tokenguard-mcp

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the burden. It discloses the input format, the lack of need for coordinates, and the free pricing model, plus points to the paid API. It does not detail rate limits, data freshness, or error behavior, but for a simple lookup this is sufficient.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences, front-loaded with core functionality, and includes only relevant extras (free, paid API pointer). No wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a single-parameter lookup tool without an output schema, the description enumerates the return values (pollutants, AQI, band) and explains input expectations. It is sufficiently complete 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.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema already documents the location parameter with an example. The description adds context by stating no coordinates are needed, clarifying the expected input format beyond the schema. This is a meaningful addition, but not extensive.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool returns current air quality data for a place, listing specific pollutants and AQI metrics. It also differentiates from siblings by noting it requires no coordinates, making its purpose distinct from geocoding tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It provides context that a place name is sufficient and that the tool is free, directing users to paid_catalogue for paid API alternatives. However, it does not explicitly contrast with other sibling tools or specify when not to use this tool.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the burden. It provides useful context: data source (World Bank), type (time series), and cost (free). However, it does not disclose response format, error behavior, rate limits, or other execution details, leaving ambiguity for the agent.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise, two sentences. The first sentence front-loads the core purpose. The second sentence about the paid API is somewhat tangential but brief and serves to direct users to paid_catalogue, reducing confusion between free and paid offerings.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the schema fully documents parameters and the description lists valid indicators, the tool is reasonably complete for a read-only data retrieval. However, without an output schema, it doesn't specify return structure, which could be helpful but is not strictly necessary for a simple time series endpoint.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with each parameter described. The description adds the actual list of indicator aliases (gdp, gdp_per_capita, etc.) that the schema refers to as 'Alias above', providing essential value beyond the schema. It also reinforces the years default context.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool retrieves World Bank time series for a country and lists specific indicators (gdp, population, etc.). This distinguishes it from sibling tools like air_quality or earthquakes through the explicit data source and scope.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage context is implied: the tool is for country-level economic indicators. It mentions a free option and directs users to paid_catalogue for paid API routes, offering some guidance on alternative tools, but it doesn't explicitly state when to prefer this tool over other data-related siblings.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the transparency burden. It discloses the data source (USGS), the returned fields (magnitude, depth, tsunami flag, felt reports), and the free status. However, it doesn't address rate limits, error behavior, or whether the data is live, leaving some ambiguity.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The first two sentences are efficient and directly relevant. The third sentence about the paid API is a tangential commercial note, not essential for using this tool, but it's short. Overall, it's concise but not perfectly focused.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple read-only query tool with 5 self-documented optional parameters, the description covers the purpose, scope, and output content. It doesn't need to explain return format since no output schema exists, but it could mention default behavior (though schema has defaults). Overall it's sufficient.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

All 5 parameters are fully described in the schema (100% coverage), so the description doesn't need to add much. It does reinforce that 'location' is a named place and allows radius search, but provides no additional semantics beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool retrieves recent earthquakes from the USGS feed, with options for worldwide or radius-based search. It uses a specific resource and scope, distinguishing it from sibling tools like geocode or elevation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives clear context: use for recent earthquake data, either globally or near a named place. It doesn't explicitly exclude alternatives, but its distinct domain makes the usage context obvious.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden. It discloses that the tool is free, requires no signup, and returns elevation in metres, which is useful. However, it does not mention error behavior or rate limits, though for a simple read-only tool this is acceptable.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences: the first states the core purpose, the second adds monetization context. Every word is purposeful and front-loaded, with no fluff.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a single-parameter tool with no output schema, the description provides sufficient context: it specifies the input type, the unit of the result, and even the cost. It could include an example output or error handling, but overall it is complete enough for successful invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema already describes the only parameter 'location' as 'Place name' (100% coverage). The description adds no additional parameter semantics beyond restating 'place name', so a baseline score of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states 'Ground elevation in metres for a place name' with a specific verb and resource, clearly distinguishing this from siblings like geocode (coordinates) or air_quality. It is concise and unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description clearly implies use for elevation queries and adds operational context (free, no signup). It also directs users to paid_catalogue for a paid API, offering an alternative, though it does not explicitly state when not to use this tool.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

