Singapore Location Intelligence MCP

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.0
Disambiguation4/5
Most tools have distinct purposes, such as find_bus_stops for locating stops and get_bus_arrival for real-time arrivals, but there is some overlap between get_weather_conditions and get_weather_advisory, which could cause confusion. Overall, descriptions help clarify boundaries, but minor ambiguity exists in weather-related tools.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern using snake_case, such as find_bus_stops, get_bus_arrival, and search_location. This uniformity makes the tool set predictable and easy to navigate, with no deviations in naming conventions.
Tool Count5/5
With 13 tools, the count is well-scoped for a location intelligence server covering transportation, weather, and geocoding in Singapore. Each tool serves a clear purpose, such as journey planning or bus stop searches, without feeling excessive or insufficient for the domain.
Completeness4/5
The tool set provides comprehensive coverage for Singapore location intelligence, including transportation (bus, train, taxi), weather, geocoding, and journey planning. Minor gaps exist, such as no tool for traffic conditions or detailed train schedules, but agents can work around these with the available tools for core workflows.
Average 3/5 across 13 of 13 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states what the tool does but provides no information about authentication requirements, rate limits, error conditions, response format, or whether this is a read-only operation. For a search tool with 5 parameters, this leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that communicates the core functionality without unnecessary words. It's appropriately sized for a search tool and front-loads the essential information about what the tool does and how it can be used.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 5 parameters, no annotations, and no output schema, the description is inadequate. It doesn't explain what the tool returns, how results are structured, error handling, or any behavioral constraints. The agent would need to guess about the output format and operational characteristics.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description mentions three search methods ('location name, coordinates, or road name') which map to the 'location', 'lat/lng', and implied 'road name' parameters, but the input schema has 100% description coverage with detailed parameter documentation. The description adds minimal value beyond what's already in the schema, meeting the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Find') and resource ('bus stops') with specific search methods ('by location name, coordinates, or road name'), making the purpose immediately understandable. However, it doesn't explicitly distinguish this tool from sibling tools like 'search_bus_stops' or 'get_bus_stop_details', which would require more specific differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 like 'search_bus_stops' or 'get_bus_stop_details'. There's no mention of prerequisites, optimal use cases, or exclusions, leaving the agent to infer usage context from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 'discover' and 'search around a location', which implies a read-only operation, but doesn't clarify if it's safe, whether it requires authentication, rate limits, or what the output format looks like. For a tool with 5 parameters and no output schema, this lack of behavioral context is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that efficiently conveys the core purpose without unnecessary words. It's front-loaded with the main action and scope, making it easy to understand at a glance. Every part of the sentence earns its place by specifying key elements like location, resources, and data source.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (5 parameters, no annotations, no output schema), the description is incomplete. It lacks details on behavioral traits (e.g., safety, performance), output format, and usage guidelines relative to siblings. For a discovery tool with rich input options, more context is needed to help an agent use it effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description adds no additional parameter semantics beyond what's in the schema—it doesn't explain how parameters interact (e.g., combining 'categories' and 'facilityType') or provide usage examples. Baseline 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Discover landmarks, facilities, and points of interest near a location using Singapore's comprehensive thematic data.' It specifies the action ('discover'), resources ('landmarks, facilities, and points of interest'), and geographical scope ('near a location' in Singapore). However, it doesn't explicitly differentiate from sibling tools like 'search_location' or 'resolve_postal_code', which might 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.
Usage Guidelines2/5
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 'Singapore's comprehensive thematic data' but doesn't specify what makes it unique compared to siblings like 'search_location' or 'get_nearby_taxis'. There's no mention of prerequisites, exclusions, or specific scenarios where this tool is preferred over others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. While it mentions what information is included, it doesn't describe important behavioral aspects like whether this is a read-only operation, potential rate limits, authentication requirements, error conditions, or response format. The description is insufficient for a tool with 5 parameters and no output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that efficiently communicates the core purpose. It's appropriately sized for the tool's complexity, though it could be slightly more front-loaded by mentioning the required busStopCode parameter upfront.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 5 parameters, no annotations, and no output schema, the description is insufficiently complete. It doesn't address behavioral aspects, doesn't help differentiate from siblings, and doesn't compensate for the lack of output schema by describing what the return value contains. The description leaves significant gaps for proper tool understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description mentions 'services, nearby amenities, accessibility information, and location context' which loosely maps to some parameters (includeServices, includeNearbyAmenities). However, with 100% schema description coverage, the schema already documents all 5 parameters thoroughly. The description adds minimal value beyond what's in the schema, meeting the baseline for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verbs ('Get comprehensive details') and resources ('about a specific bus stop'), and lists the types of information included (services, amenities, accessibility, location). However, it doesn't explicitly differentiate from sibling tools like 'get_bus_arrival' or 'search_bus_stops', which might 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.
Usage Guidelines2/5
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. With siblings like 'get_bus_arrival' (which might focus on arrival times) and 'search_bus_stops' (which might search for stops), there's no indication of when this detailed lookup tool is preferred over those options.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 what the tool does but doesn't describe how it behaves: it doesn't mention whether results are real-time, paginated, sorted, or limited; what 'available' means; or any rate limits or authentication needs. This is a significant gap for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose without unnecessary words. Every part of the sentence ('Find available taxis near a specified location') directly contributes to understanding the tool's function, making it appropriately concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (location-based query with multiple parameters) and lack of annotations and output schema, the description is incomplete. It doesn't explain what the tool returns, how results are formatted, or behavioral aspects like real-time data or limitations. For a tool with no structured output or safety hints, more context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all four parameters with descriptions and constraints. The description adds no additional parameter semantics beyond implying location-based filtering, which is already covered in the schema. Baseline 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('Find') and resource ('available taxis'), specifying the scope ('near a specified location'). It distinguishes from siblings like 'find_bus_stops' or 'get_bus_arrival' by focusing on taxis, but doesn't explicitly differentiate from other location-based tools like 'search_location' beyond the taxi context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 doesn't mention prerequisites, when not to use it, or compare it to sibling tools like 'plan_comprehensive_journey' for broader transportation planning. Usage is implied by the name and purpose but not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 states the action but lacks behavioral details like whether it's real-time or cached, data sources, rate limits, or error handling. This is a significant gap for a tool with potential real-time implications.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It's front-loaded with the core action and resource, making it appropriately sized and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description is incomplete. It doesn't explain return values, data freshness, or error cases, which are crucial for a status-checking tool. This leaves gaps in understanding how to interpret results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the parameter 'line' documented as optional and with an enum. The description adds no extra parameter meaning beyond implying it checks 'current' status, which is minimal value. Baseline 3 is appropriate 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Check') and resource ('train service status and any disruptions'), making the purpose specific and understandable. However, it doesn't explicitly differentiate from siblings like 'get_weather_advisory' or 'plan_comprehensive_journey' that might involve transportation status, though the focus on trains is implied.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It doesn't mention prerequisites, timing, or comparisons to siblings such as 'get_bus_arrival' for other transit modes, leaving usage context unclear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions 'real-time' and 'comprehensive' but doesn't specify data freshness, rate limits, authentication requirements, error conditions, or what 'travel impact analysis' entails. The description is insufficient for a tool with multiple parameters and no output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose. Every word earns its place - 'comprehensive real-time weather conditions,' 'Singapore,' and 'travel impact analysis and advisories' all provide valuable context without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 5 parameters, nested objects, no annotations, and no output schema, the description is incomplete. It doesn't explain what the tool returns, how 'travel impact analysis' manifests in outputs, or provide behavioral context needed for proper invocation. The description assumes too much given the complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description doesn't add meaningful parameter semantics beyond what's in the schema - it mentions 'travel impact analysis' which might relate to 'includeAdvisories', but this is already clear from the schema. Baseline 3 is appropriate when schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
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 comprehensive real-time weather conditions for Singapore with travel impact analysis and advisories.' It specifies the action ('Get'), resource ('weather conditions'), and scope ('Singapore'), but doesn't explicitly differentiate from sibling 'get_weather_advisory' which might 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.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives like 'get_weather_advisory' or other weather-related tools. The description mentions travel impact analysis but doesn't explain when this is preferable to basic weather data or other siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 'comprehensive journey' with 'step-by-step instructions, route visualization, and contextual information,' but doesn't disclose critical behavioral traits like whether it's a read-only operation, if it requires authentication, rate limits, error handling, or what the output format looks like (since no output schema exists). For a complex planning tool with 8 parameters, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose: 'Plan a comprehensive journey with step-by-step instructions, route visualization, and contextual information.' It's appropriately sized with zero waste, making it easy for an agent to quickly understand the tool's function without unnecessary details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (8 parameters, nested objects, no annotations, and no output schema), the description is incomplete. It doesn't address behavioral aspects, output expectations, or usage context. For a journey planning tool that likely involves real-time data and multiple transport modes, more information is needed to help an agent use it effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description adds no additional meaning beyond what the schema provides—it doesn't explain parameter interactions, dependencies, or provide examples of usage. Baseline 3 is appropriate when the schema does the heavy lifting, but the description doesn't compensate with extra insights.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Plan a comprehensive journey with step-by-step instructions, route visualization, and contextual information.' It specifies the verb ('plan') and resource ('journey'), and distinguishes from siblings by focusing on comprehensive planning rather than specific lookups like finding bus stops or weather conditions. However, it doesn't explicitly differentiate from all siblings (e.g., it could mention it's for multi-modal planning vs. single-mode tools).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 doesn't mention any prerequisites, constraints, or sibling tools that might be better for specific tasks (e.g., using 'get_bus_arrival' for real-time updates or 'search_location' for location resolution). Usage is implied by the purpose but not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states what the tool does but doesn't describe important behavioral traits: whether it's a read-only operation, what happens with invalid coordinates, rate limits, authentication requirements, or what the output format looks like (since there's no output schema). The description is functional but lacks operational context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that states the core purpose without unnecessary words. It's appropriately sized for a straightforward geocoding tool and front-loads the essential information. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (4 parameters, no output schema, no annotations), the description is insufficiently complete. It explains what the tool does but doesn't address behavioral aspects, output format, error conditions, or usage context relative to siblings. For a geocoding tool that returns location data, more guidance on results and limitations would be helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all parameters are documented in the schema. The description adds no additional parameter semantics beyond implying that latitude/longitude are the primary inputs. It doesn't explain the relationship between parameters (e.g., how radius affects results) or provide usage examples. With complete schema coverage, the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get') and resource ('address and location information') with the source ('from latitude/longitude coordinates'). It distinguishes from siblings like 'resolve_postal_code' (which uses postal codes) and 'search_location' (which likely uses text queries). However, it doesn't explicitly mention how it differs from 'find_landmarks_and_facilities' which might also use coordinates.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 doesn't mention when to choose reverse_geocode over 'resolve_postal_code' (for postal code lookups) or 'search_location' (for text-based searches), nor does it specify prerequisites like coordinate format or valid ranges beyond what's in the schema.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions 'supports fuzzy search and intelligent query analysis' which adds some behavioral context beyond basic functionality, but doesn't cover important aspects like rate limits, authentication requirements, error handling, or what the output format looks like (especially critical since there's no output schema).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately concise with two sentences that each add value. The first sentence establishes core functionality and scope, while the second adds behavioral context about search capabilities. There's no wasted verbiage or repetition of information already in the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a search tool with 5 parameters, no annotations, and no output schema, the description is insufficient. It doesn't explain what the search returns (location objects? coordinates? addresses?), how results are ranked, error conditions, or performance characteristics. The behavioral context provided is minimal given the tool's complexity and lack of structured metadata.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all 5 parameters thoroughly. The description mentions 'addresses, postal codes, landmarks, or building names' which aligns with the query parameter documentation, but adds no additional semantic context beyond what's already in the well-documented schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches for locations in Singapore using various input types (addresses, postal codes, landmarks, building names), which is a specific verb+resource combination. However, it doesn't explicitly differentiate from sibling tools like 'search_bus_stops' or 'find_landmarks_and_facilities' that might 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.
Usage Guidelines2/5
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 like 'search_bus_stops', 'find_landmarks_and_facilities', or 'resolve_postal_code'. It mentions what the tool does but offers no context about appropriate use cases or exclusions compared to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 'real-time' arrival times, which implies dynamic data, but does not cover other traits such as rate limits, authentication needs, error handling, or data freshness. For a tool with no annotation coverage, this leaves significant gaps in understanding its operational behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that efficiently conveys the core purpose without unnecessary words. It is front-loaded with the main action and resource, making it easy to understand at a glance. Every part of the sentence earns its place by specifying key aspects like 'real-time' and 'specific bus stop.'
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
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 but lacks details on behavioral traits, usage context, and output expectations. Without annotations or an output schema, the description should do more to compensate, such as hinting at return values or error conditions, but it does not.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters thoroughly (e.g., busStopCode as a 5-digit code, serviceNo as optional, format with enum values). The description does not add any meaning beyond what the schema provides, such as explaining how parameters interact or providing usage examples. Baseline 3 is appropriate when the schema handles parameter documentation effectively.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
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 real-time bus arrival times and information for a specific bus stop.' It specifies the verb ('Get'), resource ('bus arrival times and information'), and scope ('for a specific bus stop'). However, it does not explicitly differentiate from sibling tools like 'get_bus_stop_details' or 'search_bus_stops,' which might provide overlapping or related information.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 does not mention sibling tools like 'get_bus_stop_details' (which might provide static stop info) or 'search_bus_stops' (which might help find stop codes), nor does it specify prerequisites or exclusions. Usage is implied by the purpose but lacks explicit context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 'high accuracy' but doesn't cover other critical aspects like rate limits, error handling, authentication needs, or what 'detailed location information' entails. For a tool with no annotation coverage, this leaves significant gaps in understanding its operational behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose without unnecessary details. It's appropriately sized for the tool's complexity, with no wasted words, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (2 parameters, no output schema, no annotations), the description is minimally adequate. It states the purpose but lacks details on usage context, behavioral traits, and output format. Without an output schema, the description should ideally hint at return values, but it doesn't, leaving gaps in completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, clearly documenting both parameters. The description adds no additional semantic information beyond what's in the schema, such as examples or edge cases. With high schema coverage, the baseline score is 3, as the description doesn't compensate but also doesn't detract from the schema's clarity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Resolve a Singapore postal code to detailed location information with high accuracy.' It specifies the verb ('resolve'), resource ('Singapore postal code'), and outcome ('detailed location information'). However, it doesn't explicitly differentiate from sibling tools like 'reverse_geocode' or 'search_location', which might offer similar location-related functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 doesn't mention sibling tools or specify scenarios where this tool is preferred over others, such as 'reverse_geocode' for coordinates or 'search_location' for broader queries. There's no explicit context for usage, leaving the agent to infer based on the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions 'advisories' and 'recommendations' but doesn't specify what these entail (e.g., format, detail level), whether there are rate limits, authentication needs, or how defaults work. This leaves significant gaps for a tool with potential real-world impact.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose without unnecessary words. Every element ('weather-based travel and activity advisories', 'Singapore', 'specific recommendations') contributes directly to understanding the tool's function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description is incomplete for a tool that provides advisory information. It lacks details on output format, error handling, or behavioral constraints. However, the purpose is clear and parameters are well-documented in the schema, making it minimally viable but with notable gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 both parameters. The description adds no additional parameter semantics beyond implying 'Singapore' as a default location and 'advisories' as output context. This meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
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 weather-based travel and activity advisories for Singapore with specific recommendations.' It specifies the action (get), resource (advisories), and scope (Singapore). However, it doesn't explicitly differentiate from sibling tools like 'get_weather_conditions' beyond mentioning 'advisories' vs 'conditions', leaving some ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for weather-based travel and activity advisories in Singapore, but provides no explicit guidance on when to use this tool versus alternatives like 'get_weather_conditions' or other travel-related siblings. The context is clear but lacks comparative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses key behavioral traits like fuzzy matching, Singapore abbreviation support, and pattern recognition. However, it doesn't mention rate limits, authentication requirements, error conditions, or what the output format looks like (though there's no output schema).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly concise - two sentences that both earn their place. The first sentence establishes core functionality, the second provides concrete examples. No wasted words, front-loaded with the most important information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 6-parameter search tool with no annotations and no output schema, the description provides good context about search capabilities but lacks information about return format, error handling, or performance characteristics. It's adequate but has clear gaps given the tool's complexity and lack of structured metadata.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all 6 parameters thoroughly. The description adds some context about Singapore abbreviations and query patterns, but doesn't provide additional parameter semantics beyond what's already in the schema descriptions. Baseline 3 is appropriate when schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool performs 'Advanced search for bus stops' with specific capabilities like fuzzy matching, Singapore abbreviations, and pattern recognition. It distinguishes from siblings like 'find_bus_stops' by emphasizing advanced search features and provides concrete query examples like 'Opp Blk 910'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context about when to use this tool (for advanced bus stop searches with Singapore-specific patterns), but doesn't explicitly state when NOT to use it or mention alternatives like 'find_bus_stops' or 'search_location'. The examples help guide appropriate usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![MCP-Public-Transport MCP server](https://glama.ai/mcp/servers/siva-sub/MCP-Public-Transport/badges/card.svg)](https://glama.ai/mcp/servers/siva-sub/MCP-Public-Transport)

Score Badge

Copy to your README.md:

[![MCP-Public-Transport MCP server](https://glama.ai/mcp/servers/siva-sub/MCP-Public-Transport/badges/score.svg)](https://glama.ai/mcp/servers/siva-sub/MCP-Public-Transport)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/siva-sub/MCP-Public-Transport'

If you have feedback or need assistance with the MCP directory API, please join our Discord server