Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@DriveBC MCP Server What are the current conditions on Highway 1?"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
An MCP (Model Context Protocol) server that provides AI assistants with access to real-time BC highway conditions, road closures, and weather alerts via the Open511-DriveBC API.
Highway Conditions: Get current conditions for specific BC highways
Regional Overview: View all events within a BC region
Road Closures: List active closures and restrictions
Weather Alerts: Access weather-related incidents and warnings
Smart Caching: 5-minute cache to reduce API load while keeping data fresh
Type-Safe: Full TypeScript implementation with proper types
Related MCP server: aria-mcp-trafik-dk
npm install
npm run buildnpm startThe server runs on stdio transport and is designed to be used with MCP-compatible AI clients like Claude Desktop.
npm run devAdd the following to your Claude Desktop configuration file:
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Linux: ~/.config/Claude/claude_desktop_config.json
{
"mcpServers": {
"drivebc": {
"command": "node",
"args": ["/path/to/drivebc_mcp/build/index.js"]
}
}
}After adding the configuration, restart Claude Desktop.
LM Studio supports MCP as of version 0.3.17. Add the following to your LM Studio MCP configuration:
macOS/Linux: ~/.lmstudio/mcp.json
Windows: %USERPROFILE%/.lmstudio/mcp.json
{
"mcpServers": {
"drivebc": {
"command": "node",
"args": ["/path/to/drivebc_mcp/build/index.js"]
}
}
}After adding the configuration, restart LM Studio.
Get current conditions, incidents, and closures for a specific BC highway.
Parameters:
highway (required): Highway number or name (e.g., "Highway 1", "99", "1")
severity (optional): Filter by severity level (MINOR, MODERATE, MAJOR, UNKNOWN)
includeScheduled (optional): Include scheduled construction (default: true)
Example:
Check Highway 1 conditionsGet road conditions and events for a specific BC region.
Parameters:
region (required): BC region name (Lower Mainland, Vancouver Island, Thompson Okanagan, Kootenay Rockies, Cariboo, Northern BC)
eventType (optional): Filter by event type (CONSTRUCTION, INCIDENT, WEATHER_CONDITION, ROAD_CONDITION, SPECIAL_EVENT)
limit (optional): Maximum events to return (default: 50, max: 500)
Example:
Show road conditions in the Lower MainlandList all current road closures and major restrictions.
Parameters:
region (optional): Filter by BC region
highway (optional): Filter by specific highway
severityMinimum (optional): Minimum severity to include (MINOR, MODERATE, MAJOR; default: MODERATE)
Example:
Are there any road closures on Highway 1?Get active weather alerts and road condition warnings.
Parameters:
region (optional): Filter by BC region
alertType (optional): Type of alert (WEATHER_CONDITION, ROAD_CONDITION, INCIDENT)
severityMinimum (optional): Minimum severity level (default: MINOR)
Example:
Show weather alerts for Northern BCThis server uses the Open511-DriveBC API which provides:
Real-time road events and incidents
Road closures and construction updates
Weather conditions and alerts
Travel advisories
The API is public and requires no authentication.
The server implements a 5-minute cache to:
Reduce load on the DriveBC API
Improve response times
Maintain reasonably fresh data
Cache hits and misses are logged to stderr for monitoring.
drivebc_mcp/
├── src/
│ ├── index.ts # MCP server entry point
│ ├── tools/
│ │ ├── highway-conditions.ts # Highway-specific queries
│ │ ├── regional-conditions.ts # Regional overview
│ │ ├── road-closures.ts # Closures and restrictions
│ │ └── weather-alerts.ts # Weather and incidents
│ ├── api/
│ │ ├── client.ts # API client with caching
│ │ ├── types.ts # TypeScript type definitions
│ │ └── constants.ts # BC regions and highways
│ ├── cache/
│ │ └── manager.ts # Cache implementation
│ └── utils/
│ └── formatters.ts # Response formatting
├── package.json
├── tsconfig.json
└── README.mdnpm run type-checknpm run buildThe server supports the following BC regions:
Lower Mainland
Vancouver Island
Thompson Okanagan
Kootenay Rockies
Cariboo
Northern BC
MIT
Get current conditions, incidents, and closures for a specific BC highway. Returns active events including construction, accidents, weather conditions, and road closures.
| Name | Required | Description | Default |
|---|---|---|---|
| highway | Yes | Highway number or name (e.g., "Highway 1", "Highway 99", "1", "99") | |
| severity | No | Filter by severity level (optional) | |
| includeScheduled | No | Include scheduled construction/maintenance (default: true) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses behavioral traits: it returns 'current conditions, incidents, and closures' and 'active events including construction, accidents, weather conditions, and road closures,' indicating real-time data scope. However, it lacks details on permissions, rate limits, data freshness, or error handling, which are important for a read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded: the first sentence states the core purpose, and the second adds detail on return values. Both sentences earn their place by providing essential information without redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and 3 parameters with full schema coverage, the description is moderately complete. It covers the tool's purpose and return types but lacks output format details, error handling, or behavioral constraints, leaving gaps for a tool that fetches dynamic data.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents parameters. The description adds no additional parameter semantics beyond implying filtering by highway and event types, which is already covered in the schema. Baseline is 3 as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get current conditions, incidents, and closures for a specific BC highway' with specific resources (highway conditions) and verb (get). It distinguishes from siblings by specifying 'specific BC highway' (vs. regional, road closures only, or weather alerts only), though it doesn't explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by specifying 'specific BC highway' and listing event types, suggesting it's for detailed highway-level info. However, it doesn't explicitly state when to use this tool vs. siblings like get_regional_conditions or get_road_closures, nor does it provide exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get road conditions and events for a specific BC region. Useful for planning trips within a geographic area.
| Name | Required | Description | Default |
|---|---|---|---|
| region | Yes | BC region name. Options: Lower Mainland, Vancouver Island, Thompson Okanagan, Kootenay Rockies, Cariboo, Northern BC | |
| eventType | No | Filter by event type (optional) | |
| limit | No | Maximum number of events to return (default: 50, max: 500) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool retrieves data ('Get'), implying a read-only operation, but doesn't mention any behavioral traits like rate limits, authentication requirements, data freshness, or error handling. For a tool with no annotations, this leaves significant gaps in understanding how it behaves beyond basic functionality.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded, with two sentences that directly address purpose and usage. The first sentence clearly states what the tool does, and the second adds contextual value without redundancy. There's no wasted text, making it efficient for an agent to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (3 parameters, no output schema, no annotations), the description is minimally adequate. It covers the basic purpose and a hint of usage, but lacks details on behavioral aspects, output format, or differentiation from siblings. Without annotations or an output schema, the description should do more to compensate, but it only meets the minimum viable threshold.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with clear documentation for all parameters (region, eventType, limit). The description doesn't add any parameter-specific details beyond what's in the schema, such as explaining the relationship between parameters or providing examples. With high schema coverage, the baseline score of 3 is appropriate, as the schema already provides adequate parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get road conditions and events for a specific BC region.' It specifies the verb ('Get') and resource ('road conditions and events'), and mentions the geographic scope ('BC region'). However, it doesn't explicitly differentiate from sibling tools like get_highway_conditions or get_road_closures, which likely have overlapping functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides some usage context: 'Useful for planning trips within a geographic area.' This implies when to use it, but doesn't explicitly state when to choose this tool over alternatives like get_highway_conditions or get_road_closures. No exclusions or prerequisites are mentioned, leaving the agent to infer usage based on the tool name and description alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all current road closures and major restrictions across BC or filtered by region/highway. Includes full closures, lane closures, and significant restrictions.
| Name | Required | Description | Default |
|---|---|---|---|
| region | No | Filter by BC region (optional) | |
| highway | No | Filter by specific highway (optional) | |
| severityMinimum | No | Minimum severity to include (default: MODERATE) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions the types of closures included ('full closures, lane closures, and significant restrictions'), but does not cover critical aspects like data freshness, rate limits, authentication needs, or error handling, which are essential for a read operation with filtering.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded, with two sentences that efficiently convey the tool's purpose and scope without unnecessary details. Every sentence adds value, making it easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a read operation with filtering and no annotations or output schema, the description is incomplete. It lacks information on return format, pagination, error cases, and how it differs from sibling tools, which are necessary for effective tool selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, so the baseline is 3. The description adds some context by mentioning filtering by 'region/highway' and including 'severity' implicitly, but it does not provide additional semantic details beyond what the schema already documents, such as examples or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'List all current road closures and major restrictions across BC or filtered by region/highway.' It specifies the verb ('List'), resource ('road closures and major restrictions'), and scope ('across BC'), but does not explicitly differentiate it from sibling tools like 'get_highway_conditions' or 'get_regional_conditions', which likely overlap in functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It mentions filtering by region or highway, but does not specify when to choose this over sibling tools such as 'get_highway_conditions' or 'get_regional_conditions', leaving the agent without clear usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get active weather alerts, incidents, and road condition warnings across BC. Includes winter conditions, avalanche warnings, fog advisories, and weather-related incidents.
| Name | Required | Description | Default |
|---|---|---|---|
| region | No | Filter by BC region (optional) | |
| alertType | No | Type of alert to retrieve (default: all weather-related) | |
| severityMinimum | No | Minimum severity level (default: MINOR) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It describes what the tool retrieves (e.g., 'active weather alerts, incidents, and road condition warnings') but lacks details on behavioral traits such as rate limits, authentication needs, data freshness, or response format. For a tool with no annotations, this is a significant gap, as it doesn't inform the agent about operational constraints or expected behavior beyond the basic output.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded, stating the core purpose in the first sentence and adding examples in the second. It avoids unnecessary details and wastes no words, making it efficient for an agent to parse. However, it could be slightly improved by structuring usage hints, but it's already well-sized for its content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (3 parameters, no annotations, no output schema), the description is moderately complete. It covers the purpose and scope but lacks output details, behavioral context, and sibling differentiation. Without an output schema, the agent must infer return values, and the description doesn't address this gap. It's adequate for a basic read operation but has clear omissions for effective tool selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with clear parameter descriptions and enums. The description adds minimal value beyond the schema, as it doesn't explain parameter interactions, defaults (e.g., 'default: all weather-related' for alertType is only in the schema), or usage examples. With high schema coverage, the baseline score is 3, as the description doesn't compensate with additional semantic insights.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get active weather alerts, incidents, and road condition warnings across BC.' It specifies the verb ('Get') and resources ('weather alerts, incidents, and road condition warnings'), and includes examples like 'winter conditions, avalanche warnings, fog advisories.' However, it doesn't explicitly differentiate from sibling tools like 'get_highway_conditions' or 'get_road_closures,' which likely overlap in scope, preventing a score of 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus its siblings (e.g., 'get_highway_conditions,' 'get_regional_conditions,' 'get_road_closures'). It mentions the scope ('across BC') and types of alerts, but lacks explicit when-to-use or when-not-to-use instructions, alternatives, or prerequisites, leaving the agent to infer usage context without clear direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
get_highway_conditionsget_regional_conditionsget_road_closuresget_weather_alertsThe tools are mostly distinct, with each focusing on a specific aspect of road conditions: highway-specific, regional, closures, and weather alerts. However, there is some overlap between get_highway_conditions and get_road_closures, as both could include closure information, which might cause minor confusion for an agent. The descriptions help clarify the distinctions, but the boundaries are not perfectly clear.
All tool names follow a consistent verb_noun pattern using snake_case (e.g., get_highway_conditions, get_regional_conditions). This predictability makes it easy for an agent to understand and use the tools without confusion, as there are no deviations in naming conventions.
With 4 tools, the server is well-scoped for providing road condition information in BC. Each tool serves a distinct purpose, and the count is appropriate for the domain, avoiding both overcomplication and undercoverage. This aligns with typical MCP server tool counts for focused services.
The tool surface covers key aspects of road conditions, including specific highways, regions, closures, and weather alerts, which supports planning and monitoring. A minor gap exists in not having tools for historical data or predictive analytics, but agents can work around this with the provided tools for current conditions. Overall, it offers good coverage for the stated purpose.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
WA highway conditions, ferry schedules, vessel locations, toll rates, and border waits via MCP.
Live California road conditions: CHP incidents, Caltrans closures, chain controls, and wildfires.
Real-time transit stops, routes, arrivals, vehicle positions, and schedules via OneBusAway APIs.
Live barrier status and closure forecasts for ~1,600 UK level crossings. Public data, no auth.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/infil00p/DriveBC_MCP'
If you have feedback or need assistance with the MCP directory API, please join our Discord server