SG Gov MCP Server

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation5/5
Each tool targets a distinct data source or action, from weather and air quality to bus arrivals and MyInfo showcase data. Even similar tools like sg_weather vs sg_rainfall vs sg_flood_alerts have clearly separate purposes, and descriptions reinforce the differences.
Naming Consistency4/5
All tool names use the 'sg_' prefix and snake_case consistently, but the second part varies between pure nouns (sg_weather), compound nouns (sg_air_quality), and verb-noun forms (sg_dataset_search). This is a minor deviation from a strict verb_noun convention, but the overall pattern remains predictable.
Tool Count2/5
With 34 tools, the server exceeds the 25-tool threshold for 'too many' in the rubric. Even though the scope is broad (Singapore government data across many domains), the sheer number makes the server feel heavyweight and harder to navigate, despite each tool having a defined purpose.
Completeness5/5
The tool set is remarkably comprehensive for a government-data MCP: it covers weather, environment, transport, traffic, property, education, business, geospatial, and even personal data via MyInfo showcase. There are no obvious dead ends—every major data category an agent might need is represented, and dataset search/fetch covers open-data exploration.
Average 3.8/5 across 34 of 34 tools scored. Lowest: 2.7/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 1 commit 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
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
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

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It merely states the basic purpose without revealing whether it returns a list, how query filtering works, what the output format is, or any limitations. This is a critical gap for a tool with no other structured safety or behavioral metadata.
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, front-loaded sentence with no unnecessary words. It accomplishes the basic purpose in a concise manner, earning full marks for conciseness and structure.
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?
With no output schema and no annotations, the description should clarify what information is returned and the effect of the optional query. It doesn't mention return format or provide usage context, leaving the agent uncertain about the tool's expected behavior. The tool is simple, but completeness still requires more than a bare statement.
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 schema fully describes the only parameter 'query' as 'Search by name or area', so coverage is 100%. The description adds no additional parameter context, but since the schema does the heavy lifting, a baseline score 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 'Get Singapore hawker centre information' clearly identifies the resource (hawker centres) and the action (get). It is specific enough to distinguish from sibling tools like weather or transport tools, but it could be more explicit about whether it lists all centres or searches, so it lacks full sibling 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 other Singapore-specific tools, no prerequisites, and no exclusions. It also doesn't mention whether the query parameter is required or how the tool behaves with or without it.
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?
Since no annotations are provided, the description carries the full burden. It only states that fetching, sorting, and full-text search are supported. It does not disclose response format, pagination behavior, error handling, rate limits, or other behavioral traits.
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?
Two short sentences, front-loaded with the core action and key features. No wasted words or redundant restatements of the tool name.
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?
There is no output schema and no annotations, so the description must clarify what the agent can expect. It does not mention return value structure, pagination, or limits. For a data-fetch tool this is a significant gap, though the core operation is clear.
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 coverage is 60%, with dataset_id, sort, and search described. The description adds 'supports sorting and full-text search,' which maps to the sort and search params but offers no new syntax or behavior. limit and offset have defaults but are undocumented in both schema and description.
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 action ('Fetch rows from a data.gov.sg dataset by resource ID') and its key capabilities (sorting and full-text search). This distinguishes it from sibling tools like sg_dataset_search, which is about searching for datasets rather than retrieving rows.
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 when you have a dataset ID and need rows, with optional sort/search. However, it does not explicitly mention when not to use it or point to alternatives like sg_dataset_search for dataset discovery.
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 the output fields but does not disclose search behavior (e.g., exact vs. partial match, result limits, or pagination). For a read-only search, this is minimal transparency beyond what a tool name would imply.
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 two short sentences that immediately convey the purpose and key outputs. No filler or redundant wording. It is well-structured and easy to parse.
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 simplicity of a single-parameter search tool, the description covers the essentials: what it searches and what it returns. However, it lacks details about match behavior, result limits, or error conditions. With no output schema, the description could be more complete, but it is not severely deficient.
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 covers the only parameter 'query' with a clear description ('Company name to search for'), and the tool description also mentions 'by name'. With 100% schema coverage, the description adds little extra meaning, so a baseline score of 3 is appropriate.
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 specifies a clear verb ('Search'), a specific resource ('ACRA-registered companies in Singapore'), and the scope ('by name'). It also lists the returned fields, making the tool's function unambiguous. It stands out from sibling tools, none of which target company records.
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 implicitly conveys when to use this tool (when you need to search for a company by name), but it does not explicitly state when not to use it or mention any alternative tools. Since there are no competing company-search tools among the siblings, the guidance is adequate but not explicit.
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 the API key requirement, which is useful, but does not describe data freshness, response format, or operational limitations, leaving significant behavioral ambiguity.
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 exactly one sentence with the purpose, followed by a short requirement note. It is front-loaded with the verb and resource, and every word earns its place with no redundancy.
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 that there is no output schema and no annotations, the description should explain what the tool returns. It states the purpose and the key requirement, but does not describe the output structure or any operational nuances, making it minimally viable but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has zero parameters, so schema coverage is 100%. The description adds no parameter details, but since there are no parameters, it doesn't need to. The baseline for 0 params is 4, and the description meets that baseline.
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's function with a specific verb and resource: 'Get electric vehicle charging point availability in Singapore.' It distinguishes itself from sibling tools like sg_carpark and sg_taxi_availability by naming the unique EV charging domain.
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. The only additional note is 'Requires SG_LTA_KEY,' which is a prerequisite rather than selection context. There is no mention of alternative tools or specific use cases.
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 merely states the operation without revealing details such as data source, default behavior when no year is given, output format, or any limitations. This is a significant gap for a tool that claims to 'get' data.
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, front-loaded sentence with no wasted words. It efficiently conveys the tool's purpose. This is exemplary conciseness.
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 simplicity (one optional parameter, no output schema), the description is minimally viable but incomplete. It does not mention that the year parameter is optional or what happens when omitted, nor does it describe the return value (e.g., list of dates). With no annotations or output schema, the description should provide more context to be fully complete.
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% for the single optional parameter `year`, which the schema describes as 'Filter by year e.g. 2025, 2026'. The tool description itself does not add any additional parameter semantics. Baseline 3 is appropriate because the schema sufficiently documents the parameter.
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 uses a specific verb ('Get') and resource ('Singapore public holidays'), which clearly states what the tool does. It is distinct from sibling tools, none of which relate to holidays. No ambiguity or tautology.
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 when Singapore public holiday data is needed, but it does not provide explicit guidance on when to use or not use this tool. No alternatives are mentioned, though none exist among siblings. The context is simple, but explicit usage guidance is missing.
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 must disclose behavioral traits. It only mentions the SG_LTA_KEY requirement, which is a prerequisite rather than a behavior. It does not state whether the operation is read-only, discuss rate limits, error conditions, or output format. The read-only nature is only implied by 'Get'.
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, clear, and direct sentence that front-loads the main action. It is concise with no unnecessary information, though it could be slightly more structured if it included additional behavioral context.
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?
With no output schema, the description should explain what the response contains or how to interpret the crowd density data. It does not. The description is too minimal to fully prepare an agent for using the tool correctly, leaving gaps in expected output and possible failure modes.
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 coverage is 100% with both parameters fully described. The description's mention of 'real-time or forecast' only echoes the existing 'forecast' parameter description. No additional parameter semantics are provided beyond the schema.
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 'Get MRT/LRT station crowd density' with a specific verb and resource. It also specifies real-time or forecast, which further distinguishes it from sibling tools like sg_train_alerts or sg_bus_arrival.
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 clearly implies when to use this tool (when crowd density is needed), and the context is obvious from the name and description. However, it does not explicitly name alternatives or exclusion conditions, so it stops short of a 5.
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, the description carries the full burden. It does disclose the API key requirement and implies a read-only operation ('Get'), but lacks details on output format, rate limits, error handling, or the nature of the image links, leaving significant behavioral ambiguity.
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 extremely concise, consisting of two short sentences that front-load the core purpose. Every word earns its place, with no redundant 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 simple tool with one optional parameter and no output schema, the description gives the essential purpose and a key prerequisite. However, it omits details about the structure of returned image links, how the API key is provided, and potential failure modes, making it minimally adequate rather than fully complete.
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 schema fully documents the single 'location' parameter with a description ('Optional: filter by location keyword'). The tool description adds no extra semantic detail about the parameter, so the schema already covers it; the baseline of 3 is appropriate.
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's function with a specific verb ('Get') and resource ('live traffic camera image links'). It is easily distinguished from sibling tools like sg_traffic_incidents, which focus on incidents rather than camera imagery.
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 choose this tool over alternatives. It mentions a prerequisite (SG_LTA_KEY) but does not explain scenarios where this tool is appropriate or preferable to other SG data tools, such as sg_traffic_incidents.
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 full responsibility for behavioral disclosure. It only mentions 'real-time' and the SG_LTA_KEY requirement, but does not explain response behavior, error conditions, update frequency, or rate limits. This is minimal disclosure for a data-fetching tool.
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 sentence of 11 words, front-loads the core purpose, and contains no filler. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (one optional parameter, no output schema), the description covers the essential points: real-time availability, data sources, and the required API key. It is slightly thin on what the response contains, but for a simple lookup this is mostly adequate.
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 schema has 100% description coverage for the one optional 'location' parameter, and the description does not add parameter-level detail beyond what the schema provides. Baseline 3 is appropriate since the schema handles the semantic burden.
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 uses a specific verb ('Get'), names the resource ('real-time carpark availability'), and scopes it to HDB, LTA, and URA sources. This clearly distinguishes it from sibling tools like sg_taxi_availability and sg_ev_charging.
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 use for real-time carpark availability queries and mentions a required API key, but it does not explicitly state when to use this tool over alternatives or provide exclusions. It gives a clear context but lacks explicit when/when-not guidance.
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 only says 'Get', which implies a read-only operation, but does not disclose any potential caveats like data freshness, rate limits, or output format. The description adds no behavior context beyond the verb itself.
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, concise sentence that immediately states the tool's purpose. It is front-loaded with the verb and resource, with no filler or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple, parameterless tool, the description adequately states what it returns (active dengue cluster locations and case counts). It doesn't explain output structure, but given the simplicity and absence of parameters, the description is sufficiently complete for an agent to invoke it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema is fully covered. The baseline for 0 params is 4, and the description adds no confusion about parameters since there are none. No additional semantic explanation is needed.
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's function with a specific verb 'Get' and a specific resource: 'Singapore active dengue cluster locations and case counts'. This distinguishes it from sibling tools like sg_weather and sg_air_quality, which cover different domains.
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 exclusions, prerequisites, or context that would help an agent decide between this and related tools such as sg_neighbourhood_report or sg_flood_alerts.
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, the description carries the full burden. It does disclose the ordering behavior ('most recent first') and filtering capabilities, but it omits details about the 'limit' parameter's behavior, potential errors, or response format. This is a partial disclosure for a read-only data tool.
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, direct sentence that front-loads the primary purpose and key features. Every word adds value; there is no redundancy or unnecessary detail.
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 absence of an output schema and annotations, the description is too sparse. It fails to mention the 'limit' parameter, what data fields the response contains, or any source limitations. An agent would be left guessing about basic behavioral expectations beyond the filters.
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 schema already documents town and flat_type with examples, providing 67% coverage. The description reinforces these filters but adds no new meaning and completely ignores the 'limit' parameter, which also lacks a schema description. Thus, it does not fully compensate for the coverage gap.
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 specifies the action ('Get'), the resource ('HDB resale flat prices'), and key details like ordering ('most recent first') and filters. It distinguishes itself from sibling tools such as sg_coe_prices (COE prices) and sg_myinfo_hdb (personal HDB data).
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 usage context is implied by the description: retrieve HDB resale prices with optional filters. However, it does not explicitly mention when to choose this tool over alternatives like sg_dataset_fetch or sg_dataset_search, nor does it provide any exclusion criteria.
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 must carry the full behavioral disclosure burden. It only states the search scope (MOE schools) and mentions common data fields, but does not disclose whether results are limited to a certain number, whether authentication is needed, or what happens for empty queries. This is a notable gap for a read/query tool.
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, tightly worded sentence that conveys purpose and scope without any filler. It is appropriately sized for a simple tool and earns maximum points for efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (one optional parameter, no annotations, no output schema), the description covers the essential context: what is searched and what data points are included. It slightly loses points because it omits any detail about the return format or result limits, but overall it is sufficiently complete for a basic directory lookup.
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 covers the single parameter 'query' with a description that already explains how to search (by school name, area, or keyword). The tool description adds little semantic nuance beyond this, so the score is at the baseline for full schema coverage.
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's purpose with a specific verb ('Search') and a defined resource ('Singapore school directory'), and it distinguishes itself from sibling tools by focusing on MOE schools with address, principal, and subjects. This makes it immediately clear what the tool does and where it fits among other Singapore-related tools.
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 (search for school info), but provides no explicit guidance on when to use this tool over alternatives or when not to use it. It does not mention any exclusions or related tools, so the agent must infer the appropriate context from the purpose alone.
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, the description carries full responsibility. It discloses the tool returns bidding results and quota premiums by category, but does not mention any limitations, rate limits, or the behavior of the optional 'limit' parameter. This is adequate for a simple read operation but leaves some ambiguity.
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 extremely concise—two sentences with no fluff. It is front-loaded with the primary action ('Get COE...') and includes essential detail about the content (quota premiums by vehicle category) without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (one optional parameter, no output schema), the description provides a reasonable overview of what the tool returns. However, it omits any mention of the 'limit' parameter and does not fully specify the output structure beyond 'quota premiums by vehicle category'. Still, it is largely complete for the tool's apparent straightforward nature.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter ('limit') with a default of 10, but the description does not mention or explain it. Since schema description coverage is 0%, the description fails to add value beyond the parameter name itself. The purpose of 'limit' (e.g., maximum number of results) is not clarified.
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 it retrieves COE bidding results and prices, specifying the output as quota premiums by vehicle category. This distinguishes it from sibling tools like sg_hdb_prices or sg_dataset_fetch which deal with different data types.
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 context implies this tool is for COE price queries, but there is no explicit guidance on when to use it versus alternatives. No exclusions or mention of related tools are provided, so usage is only implied by the tool name and description.
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, the description discloses authentication requirements, a behavioral trait. However, it does not describe output format, error handling, or whether the operation is read-only, though 'Find' implies reading. The disclosure of required credentials adds value beyond the schema, but overall behavioral transparency is limited.
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?
Two efficient sentences: one for purpose and auth, one for theme examples. No redundant phrases, front-loaded with the core action, and every clause adds useful 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?
The tool is simple (3 params, no output schema), but with no annotations the description needs to cover more. It handles prerequisites and themes, but omits what the response will contain or how results are ordered. Given low complexity, it is minimally complete but leaves the output unaddressed.
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 only 33% (just the 'theme' parameter). The description enriches theme semantics with common examples, but gives no additional info for latitude/longitude beyond the word 'nearby'. Since these are standard coordinate params, the lack is partly compensated by their natural clarity, but the description could specify units or ranges.
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 uses a specific verb ('Find') and resource ('nearby amenities using OneMap themes'), making the tool's purpose clear. It does not explicitly differentiate from siblings like sg_hawker_centres, but the 'OneMap themes' qualifier and theme examples provide functional distinction.
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?
States a clear prerequisite ('Requires SG_ONEMAP_EMAIL + SG_ONEMAP_PASSWORD') and provides common theme examples, which guides selection. It does not explicitly mention when not to use it, but the examples and purpose imply suitable scenarios, so it's clear context without exclusions.
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?
No annotations are provided, so the description carries the burden for behavioral disclosure. It does disclose that the tool returns PM2.5 and PSI readings by region with health advisory band, but it omits details like data freshness, potential errors, or whether readings are real-time or historical. This is adequate but not rich.
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, clearly structured sentence that front-loads the action and resource. Every phrase contributes valuable information without any redundancy or unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a no-parameter tool with no output schema, the description sufficiently covers the main aspects: the type of readings (PM2.5, PSI), the grouping (by region), and the health advisory band. It could add specifics about regions or data recency, but overall it provides enough context for a user to understand what the tool returns.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema is empty with 100% coverage. The description adds no parameter-specific detail, but with no parameters, the baseline is 4 per the rubric.rules.
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 identifies the tool's function with a specific verb ('Get') and resource ('Singapore air quality'), and elaborates on the content (PM2.5, PSI, region breakdown, health advisory band). This clearly distinguishes it from sibling tools like sg_weather or sg_uv_index.
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 does not provide any explicit guidance on when to use this tool versus alternatives. There are no mentions of alternatives or exclusions, leaving usage fully implied by the name and purpose.
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?
No annotations are provided, so the description must carry the burden. It discloses the sandbox nature via 'SHOWCASE MODE (sandbox data)', which is valuable. However, it does not mention other behavioral aspects such as permissions, rate limits, or output format, leaving some gaps 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the main action and data categories. The added 'SHOWCASE MODE' note is useful and not redundant. Every word earns its place, and there is no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter with one parameter and no output schema, the description covers the essential return values (balances, contributions, employer history) and the sandbox context. It is mostly complete, though it could benefit from a note on whether the NRIC is required or any expected format details.
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 covers 100% of the parameters, providing 'nric' with description 'NRIC/FIN number'. The tool description does not add additional parameter semantics beyond the schema, so the baseline score of 3 applies.
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's function with a specific verb ('Get') and resource ('CPF information'), and it lists specific data types (balances, contributions, employer history) that distinguish it from sibling tools like sg_myinfo_person or sg_myinfo_passport.
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 by indicating the data type, but it does not explicitly state when to use this tool over siblings or provide any general context. There is no mention of alternatives or exclusion criteria, so usage guidance is only implicit.
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, the description carries the burden of explaining behavior. It discloses the tool combines several data sources, which is useful, but it does not describe the report's return format, data freshness, or any limitations. The phrase 'comprehensive' is vague about what exactly is included beyond the listed categories.
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 front-loads the primary purpose and lists the key components. It is concise with no wasted words or repetition.
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?
This tool aggregates multiple data sources but has no output schema and no annotations. The description does not clarify the structure or format of the returned report, which is essential for an agent to use it correctly. It lists categories but gives no detail on how they are presented, leaving significant 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?
The input schema already describes the sole parameter 'area' with examples (Tampines, Bishan, etc.), giving 100% coverage. The tool description adds no new param-specific information, so the baseline of 3 applies.
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 uses a specific verb ('Get') and clearly identifies the resource ('comprehensive neighbourhood report') for a Singapore area. It enumerates the combined data types (HDB prices, schools, hawker centres, dengue clusters, weather), which distinguishes it from the individual sibling tools like sg_weather or sg_hdb_prices.
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 clearly implies a use case: when a holistic overview of a neighbourhood is needed rather than calling multiple individual tools. However, it does not explicitly state when NOT to use it or mention alternatives, so it falls short of a 5.
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?
No annotations are provided, so the description carries the burden. It discloses the auth requirement ('Requires SG_LTA_KEY') and data source, but does not describe output format, pagination, or any other behavioral details. This is a basic read operation, and the disclosed info is useful but not rich.
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, front-loaded sentence that conveys the purpose, source, and auth requirement without any redundant wording.
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?
The tool has no output schema and no annotations, so the description must explain the return value. It states it returns 'current flood alerts' but does not specify the structure or content of the response, leaving the agent with incomplete information for downstream use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and schema coverage is effectively 100% (empty schema). No parameter descriptions are needed, so the baseline of 4 applies.
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 uses a specific verb ('Get'), identifies the resource ('current flood alerts in Singapore'), and cites the data source ('from PUB via LTA'), clearly distinguishing it from sibling tools like sg_weather or sg_rainfall.
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 this tool is for flood alerts but does not explicitly state when to use it versus alternatives or mention any exclusions. No alternative tools are referenced, so the usage context is only implicit.
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, the description carries the full burden. It discloses the credential requirement (SG_ONEMAP_EMAIL + SG_ONEMAP_PASSWORD), which is useful, but it does not mention return format, error behavior, or whether the operation is read-only. This is a moderate level of transparency.
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 consists of two sentences, each earning its place: the core function and the required credentials. It is front-loaded and free of unnecessary details.
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?
This is a simple one-parameter tool with no output schema or annotations. The description conveys the action and authentication requirement but does not specify the output format or further context. It is adequate for basic invocation but has gaps around return values.
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 already describes the parameter fully as 'Address, building name, or postal code'. The description repeats similar information without adding new meaning, so it stays at the baseline 3 for high schema coverage.
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 converts a Singapore address or postal code to coordinates, using a specific verb and resource. This distinguishes it from siblings like sg_reverse_geocode, which performs the opposite function.
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 purpose is clear and the auth requirement is stated, but the description does not explicitly mention when to use this tool versus alternatives or any exclusions. It provides clear context without explicit usage distinctions, earning a 4.
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, the description carries the transparency burden. It discloses return behavior (code/title/credits vs full details) and hints at the difference between query types. Yet it omits potential edge cases like no results, multiple matches, or whether full details are only returned for exact code matches. It is informative but not comprehensive.
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?
Two sentences, front-loaded with action and object, no redundant phrasing. Every word adds value, making it highly efficient.
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 output schema and no annotations, the description gives a reasonable overview but lacks details about response structure, handling of multiple matches, empty results, or optional acad_year behavior. It covers the main use cases but leaves gaps that an agent might need for robust invocation.
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 coverage is 100% so baseline is 3. The description adds a usage nuance about using a specific module code for full details, which goes slightly beyond the schema. But it doesn't clarify acad_year usage or response format, so value added is modest.
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 states a specific verb 'Search' with a clear resource 'NUS modules' and search criteria ('by code or title'). It distinguishes from sibling sg_ntu_modules by specifying NUS. It also outlines return contents, making the purpose unambiguous.
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?
It clearly implies use for NUS module lookups and gives within-tool guidance: use keyword for broad search, or specific module code for full details. However, it does not explicitly name alternatives or exclusions (e.g., 'for NTU modules, use sg_ntu_modules').
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, the description carries the burden. It adds the valuable credential requirement (SG_ONEMAP_EMAIL + SG_ONEMAP_PASSWORD), but does not disclose other behavioral aspects like error handling, rate limits, or return format. This is minimal but non-trivial 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 two sentences, front-loaded with the core purpose followed by the authentication requirement. Every word earns its place; there is no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple reverse geocoding tool with self-explanatory parameters, the description covers purpose and credentials. It lacks output shape or error behavior, which would be helpful given no output schema, but the essential context is present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has no descriptions for latitude/longitude and the description does not add any parameter detail beyond the names. The phrase 'coordinates' only implies the two parameters without clarifying formats or ranges. Since schema coverage is 0%, the description should compensate but doesn't.
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 uses the specific verb 'Convert' with a clear resource ('coordinates to Singapore address'), which precisely identifies the tool's function. It also distinguishes it from sibling tools like sg_geocode by explicitly stating the direction of conversion (coordinates to address).
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 clearly implies usage: when you have coordinates and need a Singapore address. However, it does not explicitly mention when not to use it or point to alternatives like sg_geocode, so it falls short of full explicit 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, the description carries the full burden. It usefully discloses that SG_ONEMAP_EMAIL and SG_ONEMAP_PASSWORD are required, which is beyond the schema. It does not disclose return format, error behavior, or rate limits, leaving a notable gap for a read-style routing tool.
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?
Three concise, front-loaded sentences each add value: the main purpose, the supported modes, and the prerequisite workflow. No filler or redundant restating of the schema.
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?
The description covers purpose, modes, and auth, but omits any mention of the response structure—critical since no output schema is provided. For a 3-parameter tool without annotations, it is minimally viable but leaves users wondering what the route result looks like.
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 baseline is 3. The description adds no extra parameter details beyond the schema, which already explains start, end_point, and mode with examples and an enum.
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 starts with the specific verb 'Get route between two points in Singapore,' clearly identifying the tool's resource (routes) and geographic scope. It also lists supported modes (driving, walking, public transport), which distinguishes it from other location-based siblings like sg_geocode or sg_nearby.
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?
It explicitly instructs 'Use sg_geocode first to get coordinates,' establishing a clear workflow prerequisite and pointing to a sibling tool. However, it does not mention when to prefer this tool over alternatives or list exclusions, so it stops short of full when/when-not 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, the description carries the burden of behavioral disclosure. It mentions the requirement of 'SG_LTA_KEY', which is a useful prerequisite, but it does not disclose response format, error behavior, rate limits, or data freshness details. The added context about the API key is valuable but incomplete for a full behavioral picture.
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 two concise sentences, immediately front-loading the core purpose and the API key requirement. Every word earns its place, with no redundancy or filler.
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 simple no-parameter tool, the description gives the essential purpose and a prerequisite, but it omits any information about the output structure, possible errors, or limitations. Without an output schema, the agent is left unaware of what the response looks like, making the description adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the input schema is an empty object with 100% coverage. Since there are no parameters to describe, the description does not need to add parameter semantics. The baseline score of 4 applies here, and the description does not detract from it.
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's function with a specific verb and resource: 'Get current traffic incidents on Singapore roads'. It distinguishes itself from sibling tools like sg_traffic_images by explicitly focusing on incidents rather than images or other data.
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 retrieving current traffic incidents but does not provide explicit guidance on when to use this tool versus alternatives. No exclusions or alternative tool mentions are present, so the usage context is only inferred from the purpose.
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?
The description discloses that an SG_LTA_KEY is required, which is a useful behavioral prerequisite not captured by any annotations. However, it does not mention response format, rate limits, or whether the data is live or cached. Since no annotations are present, the description carries the full burden, and this limited disclosure is only partially sufficient.
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 extremely concise, composed of two short sentences that state the purpose and the key requirement. Every word contributes value, and the structure front-loads the main action before the prerequisite. There is no fluff or redundancy.
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?
With no output schema and no annotations, the description should explain what the agent can expect in the response. It does not describe the structure of the alerts (e.g., affected lines, severity, timestamp), leaving potential gaps in interpretation. The tool is simple and the purpose is clear, but the lack of return-value information makes it only partially complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema trivially covers 100% of them. There are no parameter semantics to explain, and the description adds nothing beyond what the empty schema shows. The baseline for a zero-parameter tool is 4, which is appropriate here.
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 retrieves MRT/LRT service alerts and disruptions, using a specific verb 'Get' and a concrete resource. It is easily distinguished from siblings like sg_bus_arrival (bus arrivals) and sg_mrt_crowd (crowd levels), leaving no ambiguity about what the tool does.
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 the tool should be used when MRT/LRT service alerts are needed, but it provides no explicit comparison with alternative tools such as sg_bus_arrival or sg_traffic_incidents. No exclusions or conditions for when to avoid this tool are stated, so guidance is limited to an implied use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description itself must convey behavioral traits. It states that the tool returns known dataset IDs and browse links, which implicitly defines the output and hints at a limitation: only 'known' datasets. No mention of pagination, rate limits, or auth is made, but as a read-only search tool this is less critical. The description adds useful context beyond a simple verb.
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 sentence that packs the purpose and output type, with no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple nature of the tool (one parameter, no output schema) and the absence of annotations, the description covers the purpose and return value adequately. It could mention how results are ordered or paginated, but that may be outside the essential scope.
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 schema already fully documents the single query parameter with examples. The description does not add extra semantic meaning beyond restating that the tool searches for datasets, so the baseline of 3 applies.
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 uses the specific verb 'Search', names the resource 'Singapore government datasets on data.gov.sg', and specifies the return value (dataset IDs and browse links). This clearly distinguishes it from sibling tools like sg_dataset_fetch, which retrieve specific datasets, or sg_weather, which provides specific data.
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 that this is for finding dataset IDs and links, which could then be used with sg_dataset_fetch, but it does not explicitly state this workflow or any exclusions. No alternative tools are mentioned, leaving some ambiguity about when to use this versus searching directly on the website.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explicitly discloses 'SHOWCASE MODE (sandbox data)', alerting the agent that all returned information is fake and not suitable for real decisions. Since no annotations are provided, this disclosure carries the full burden and adds meaningful context, though it does not cover authentication or error 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, efficiently worded sentence followed by a short clarity flag about sandbox mode. Every word adds value with no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter getter with no output schema, the description adequately lists the returned fields and discloses the mock nature. It could mention whether all fields are always present or how invalid NRICs are handled, but it is sufficient for basic selection and invocation.
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 already provides a complete description of the single parameter `nric`, including test personas, so the description adds no additional parameter-level meaning. The high schema coverage (100%) makes the baseline 3 appropriate.
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 uses a specific verb 'Get' and identifies the resource as 'SingPass MyInfo', then enumerates the exact data fields (name, DOB, nationality, address, marital status, email, mobile), clearly distinguishing it from sibling tools like sg_myinfo_cpf or sg_myinfo_passport.
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 this tool retrieves a person's basic profile from MyInfo, but it does not explicitly state when to prefer it over the other sg_myinfo_* tools or provide any exclusion/alternative guidance. Usage is only implied by the listed fields.
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, the description carries the full burden of behavioral disclosure. It states what the tool returns (module code, title, AUs, description) and how it searches (by code or title), but it does not disclose potential limitations such as empty results, pagination, or authentication requirements. For a simple read-only search, this is reasonable but not exhaustive.
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, information-dense sentence with no filler. It communicates purpose, search method, and output in an efficient manner, 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.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple search tool with one parameter and no output schema, the description adequately covers the essentials: what it does and what it returns. It lacks only optional details like result limits or error behavior, but these are not critical for typical usage.
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 provides 100% coverage with a detailed description of the 'query' parameter, including examples. The tool description adds little beyond the schema, merely restating that search is by code or title. The baseline of 3 applies since the schema fully documents the parameter.
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 uses a specific verb ('Search') and identifies the exact resource ('NTU modules'), clearly distinguishing it from sibling tools like sg_nus_modules and sg_company_search. It also enumerates the returned fields, leaving no ambiguity about the tool's function.
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 makes clear this is the tool for searching NTU modules by code or title, providing immediate context. It does not explicitly name alternatives or state when not to use it, but the NTU focus is unambiguous and differentiates it from similar tools.
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, the description carries the full burden. 'Get locations' implies a read-only operation, and the 'no key needed' note discloses an important access condition. However, it does not describe potential response format, rate limits, or data freshness, leaving some behavioral aspects opaque.
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, front-loaded sentence that immediately states the tool's purpose. Every word adds value, and there is no redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no parameters and no output schema, the description adequately communicates the core function and access requirements. It could be more explicit about the return shape (e.g., coordinates vs. addresses), but the current level of detail is sufficient for a simple lookup tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so the schema provides complete coverage vacuously. The baseline for zero parameters is 4, and the description does not need to add parameter semantics. It correctly focuses on the tool's output rather than inputs.
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 states a specific verb ('Get') and resource ('locations of available taxis in Singapore'), clearly distinguishing it from sibling tools like sg_bus_arrival or sg_traffic_incidents. The mention of the data source (data.gov.sg) adds clarity about the provenance.
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 taxi location queries and notes 'no key needed,' but it does not explicitly state when to use this tool versus alternatives. It provides context about accessibility but no exclusions or comparisons to sibling tools.
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, the description carries the transparency burden. It discloses that the tool's behavior varies by period and gives a high-level description of the data returned. However, it omits details such as data source, update frequency, units, and response structure, which would improve behavioral prediction.
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 brief, front-loaded with the main purpose, and efficiently packs the period distinctions into one sentence with no filler.
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 tool with a single parameter and no output schema, the description covers the selection of period but does not describe the response format, units, or data fields. This leaves the agent uncertain about what to expect in the return value.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already documents the period enum with descriptions, and the tool description adds richer semantics by specifying exactly what each period provides. The default value is also clear. This goes beyond the schema's baseline.
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 gets Singapore weather forecast and enumerates the three forecast periods with their specific outputs, distinguishing it from weather-related siblings like sg_rainfall and sg_air_quality.
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 usage context by explaining what each period option yields (2h per-area, 24h temp/humidity overview, 4day outlook), which guides period selection. However, it does not explicitly discuss when to choose this tool over related weather tools like sg_rainfall or sg_air_quality.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the key behavioral trait of 'SHOWCASE MODE (sandbox data)', indicating that the tool returns non-production test data. This is valuable beyond the name/schema since no annotations are provided. It doesn't mention permissions or read-only nature, but 'Get' implies a safe read operation, and the sandbox caveat is the most critical transparency point.
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 sentence with two clear parts: the purpose and the sandbox caveat. It is front-loaded with the main action and resource, and the emoji notation effectively highlights the showcase mode without excessive words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description lists expected output fields (flat type, address, ownership details), giving the agent a reasonable expectation of return values. The sandbox caveat informs about data quality. The tool's simple scope (one optional parameter) makes this level of detail sufficient, though it could mention error handling or a more explicit note that data is linked to the NRIC.
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 only parameter nric is fully described in the schema ('NRIC/FIN number') with a default value and no required flag. The description does not add additional meaning to the parameter, and since schema coverage is 100%, the baseline score of 3 is appropriate.
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 verb 'Get' and the specific resource 'HDB ownership and housing information', listing example fields such as flat type, address, and ownership details. This distinguishes it from sibling tools like sg_myinfo_person and sg_myinfo_cpf, and from sg_hdb_prices which focuses on pricing rather than ownership.
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 by specifying the domain (HDB ownership and housing info), making it evident when this tool should be used. However, it does not explicitly mention alternatives or when not to use it, such as comparing with sg_myinfo_person for personal data or sg_hdb_prices for housing prices.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the sandbox nature ('SHOWCASE MODE (sandbox data)') which is a key behavioral trait, and lists the returned fields. It doesn't discuss side effects or auth, but as a read-only getter, the sandbox disclosure is the most important 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, front-loaded sentence that directly states the purpose and includes the critical sandbox note. Every word earns its place without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool with no output schema, the description covers the purpose, output fields, and the sandbox behavior. It is adequately complete for an AI to invoke correctly, though it could clarify how to interpret 'pass status'.
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% (nric is described as 'NRIC/FIN number' with a default). The description adds no additional parameter meaning beyond what the schema already provides, so baseline 3 is appropriate.
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 'Get passport and travel document information' with specific fields (passport number, expiry date, pass status). This distinguishes it from siblings like sg_myinfo_person and sg_myinfo_cpf by focusing on travel documents.
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 '🎭 SHOWCASE MODE (sandbox data)' note provides clear context that this is meant for sandbox/demo use, signaling when it's appropriate to call. It doesn't explicitly mention alternatives, but the context is clear for a MyInfo family tool.
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, the description must disclose behavioral traits itself. It adds context about freshness ('real-time') and coverage ('76 weather stations'), but does not describe output format, update intervals, or any potential caveats. The read-only nature is implied by 'Get', but not explicitly stated.
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 one concise sentence with no filler, front-loading the purpose and key attributes. Every part is informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter read tool, the description covers the key aspects: what data, where, freshness, and coverage. It omits the response structure, but given the simplicity and the lack of an output schema, the description is largely adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema is trivially complete. The description adds no parameter-specific behavior, but none is needed; the baseline for zero-parameter tools is 4.
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 retrieves real-time rainfall readings across Singapore, naming the specific resource and geographic scope. This distinguishes it from sibling tools like sg_weather or sg_air_quality, which cover other data domains.
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 implies usage for rainfall-specific queries, with 'real-time rainfall readings' making the use case explicit. However, it does not explicitly mention alternatives or exclusions, such as 'for general weather use sg_weather', leaving that distinction implicit.
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?
No annotations are provided, so the description carries the burden. It discloses that the tool performs a status check and provides links for missing keys, but does not explicitly state that it is read-only or describe the response format. More detail on return structure or side effects would improve transparency, but the described behavior is inherently benign.
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 front-loads the primary action ('Check configuration status') followed by a secondary benefit. Every word earns its place, with no fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having no output schema or annotations, the description is reasonably complete for a simple, parameterless status tool. It tells the user what to expect (configuration status and missing-key links). However, a brief note on the output format or how to interpret the status would make it fully self-contained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the description is not required to explain parameter semantics. The baseline of 4 applies because no parameter documentation is needed, and the description does not introduce any confusing parameter-related ambiguity.
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 a specific verb ('Check') and resource ('configuration status for all SG Gov MCP tiers') plus an additional action ('get links for missing API keys'). This distinguishes it strongly from sibling tools, which are all data-fetching tools, making the purpose unambiguous.
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 implies usage context (during setup or when needing to verify API key configuration) and clearly defines the tool's scope ('all SG Gov MCP tiers'). It does not explicitly name alternatives or exclusion conditions, but given the unique role among siblings, no such guidance is necessary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/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 discloses the authentication requirement (SG_LTA_KEY) and a behavior (shows next 3 buses per service), which are useful beyond the schema. It doesn't cover all edge cases, but for a read-only tool this is sufficient.
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 two concise sentences: first states the primary purpose and output limit, second gives key requirement and practical examples. No filler, all information is high-value and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with two parameters and no output schema, the description explains the output ('next 3 buses per service') and required key. It could add more detail about the exact response structure, but given low complexity, this is adequately complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% of parameters with descriptions, so baseline is 3. The description adds value by providing concrete example values for bus_stop_code (83139, 46009), which aids in selecting real stops. It doesn't deeply elaborate on service_no, but the schema already explains it as an optional filter.
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 a specific action ('Get real-time bus arrival times at a bus stop') and differentiates from sibling tools by specifying the resource (bus arrivals) and output scope (next 3 buses per service). This immediately distinguishes it from MRT, taxi, and other transport tools.
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 for use: real-time bus arrival times, with a required API key and common bus stop examples. It does not explicitly mention when not to use it or name alternatives, but the resource specificity makes the usage context clear enough without needing explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/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 adds useful context beyond the function name: the hourly frequency and the interpretation scale (0-2 Low, etc.). It does not detail data source or update timing, but for a simple 0-parameter read tool, this is sufficient.
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 two short sentences. The first states the action and resource, the second gives the value scale. Every word earns its place, no fluff or repetition of the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 params, no output schema, no annotations), the description covers the core semantics: what it returns (hourly UV index readings) and how to interpret them. It does not specify the exact output structure (e.g., array of timestamps), but this is a minor gap for such a straightforward tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema coverage is 100% (trivially). The description does not need to explain parameters. Baseline for 0 parameters is 4, and the description adds no unnecessary parameter-related info.
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 uses a specific verb and resource: 'Get Singapore UV index readings (hourly)'. This clearly identifies the tool's function and distinguishes it from sibling tools like sg_weather or sg_air_quality, which focus on different data types.
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 makes the use case obvious (retrieving UV index readings), providing clear context within the Singapore data tool ecosystem. However, it does not explicitly state when not to use it or mention alternatives, so it falls just short of a 5.
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:

[![sg-mcp-server MCP server](https://glama.ai/mcp/servers/DarKSanjan/sg-mcp-server/badges/card.svg)](https://glama.ai/mcp/servers/DarKSanjan/sg-mcp-server)

Score Badge

Copy to your README.md:

[![sg-mcp-server MCP server](https://glama.ai/mcp/servers/DarKSanjan/sg-mcp-server/badges/score.svg)](https://glama.ai/mcp/servers/DarKSanjan/sg-mcp-server)

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/DarKSanjan/sg-mcp-server'

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