ph-civic-data-mcp

Server Quality Checklist

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

Latest release: v1.0.4
Disambiguation4/5
Most tools have distinct purposes (e.g., weather forecast vs alerts vs typhoons), but several earthquake-related tools (get_earthquake_bulletin, get_latest_earthquakes, get_usgs_earthquakes_ph) could be confused without careful reading. The PSGC-related tools (resolve, list, hierarchy) and PSA workflow tools (browse, describe, query) are clearly separated.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern (get_, search_, summarize_, assess_, flag_, resolve_, list_, browse_, describe_, query_). No mixed casing or stylistic deviations. The naming convention is uniform and predictable.
Tool Count3/5
At 32 tools, this exceeds the typical well-scoped range, but the server's broad mandate (Philippine civic data across PSA, PAGASA, PHIVOLCS, PhilGEPS, and more) justifies many of them. Still, some consolidation could reduce count without losing functionality.
Completeness5/5
The tool surface comprehensively covers multiple domains: geology, weather, socioeconomic statistics, infrastructure, procurement, location, and environmental data. It includes CRUD-like operations, search, summaries, and multi-step workflows (e.g., browse-describe-query for PSA), leaving no obvious dead ends for the stated civic data purpose.
Average 4.2/5 across 32 of 32 tools scored. Lowest: 3.4/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 8 commits in the last 12 weeks
- Last stable release on August 6, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
This repository includes a glama.json configuration file.
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

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false. The description adds that the data comes from PSA and that the latest vintage is 2023 Full-Year, giving useful temporal context. However, it does not describe output format or any filtering behavior beyond what annotations and schema already cover.
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, front-loading the core information (data type, source, recency). There is no wasted text, and it is easy to scan 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?
The tool is simple with one optional parameter, strong annotations, and an output schema (as indicated by context). The description covers the data source and latest year, which is sufficient for basic usage. It could mention regional filtering explicitly, but the schema already handles that.
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%; the 'region' parameter has a clear description: 'PH region (None returns national).' The tool description adds no parameter-specific information, so the schema carries the full burden for parameter semantics.
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 states 'Poverty incidence from PSA', which clearly identifies the data topic and source. Combined with the title 'Philippine poverty incidence', it distinguishes this from sibling tools about population, inflation, etc., though it lacks an explicit verb like 'retrieve' or 'get'.
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 description does not mention any excluded use cases or suggest alternative tools, leaving the agent to infer suitability solely from the name.
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?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false, so no safety disclosure is needed. The description adds the data source (PSA OpenSTAT) and census year (2020), which provides useful context about data provenance and recency. However, it does not mention the openWorldHint implications or any rate limits/auth requirements, which would add further 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 is a single, focused sentence that front-loads the core purpose and key details (source and vintage). There is zero redundant language, and it is appropriately sized for a simple read-only tool.
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 low tool complexity, comprehensive schema descriptions, and presence of an output schema, the description is complete enough for selection. It conveys the essential data content and provenance. However, it could have benefited from mentioning that region filtering is available, but that is already in the schema, so the description adds sufficient value.
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 both parameters fully (year and region) with descriptions, including that year is ignored. The tool description adds no extra parameter detail beyond what the schema already provides, so it does not go beyond the baseline for 100% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource as Philippine population data from PSA OpenSTAT, specifically the 2020 Census. This distinguishes it from sibling tools like get_poverty_stats or get_inflation_stats by domain. However, the description lacks an explicit verb, relying on the tool name 'get' to convey the action.
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 intended use is implied by the tool name and description (for population data), but there is no explicit guidance on when to use this tool versus alternatives like get_data_freshness or other statistical tools. No when-not-to-use scenarios or alternative tool mentions are provided.
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?
Annotations already declare the tool as read-only, idempotent, and non-destructive, so the description does not need to repeat these. It adds a useful behavioral detail about the parent_code=None case and the 'children' relationship. However, it does not disclose potential error behaviors, rate limits, or any other side effects beyond the schema, so transparency is adequate but not exceptional.
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 immediately communicates the tool's function and the key special case. There is no redundancy or filler; every word adds value.
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?
The tool is simple and the schema is thorough, with all parameters explained and an output schema present. The description covers the primary use cases (browsing children or listing top-level regions) adequately. A brief note distinguishing it from related tools like get_location_hierarchy would improve completeness, but for the given complexity, it is nearly 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 input schema provides descriptions for all four parameters (level, limit, offset, parent_code), including the special behavior of parent_code=None returning regions. The tool description adds no additional parameter meaning beyond what the schema already covers. With 100% schema coverage, 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 clearly states the tool browses children of a PSGC node, and explicitly handles the case where parent_code is None to return top-level regions. It specifies the resource and scope concisely. However, it does not explicitly differentiate from sibling tools like get_location_hierarchy or resolve_ph_location, so it misses the full mark for purpose clarity.
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 navigating the administrative hierarchy by providing a parent_code or omitting it to get regions. It does not provide explicit when-to-use or when-not-to-use guidance, nor does it mention alternatives. The conditional statement about parent_code is helpful but insufficient for clear 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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds valuable behavioral context by explaining that the tool accepts both WB codes and friendly aliases, giving concrete examples. This goes beyond the schema and annotations, though it doesn't detail rate limits 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 two sentences, front-loaded with the core purpose. The first sentence states the resource domain, and the second provides input syntax with examples. 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?
For a simple tool with two parameters, one required, and an output schema, the description covers the essential input semantics. It doesn't explain output structure, but that's covered by the output schema. It also doesn't mention pagination limits or error handling, but the schema and annotations cover safety. Overall, it's sufficient for an agent to correctly select and invoke the 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?
Schema coverage is 100% for both parameters, so baseline is 3. The description enhances this by providing concrete alias examples (e.g., 'gdp', 'poverty_ratio'), which bridge the gap between abstract schema descriptions and practical use. The per_page parameter is already well described in the schema, so the description adds value for the indicator parameter.
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 states the resource is a 'World Bank macroeconomic/social indicator for the Philippines' and clarifies that it accepts indicator codes or friendly aliases. The verb 'get' is in the tool name, and the examples (e.g., 'NY.GDP.MKTP.CD', 'gdp') make the function clear. It is distinguishable from siblings that target specific data sources like PSA or specific indicators, though it doesn't explicitly contrast with them.
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 gives input examples but provides no explicit guidance on when to use this tool versus alternatives like get_poverty_stats or get_inflation_stats. There is no mention of exclusions, prerequisites, or preferred scenarios. The usage context is only implicitly inferred from 'World Bank' and the sibling set.
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?
Annotations already provide the safety profile (readOnlyHint, idempotentHint, destructiveHint). The description adds the 'latest' recency behavior and source, but doesn't disclose pagination or return format. No contradiction with annotations.
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 with no unnecessary words. It front-loads the action and is immediately understandable.
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 tool (3 parameters, output schema, rich annotations), the description is nearly complete. It could mention differences from get_earthquake_bulletin or filtering options, but the schema fills those gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with all three parameters (limit, region, min_magnitude) described in the schema. The description itself adds no parameter information, so baseline 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 'Get the latest earthquake events from PHIVOLCS,' with a specific verb and resource. It distinguishes itself from siblings like get_usgs_earthquakes_ph by naming PHIVOLCS as the source.
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 PHIVOLCS qualifier implies when to use this tool (for PHIVOLCS data), but there is no explicit guidance on when not to use it or alternatives for other earthquake sources. This is implied usage rather than clear 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?
Annotations already declare this as a read-only, non-destructive, and idempotent operation. The description adds the 'fuzzy' behavior, indicating approximate matching, which is helpful. However, it does not disclose how ambiguity is handled (e.g., multiple matches) or what happens when no match is found.
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 essential purpose without extraneous detail. Every word adds value, making it highly concise and well-structured.
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 (one parameter), the presence of the output schema, and comprehensive annotations, the description is largely complete. It does not explicitly address edge cases like no-match behavior, but the output schema likely covers the return format, so only a minor gap exists.
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 for the single 'query' parameter, including detailed examples. The tool description does not add additional parameter semantics beyond what the schema already documents, so a 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: 'Fuzzy-resolve a Philippine place name to its canonical PSGC record.' This specifies the action (fuzzy-resolve), the input (a Philippine place name), and the output (a canonical PSGC record), distinguishing it from sibling tools that focus on data retrieval or statistics.
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 a user needs to convert a free-text place name into a standard PSGC code, but it does not explicitly discuss when to use this tool versus alternatives like get_location_hierarchy or list_admin_units. No exclusions or alternative recommendations are provided.
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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds the temporal constraint of 'latest PhilGEPS window' but does not disclose other behavioral details, such as how the window is determined or whether aggregation includes filtering effects. This adds some value without being 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 sentence that is concise and front-loaded with the action ('Aggregate'). Every word contributes without filler, making it easy 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?
Given the presence of a full output schema and strong annotations, the description is mostly sufficient. It clearly states the core purpose, but leaves domain-specific terms like 'PhilGEPS window' undefined and does not clarify aggregation granularity. These gaps are partially mitigated by the schema and structure.
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 parameters with descriptions, including the special note that funding_source is a no-op. The tool description itself adds no parameter-specific meaning, so 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 uses a specific verb 'aggregate' and clearly identifies the resource 'infrastructure procurement statistics' with an explicit scope ('over the latest PhilGEPS window'). This differentiates it from siblings like search_procurement and get_procurement_summary, which focus on searching or general procurement summaries.
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?
No explicit when-to-use or alternative guidance is given. The purpose implies it is for summarizing infrastructure spending, but there is no direction on when it should be preferred over similar sibling tools like get_procurement_summary. This 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is fully disclosed. The description adds 'full bulletin' but doesn't elaborate on behavior such as error handling or content details, which is acceptable given the read-only nature and existing annotations.
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?
One sentence, zero waste. It communicates the tool's purpose and scope efficiently.
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 fetch-by-URL tool with one parameter, an output schema, and strong annotations, the definition is sufficient. The workflow linking to get_latest_earthquakes is clear, though the description doesn't mention what the full bulletin contains.
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%, and the bulletin_url parameter is well-described as the output of get_latest_earthquakes, so the schema carries the semantic weight. The main description adds no additional param guidance, maintaining the baseline for high 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 uses a specific verb ('Get') and resource ('full bulletin') and scopes it to 'PHIVOLCS earthquake event', clearly distinguishing it from the list-oriented get_latest_earthquakes and the USGS-based sibling tool.
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 alone implies usage for a specific event, but the schema parameter description explicitly states the bulletin_url must be the full URL returned by get_latest_earthquakes, establishing a clear workflow. It doesn't name alternatives or exclusions, but the coupling with get_latest_earthquakes provides sufficient context for correct selection.
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?
Annotations already declare readOnly, idempotent, and non-destructive behavior. The description adds the significant behavioral detail that data comes from 'latest notices cached from PhilGEPS', indicating potential staleness and that this is not a live query. This adds value beyond the annotations without contradicting them.
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 of 10 words. It states the verb and resource immediately, with no redundant phrasing or extraneous details. 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 presence of annotations, an output schema, and a fully described parameter schema, the description is reasonably complete. It adds the cached-data context, which is essential for setting expectations. Minor additional detail about the output statistics could be useful, but the output schema mitigates this gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage, with each parameter (year, agency, region) already described in the schema. The tool description adds no additional parameter semantics, which meets the baseline for a schema-heavy tool.
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 ('Aggregate') and resource ('procurement statistics') with a clear data source ('latest notices cached from PhilGEPS'). This clearly distinguishes it from sibling tools like search_procurement (searching individual notices) and summarize_infra_spending (infrastructure spending), leaving no ambiguity about its purpose.
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 a summary use case through the verb 'Aggregate', but it offers no explicit guidance on when to use this tool versus alternatives like search_procurement. There are no exclusion criteria or alternative references, so the usage context must be inferred from the 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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is well covered. The description adds minimal behavioral information beyond the core function, but this is adequate given the annotations.
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 conveys the tool's purpose with no wasted words or extraneous detail.
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?
The tool is simple with one optional parameter, and the input schema plus output schema fill in important details like the parameter behavior and return structure. The description itself is sufficiently complete for an agent to understand when and how to use the tool, though it could be slightly more explicit about the optional parameter's effect, which is already covered in the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the volcano_name parameter fully documented including examples and null behavior. The tool description does not add any parameter-specific meaning beyond what the schema provides, so a baseline 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 'Get' and clearly states the resource as 'current alert level for Philippine volcanoes'. This distinguishes it from sibling tools like earthquake and weather tools, leaving no ambiguity about its 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 the tool's context very clear: it is for volcano alert levels in the Philippines. While it does not explicitly name alternative tools or state when not to use it, the purpose is unambiguous and the context is sufficient for a simple data retrieval 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?
Annotations already disclose read-only, idempotent, and non-destructive behavior, lowering the description's burden. The description adds 'full record' but does not explain the openWorldHint or potential partial data behavior, so it provides only minimal extra transparency beyond annotations.
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?
A single, well-structured sentence directly states the action, resource, and parameter. 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.
Completeness5/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 parameter), rich annotations, and presence of an output schema, the description sufficiently sets expectations. It explains the core purpose without needing to elaborate on return values or additional behavior.
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%, and the schema already documents project_id as 'Reference number from search_infra_projects'. The description's 'by project_id' adds no new semantic detail, meeting the baseline but not exceeding 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 specifies the verb 'Return' and the resource 'full record for one infrastructure project', uniquely identifying a detail retrieval operation. This distinguishes it from sibling tools like search_infra_projects (searching) and summarize_infra_spending (aggregation).
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 parameter description explicitly notes the project_id is a 'Reference number from search_infra_projects', implying this tool is the follow-up detail lookup after a search. However, it does not explicitly state when not to use it (e.g., for lists or summaries), so it lacks full exclusion guidance.
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?
Annotations already declare the tool safe (readOnly, idempotent, non-destructive). The description adds valuable behavioral context: the data source (NASA POWER), the specific variables returned, and the daily temporal granularity. This goes beyond what annotations provide, though it does not mention potential limitations or date-range constraints.
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 tight paragraphs: first establishes the core function, second lists returns and use cases. Every sentence provides useful information with no fluff. The structure front-loads the main purpose and uses bullet-style clarity in prose.
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 an output schema present, the description need not explain return formats. It covers the tool's purpose, variables, units, source, and application areas, which is sufficient for a read-only data retrieval tool. A slight gap is the absence of any mention of date-range behavior or limitations, but annotations and schema fill some of that.
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 minimal parameter-level detail beyond the schema, only implying lat/lon via 'any coordinate' and daily data via 'daily'. No additional syntax or format guidance is given, so it does not elevate the score.
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 the tool returns daily solar irradiance and climate variables from NASA POWER for any coordinate, listing specific variables and units. This clearly identifies the resource (NASA POWER) and the scope, distinguishing it from sibling tools like weather forecast or 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?
Explicit use cases are provided ('solar energy siting, agricultural planning, historical climate analysis'), giving clear context for when to use the tool. However, it does not explicitly contrast with alternative siblings (e.g., get_weather_forecast for forecasts), so it lacks exclusionary guidance.
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?
Annotations already disclose readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds valuable behavioral context beyond annotations: NDVI range (-1..1), EVI's sensitivity in high-biomass areas, 16-day composite period, and 250m resolution. No contradictions with annotations.
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 compact and efficiently organized: one core statement, then definitions of NDVI/EVI, then resolution and use cases. Every sentence adds value with no redundancy or 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?
The description covers the product details, index interpretations, resolution, and practical applications. Since an output schema exists, not describing the return format is acceptable. It could mention date range behavior or data caveats, but overall it is complete for a read-only point query tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with clear descriptions for all four parameters, including WGS84 for coordinates and ISO dates with defaults. The description itself does not add parameter-specific details, but the schema handles this fully. 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 it returns NDVI and EVI vegetation index from NASA MODIS MOD13Q1 at any coordinate. It distinguishes itself from all sibling tools, which cover different domains like weather, earthquakes, and poverty. The data source and indices are specific, avoiding tautology.
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 gives explicit use cases: 'agricultural monitoring, deforestation tracking, drought stress indicators.' This provides clear context for when to use the tool. However, it does not mention alternatives or exclusions, and there are no direct sibling tools for vegetation index, so the lack of explicit 'when not to use' is not a major gap.
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?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so safety profile is clear. The description adds the non-obvious behavioral detail that it switches between PAGASA TenDay API and Open-Meteo based on the PAGASA_API_TOKEN environment variable. This is valuable context beyond annotations, though it does not describe output format or data update 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 two sentences, front-loaded with the main purpose, followed by the API selection note. Every word earns its place, and there is no redundant or vague phrasing. It is an exemplary concise description.
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 2-parameter tool with full schema coverage, an output schema, and strong annotations, the description is nearly complete. It covers the main purpose, the location scope, and the API source behavior. It does not specify units or forecast elements, but these are likely covered by the output schema, and no critical gaps are apparent for an agent to invoke the tool correctly.
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%: both 'days' and 'location' are described in the input schema. The description does not add extra meaning beyond what the schema provides, but it does not need to because the schema is self-sufficient. The description's phrase 'Philippine location' aligns with the schema's 'Municipality, city, or province name' without adding detail.
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 opens with a specific verb+resource+scope: 'Get weather forecast for a Philippine location.' This clearly distinguishes it from sibling tools like get_weather_alerts (alerts) and get_active_typhoons (typhoons). The title 'Philippine weather forecast' reinforces the purpose.
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 by stating it is for weather forecasts in the Philippines, which is clear enough to guide selection. It does not explicitly mention alternatives or when-not-to-use cases, but the clear domain and tool name make the intended use obvious. The note about API choice provides additional context for when the tool might behave differently.
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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the agent knows this is a safe read operation. The description adds minimal behavioral context beyond the purpose—it notes the codes 'live here' but doesn't describe output details, pagination, or error behavior. It is consistent with annotations but does not significantly enhance transparency beyond them.
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 concise sentences. The first sentence states the core function, and the second provides essential usage guidance. There is no waste or redundancy, and the most important information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/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 parameter, read-only) and the presence of a detailed input schema and an output schema, the description is complete. It explains the tool's role in the broader workflow, including its relationship with query_psa_dataset and browse_psa_catalog, leaving no critical gaps for an AI agent to resolve.
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 description for 'dataset_path' is already highly informative, covering the relative path format, an example, and where to find the value (from the 'path' field of browse_psa_catalog). The tool description does not add any extra parameter meaning. With schema_description_coverage at 100%, 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 verb 'Read' and specifies the resource: 'dimensions and valid value codes of one PSA OpenSTAT dataset.' It distinguishes this tool from siblings like query_psa_dataset (which queries data) and browse_psa_catalog (which browses the catalog). This is a specific, unambiguous purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Call this before query_psa_dataset' and explains why: 'The query tool needs an explicit value code for every dimension, and those codes live here.' This provides clear when-to-use guidance and references a specific alternative, making the usage context unmistakable.
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?
Annotations already indicate read-only, idempotent, non-destructive behavior. The description adds value by specifying the data source (Open-Meteo, no API key), the exact pollutants and AQI categories returned, and the ~80 city coverage limitation. It does not mention error handling or rate limits, but the added context suffices.
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 sentences, front-loaded with the core function, then return details and limitations. No redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With output schema present and rich annotations (read-only, idempotent), the description sufficiently covers data source, return items, and scope. Limitation about unlisted locations is also disclosed. No major gaps for a single-parameter lookup tool.
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 covers the single parameter (location) with examples, so baseline is 3. The description reinforces that location must be a Philippine city and adds coverage limitations, but does not fundamentally extend the parameter's semantic meaning.
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 returns real-time air quality for a Philippine city, listing specific pollutants and AQI metrics. It distinguishes itself from weather-related siblings by focusing on air quality data.
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 provides clear context: use for Philippine city air quality, covers ~80 major cities, and notes a limitation for unlisted locations (future coordinate support). It does not explicitly name alternative tools for other data types, but the purpose is unambiguous.
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?
Annotations already establish read-only, idempotent, non-destructive behavior. The description adds meaningful functional transparency: place resolution to PSA code, composition of six data domains, and derived cross-source context. It does not contradict any annotation.
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 compact paragraphs, front-loaded with a one-line summary. It then details the aggregation scope and derived value without extraneous content. Every sentence contributes to the agent's understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex multi-source aggregator with an output schema, the description covers the full scope of data included and the value of derived normalization. The agent has enough context to invoke correctly without needing to know every output field.
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% and the schema already describes the 'location' parameter thoroughly with examples. The description adds no additional parameter-level details beyond mentioning PSA code resolution, which is tool behavior rather than parameter semantics. 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 clearly states the tool's purpose with specific verbs ('resolves', 'composes') and identifies it as a one-call aggregator for a civic profile. This distinctly differentiates it from the extensive list of single-purpose sibling tools like get_poverty_stats, get_weather_forecast, and assess_area_risk.
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 explicitly says it replaces 'eight' separate calls, providing a clear alternative. It implies use when a comprehensive overview is needed, though it does not explicitly state exclusions (e.g., 'don't use if you need only weather'). The guidance is strong but not exhaustive.
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?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds meaningful behavioral context: the data is from the latest published reference period and the region argument is a caveat only, as the table has no regional breakdown. This goes beyond annotations and prevents misuse.
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 concise and well-structured: a short opening sentence identifies the tool, the next sentence lists the outputs, and a final sentence explains the important caveat. Every sentence adds value, with no fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple parameter set, presence of annotations and output schema, and the detailed caveat, the description is complete. It specifies the type of indicators, the national scope, and the region handling, which is sufficient for an agent to invoke the tool correctly.
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%, and the schema already fully explains the 'region' parameter, including its purpose as a caveat for API symmetry. The description restates this information but does not add new semantic detail beyond what the schema provides. 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 the tool returns Philippine labor-force indicators from the PSA Labor Force Survey, and enumerates the specific rates (participation, employment, unemployment, underemployment). This specific verb+resource differentiates it from sibling tools like get_poverty_stats or get_inflation_stats.
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 on what data is returned and emphasizes the national scope, which helps an agent know when to use it and what to expect. It does not explicitly name alternative tools or exclusions, but the distinction from siblings is implicit and sufficient for this single-purpose tool.
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?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false. The description adds behavioral insight about the return structure (the chain of administrative levels), which is valuable beyond annotations. It does not contradict annotations, and there are no hidden side effects implied.
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 action and output. It contains no filler, and every word contributes to clarifying the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has a simple one-parameter schema, a clear output schema, and strong annotations (read-only, idempotent, open-world), the description fully covers the necessary context. It explains the hierarchical chain, and since an output schema exists, return value details are not required.
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 for the parameter is 100% since the input schema includes a description for psgc_code ('9-digit PSGC code (leading zeros optional)'). The description reinforces that it takes one PSGC code but adds no additional semantic detail beyond the schema, so the 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 the tool returns the full hierarchy chain (region -> province -> city/municipality -> barangay) for a single PSGC code. It uses a specific verb ('Return') and resource ('full chain'), and the hierarchical scope distinguishes it from location-related siblings like list_admin_units and resolve_ph_location.
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 clear usage context: use this when you need the complete administrative hierarchy for one PSGC code. It does not explicitly mention when not to use it or alternatives, but the context is sufficient given the focused single-code input and the explicit chain output.
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?
Annotations already declare readOnly, openWorld, and idempotent, so the bar is lower. The description adds valuable context: bounding box coordinates, USGS data source, magnitude types (Mww/Mwc), and depth solutions. This goes beyond basic annotations, though it does not address potential data gaps or latency, which openWorldHint partially covers.
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 primary purpose, followed by scoping and relational details. Every sentence 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.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the rich schema (100% parameter coverage), existing output schema, and strong annotations, the description fully covers the tool's scope, source, and differentiation. It is complete for a read-only query tool, and no critical context is missing.
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%, and all parameters (limit, start_date, end_date, min_magnitude) are well-described in the schema with defaults and meanings. The tool description does not add parameter-specific details, so 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 returns Philippine-region earthquakes from USGS, with a specific bounding box and cross-reference to PHIVOLCS, including international-standard magnitudes. This distinguishes it from sibling tools like get_earthquake_bulletin and get_latest_earthquakes by emphasizing its global-network analysis and USGS sourcing.
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 on when to use the tool: when you need USGS cataloged events with international-standard magnitudes, complementing PHIVOLCS data. It implies a distinction from PHIVOLCS-based tools but does not explicitly name alternatives or provide when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite having readOnlyHint and idempotentHint annotations, the description adds significant behavioral context by disclosing parallel upstream calls and a 3-6 second response time. This goes beyond the annotations and helps the agent set expectations for latency and internal operations.
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 compact and front-loaded, with two short paragraphs. The first states the tool's purpose, and the second adds practical operational details. Every sentence contributes value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a single, fully documented parameter, an output schema, and comprehensive annotations. The description explains the multi-hazard nature and gives performance expectations, which is sufficient for a snapshot tool. Returning value details are covered by the output schema, so no further description is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already fully describes the single 'location' parameter as 'Municipality, city, or province name' (100% coverage). The description adds no additional parameter-level details beyond the schema, so it meets the baseline without enhancing semantics.
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 provides a 'Multi-hazard risk assessment combining PHIVOLCS + PAGASA', which is specific and distinct from sibling tools by aggregating earthquake, volcano, typhoon, and weather alert data. The verb 'assess' and the resource 'area risk' are explicit, and the multi-hazard integration differentiates it from single-source tools like get_volcano_status.
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 a comprehensive hazard snapshot by listing the data sources (PHIVOLCS and PAGASA) and mentioning parallel calls. It does not explicitly exclude alternatives or state when not to use it, but the context makes the intended use clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, covering safety traits. The description adds valuable behavioral context beyond annotations by emphasizing that the tool traverses the catalog 'one level at a time', implying the need for repeated calls to go deeper. This is a non-obvious behavior not captured in the annotations and is clearly disclosed. No contradiction exists.
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 short sentences, each earning its place. The first sentence states the core functionality, and the second provides essential context about the catalog's scale and navigation strategy. 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.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple single-parameter interface, the rich parameter description in the schema, and the presence of annotations and an output schema, the description is complete. It addresses the tool's purpose, behavior, and usage context without needing to explain return values (handled by the output schema) or safe-read characteristics (handled by annotations). An agent can correctly decide when to invoke this tool and how to use it.
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 100% coverage with a detailed description of the 'path' parameter, including examples and the behavior of null/empty values. Therefore, the description does not need to elaborate further. It adds only incidental context about the catalog size (2,900 tables, 27 subjects) which helps understand the purpose of the path parameter but does not directly explain its syntax or semantics 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 states 'List one level of the PSA OpenSTAT statistical catalog' with a specific verb and resource. It clearly differentiates from sibling tools like describe_psa_dataset and query_psa_dataset by focusing on catalog navigation rather than dataset details or querying. The additional context about walking the tree one level at a time makes 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 explains when to use the tool: 'so an agent can find a dataset without guessing a table id'. This provides clear contextual guidance for discovery use cases. However, it does not explicitly name alternatives or state when not to use it, such as mentioning that describe_psa_dataset should be used once a dataset ID is known. Without exclusions or explicit alternative references, 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the description does not need to restate safety. It adds value by disclosing the tool doubles as the canonical version/health endpoint and by explaining the semantics of the returned fields (e.g., freshness and cache_ttl_seconds for cache decisions). This complements annotations without contradiction.
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 efficiently structured: a one-line summary, a paragraph explaining the dual purpose, and a clear list of return fields. Every sentence contributes meaning (e.g., how to use the freshness info, what the response contains). It is front-loaded and not padded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the description provides sufficient context: it explains the tool's role, the meaning of freshness/TTLs for practical decisions, and enumerates the exact return fields in the sources list. The tool is simple (no params), and the description covers all necessary aspects for an agent to invoke it correctly.
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 baseline is 4. The description adds no parameter-specific semantics because there are none, and the schema already covers everything (100% coverage with empty properties). It appropriately avoids inventing unnecessary parameter details.
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 explicitly states 'Server health + data-source catalog probe' and details the exact outputs (server_version, sources catalog with TTLs, freshness). This clearly distinguishes it from sibling data-retrieval tools which focus on specific datasets (e.g., earthquakes, weather). The verb 'probe' and resource scope are precise.
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 use cases: confirming server release via server_version and deciding whether a stale cached response is acceptable based on source freshness/TTLs. It does not explicitly name alternative tools or state when not to use it, but the context strongly implies its unique role as a health/catalog probe among data tools.
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?
Annotations already declare read-only, open-world, and idempotent behavior. The description adds valuable context about the default response, fuzzy-match behavior, and that the available indicator list is never hardcoded but browse-discovered, which goes beyond the annotation hints.
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 compact, front-loaded with the domain and source, and every sentence adds value. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple one-parameter read-only tool, the description covers the default behavior, parameter semantics, and source. The output schema exists to explain return values, so no additional return details are needed.
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 already describes the parameter well with examples and default. The description adds semantic detail by explaining 'fuzzy-match' and that the list is 'browse-discovered, never hardcoded', informing the agent that exact strings are not required and discovery is possible via other tools.
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 returns 'National health indicators from PSA OpenSTAT' and specifies the default headline set (maternal mortality ratio and total fertility rate). It distinguishes itself from sibling tools by naming the Health subject, making its scope unmistakable.
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 gives clear behavioral guidance: no argument returns the curated set, while a free-text indicator triggers fuzzy matching against Health subject tables. It doesn't explicitly mention alternatives or exclusions, but the health-specific domain naturally distinguishes it from sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations, the description discloses the data source (NOAA IBTrACS), the filtering and aggregation logic (Western Pacific basin + coordinates in PAR, aggregated per storm), and the return values (peak intensity, minimum pressure, track period). These details provide a strong understanding of the tool's 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 compact, well-structured paragraph with three sentences that cover the summary, source, and filtering/aggregation. There is no redundant or filler text; every sentence contributes useful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with only two optional parameters and an output schema, the description covers the essential context: purpose, source, filtering, aggregation, and return fields. It is complete enough for an agent to select and invoke the tool correctly.
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 the baseline is 3. The description adds no extra parameter-level semantics beyond what the schema already provides; it focuses on overall data scope and output rather than explaining year or limit behavior.
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 provides historical tropical cyclone tracks through the Philippine AOR, sourced from NOAA IBTrACS, and returns specific data fields. This distinguishes it from siblings like get_active_typhoons by emphasizing 'historical' rather than current storms.
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 establishes a clear context for when to use the tool—for historical typhoon track data—through the word 'historical' and the geographic scope. However, it does not explicitly mention alternatives or exclusionary guidance, such as 'use get_active_typhoons for current typhoons.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (read-only, idempotent), the description explains that the tool discovers the CPI series by text, never uses a hardcoded table id, and reports the exact reference period with lag awareness. This adds meaningful behavioral context beyond what annotations provide.
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 concise and well-structured, leading with the key result, then source, then behavior. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter read-only tool with a full output schema, the description provides sufficient operational context, including data provenance and lag behavior, making it 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 input schema already fully describes the single 'area' parameter with 100% coverage, including examples and default behavior. The description adds no further parameter details, so a 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 explicitly states the tool returns headline consumer-price inflation (year-on-year, all items) from PSA, and specifies it returns the most recently published month's change. This clearly identifies the resource and scope, distinguishing it from sibling stats 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: it returns the latest published figure, notes the lag, and describes the data source. However, it does not explicitly mention when to use this instead of alternatives or any exclusions, 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds a critical behavioral warning: PXWeb expands unselected dimensions and PSA returns HTTP 403 for full-cube requests. This goes beyond annotations by explaining a failure mode and the reason for the strict requirement.
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, immediately front-loaded with the purpose. Every clause adds critical information: bounded query, need for explicit codes, failure mode. No fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, return values don't need description. The tool has only 3 parameters, and the description covers its essential behavior, the companion tool to use first, and the key failure condition. It is self-contained and sufficient for an agent to invoke correctly.
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 coverage is 100%, so the baseline is 3. The description adds value by emphasizing that selections must cover every dimension and pointing to describe_psa_dataset as the source of valid value codes. This supplements the schema and helps the agent construct correct selections.
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 opens with 'Run one bounded query against a PSA OpenSTAT dataset,' which names a specific verb and resource. It clearly differentiates from siblings like browse_psa_catalog and describe_psa_dataset by focusing on query execution against a dataset.
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 gives concrete guidance: 'Every dimension needs an explicit list of value codes from describe_psa_dataset.' It also frames this as a hard requirement, telling the agent to first call describe_psa_dataset. It stops short of explicitly naming alternatives or exclusions, so it doesn't earn a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnlyHint, idempotentHint, etc.), the description discloses key behavioral traits: the lack of server-side search, fetching only ~100 latest notices, 6-hour caching, and client-side case-insensitive substring matching. This adds significant operational context that helps set expectations about data freshness and filtering 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 concise: one clear purpose sentence followed by a compact note explaining limitations and behavior. Every sentence adds necessary context, and the note is front-loaded with the most important limitation before procedural details.
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 an output schema present and rich annotations, the description covers the critical operational constraints: data source, fetch limit, caching, and filtering approach. It would be more complete if it mentioned date-range parameter handling or explicitly referenced relevant sibling tools, but overall it provides sufficient context for an agent to use the tool effectively.
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 description explicitly explains that keyword/agency/region filters are applied client-side as case-insensitive substring matches, adding meaning beyond the schema. It also clarifies that keyword matches against title + agency + classification. However, the date_from and date_to parameters lack descriptions both in schema and description, which keeps this from a 5.
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: 'Search PH government procurement from PhilGEPS open data.' The verb 'search' plus the specific resource 'PhilGEPS' and object 'procurement notices' makes the purpose unambiguous. It also distinguishes itself from sibling tools like search_infra_projects by focusing on procurement notices.
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 on how the tool operates: it fetches the latest ~100 bid notices and filters them in-memory because PhilGEPS lacks server-side search. This implies appropriate use cases and limits, though it does not explicitly name alternatives or when-not-to-use scenarios relative to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only state read-only, idempotent, non-destructive. The description adds substantial transparency: it explicitly says outputs are 'heuristic anomaly indicators, not accusations', disclaims that patterns may have legitimate explanations, and details each rule's exact behavior, including the caveat that the high-cost rule is a transparency flag, not a project-specific progress finding.
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 front-loaded with the core purpose, then uses a clearly labeled bullet list for the three heuristic rules. Each bullet conveys necessary detail without padding, and the disclaimer about heuristic nature is useful context, making the length justified.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has three parameters, three rules, and an output schema (so return values are already defined). The description fully explains the cross-referencing logic, the meaning of each rule, and the behavioral caveats, making it complete for an agent to invoke correctly and interpret results appropriately.
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 coverage is 100%, so baseline is 3. The description adds extra meaning by explaining min_cost_php's role as 'the threshold for the high_cost_no_published_progress rule', linking it to a specific heuristic. It also clarifies the semantics of the high-cost rule, which is beyond the schema's parameter descriptions.
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 opens with a specific verb-resource pair: 'Flag PhilGEPS infrastructure projects that warrant further review by cross-referencing PHIVOLCS earthquakes and PAGASA typhoon footprints.' This clearly distinguishes the tool from sibling search/summarize tools by its analytical/heuristic purpose and names the exact data sources involved.
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 conveys clear usage context: it flags projects for further review based on hazard overlap and cost/progress signals. It does not explicitly mention when not to use it or name alternative tools, but the detailed heuristic rules effectively imply the intended use case and scope.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnly, openWorld, idempotent, non-destructive), the description discloses key behavioral details: returns empty list if none active, and returns a structured error object if the upstream PAGASA page is unreachable, preventing false negatives. This adds valuable context not conveyable by annotations alone.
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 sentences, front-loaded with the main purpose, followed by two concise behavioral clarifications. Every sentence adds value with no redundancy or extra words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a no-parameter read-only tool with an output schema, the description covers all relevant aspects: what it returns, the empty case, and the failure mode. It fully supports agent decision-making without needing additional context.
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 0 parameters, so the baseline is 4. The description correctly omits parameter details and instead explains output semantics, which is appropriate given no inputs to document.
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 active tropical cyclones in/near the Philippine Area of Responsibility (PAR)'—a specific verb, resource, and geographic scope. This distinguishes it from sibling tools like get_historical_typhoons_ph and get_weather_forecast.
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 context of use is clear: for active tropical cyclones in the PAR. It does not explicitly name alternatives or exclusions, but the description's specificity implies when to use it (e.g., current status, not historical data). Lacks explicit 'use instead of X' guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses important behavioral quirks beyond the annotations: it cannot isolate active warnings from chrome text, and it returns [] with a caveat when state is ambiguous or with an explicit 'no active warnings' signal. This is valuable reliability context that annotations do not provide.
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 compact (about 70 words) yet information-dense. Each sentence adds value: purpose, reliability limitation, return behavior, and an alternative. It is front-loaded with the core purpose and well-structured with a caveat explanation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema and strong annotations, the description provides crucial context about failure modes, ambiguity handling, and the alternative source, making it complete for real-world usage. It covers edge cases (ambiguous state) that structured fields do not.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% — the region parameter is already explained with examples ('e.g. "NCR", "Region VII"...'). The tool description adds no additional parameter information, 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 first sentence, "Get active PAGASA weather alerts and advisories," uses a specific verb and resource, clearly distinguishing this from sibling tools like get_weather_forecast and get_active_typhoons. The scope (active alerts/advisories) is explicit and non-tautological.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when the tool returns [] in ambiguous vs. no-active-warning states, and provides an alternative for real-time advisories: "For real-time advisories, call bagong.pagasa.dost.gov.ph directly." This gives clear when-to-use and when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, open-world behavior. The description adds valuable context: cost_php is null due to unpublished approved budgets, and the DPWH portal is intentionally not used because of Cloudflare blocking, which explains data gaps beyond what annotations convey.
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 sentences, no filler, front-loaded with the main purpose. Every clause earns its place by explaining scope, source, and data limitation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers source, filtering scope, data nullability, and why an alternative API isn't used. With an output schema present and all parameters documented, the description provides sufficient behavioral context for an agent to select and invoke the 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?
All 7 parameters have thorough schema descriptions (100% coverage). The description adds one key behavioral note—that cost_php is null in most records, which directly informs how min_cost_php behaves (filtering out nulls). This supplements, not repeats, 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?
Clearly states it searches Philippine government infrastructure projects, specifying the verb and resource. Distinguishes from siblings like get_infra_project and search_procurement by emphasizing the infra-focused PhilGEPS open notice listing.
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?
Provides clear context about the data source (PhilGEPS) and scope (infra-related work), helping an agent choose this over general procurement search. However, it doesn't explicitly name alternative tools or state when not to use it, so it falls short of full exclusionary guidance.
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:

[![ph-civic-data-mcp MCP server](https://glama.ai/mcp/servers/xmpuspus/ph-civic-data-mcp/badges/card.svg)](https://glama.ai/mcp/servers/xmpuspus/ph-civic-data-mcp)

Score Badge

Copy to your README.md:

[![ph-civic-data-mcp MCP server](https://glama.ai/mcp/servers/xmpuspus/ph-civic-data-mcp/badges/score.svg)](https://glama.ai/mcp/servers/xmpuspus/ph-civic-data-mcp)

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/xmpuspus/ph-civic-data-mcp'

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