There are no annotations, so the description carries the full burden. It reveals that the tool is free and that a paid API exists, and lists the output fields, but it does not disclose rate limits, response format (beyond the fields), or error behavior. This is adequate but not rich.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences, with the primary purpose stated first and a concise parenthetical about pricing. Every word earns its place, and there is no redundancy or unnecessary detail.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple geocoding tool with no output schema, the description adequately covers input, output fields, and the free/paid distinction. It could add error handling or return structure, but the listed fields serve as a sufficient return description, making it complete enough for practical use.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and both parameters have descriptions. The description adds context by listing the geographic attributes returned, which clarifies the meaning of the `name` parameter, but adds no new syntax or format details for `count`. It meets the baseline without exceeding it.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses the specific verb 'resolve' and names the resource (place name) along with a detailed list of output fields (coordinates, country, admin region, timezone, elevation, population). This clearly distinguishes it from sibling tools like elevation or country_indicator, which serve different purposes.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It does not explicitly state when to use this tool versus alternatives, but the output scope makes its role clear. The mention of `paid_catalogue` provides guidance on when to escalate to a paid API, which is a form of alternative guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the burden. It discloses important behavioral traits: payment is via x402 over USDC on Base, no account or API key is needed, and the tool takes no arguments. It also clarifies that MCP tools are free. However, it does not explicitly state that this particular tool is read-only or whether it incurs a charge, though 'list' and 'free' imply it.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is compact, front-loaded with the core action, and every sentence adds value. It efficiently covers purpose, differentiation, payment details, and parameter confirmation without irrelevant filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a zero-parameter, no-output-schema catalogue tool, the description is complete. It tells the user what the tool lists (paid routes with prices and input requirements), who it is for (those needing specialised data), and how payment works. It also clarifies the relationship to the free MCP tools, providing enough context to invoke it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters, and the schema is empty. The description explicitly confirms 'Takes no arguments', which removes any ambiguity. Since there are no parameters to document, the description fully compensates for the schema's emptiness.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'List' and the resource 'the paid API routes this same server offers', with specific detail about prices and input requirements. It also distinguishes itself from the sibling free MCP tools by explaining that the paid routes are specialised for on-chain token safety, live DEX prices, wallet intel, and supply-chain scans.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear context on when to use this tool: it is a catalogue of paid routes, while the MCP tools are free and general-purpose. It gives examples of specialised use cases but does not explicitly state 'when not to use' or name alternative tools by their tool names, so it falls short of a full explicit usage guide.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the transparency burden. It adds useful behavioral context by stating the response includes local names and a past/upcoming flag, and the parenthetical clarifies that the tool is free and requires no signup. However, it does not disclose error behavior, rate limits, or explicitly confirm read-only status.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise, with the core purpose front-loaded in the first sentence. The second sentence about the paid API is somewhat tangential but still brief and potentially useful for choosing between free and paid options. No wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple 2-parameter read-only lookup tool without an output schema, the description adequately conveys the return content (local names, past/upcoming flag) and the cost/auth context. It is missing some details about error cases or data source limitations, but these are not critical for basic usage.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema fully covers both parameters (country and year) with descriptions, so schema coverage is high. The description adds no additional parameter-level semantics beyond what the schema already provides, warranting the baseline score.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly identifies the resource (public holidays) and its scope (country and year), and distinguishes this tool from sibling data lookup tools. However, it lacks an explicit verb like 'get' or 'returns', so the action is implied rather than stated.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies the tool is used to fetch public holidays for a country and year. It also points to paid_catalogue as an alternative for paid API access, but it does not explicitly state when to use this tool over sibling tools or when not to use it.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden. It explicitly discloses the core behavior: fetching a URL and returning clean Markdown with boilerplate stripped. It also adds context about being free and the paid alternative, though it does not mention rate limits or edge cases.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences: the first gives the core function, the second provides relevant pricing and alternative API information. Every sentence earns its place with no wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple tool with one parameter and no output schema, the description adequately specifies both input (a URL) and output (clean Markdown), while also conveying the free/paid context. It is complete for the tool's complexity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema fully describes the url parameter as 'Page to fetch' (100% coverage). The description merely restates 'Fetch a URL' and adds no additional semantic detail beyond the schema, so the baseline of 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool fetches a URL and converts its main content to clean Markdown with boilerplate stripped. This specific verb-resource-output combination distinguishes it from sibling tools like web_search or audit_skill_url.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives clear context by noting the tool is free and points to paid_catalogue as an alternative for a paid API. However, it does not explicitly mention when to use this tool over sibling tools like web_search, so it stops short of full exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden. It discloses an automatic multi-engine failover chain and free access, which adds meaningful behavioral context. But it omits potential rate limits, error behavior, or result pagination details that an agent might need.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The first sentence is concise and directly explains the tool. The second sentence introduces paid API details, which is tangential but still compact. Overall it is appropriately sized, though the commercial pitch slightly distracts from core usage.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool is simple (2 parameters, no output schema). The description explains the return type (title/url/snippet) and key behavior (failover). It could mention limits or pagination, but for live web search the description is sufficiently complete for an agent to use it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema already provides 100% coverage for both parameters (query and max_results). The description adds no extra parameter-specific semantics, just general search behavior, so the baseline of 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Search the live web'), the resource ('live web'), and the output format ('ranked title/url/snippet results'), distinguishing it from sibling tools like read_url or geocode.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides context that this is free and explicitly points to paid_catalogue as an alternative for a paid API, offering some usage guidance. However, it does not give explicit 'when not to use' or alternative selection criteria beyond that.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.