netcafe-live-data

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 meaningful context beyond that: it specifies the real China network vantage point and the metrics returned (HTTP status, latency, DNS answers), giving the agent a better sense of what the tool actually does.

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 no filler. The first sentence states the action and outputs, the second adds the unique value proposition. Every clause earns its place.

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 (one parameter, output schema present) and the description fully covers its purpose, metrics, and when to use it. There are no significant gaps given the low complexity and strong annotation support.

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 the URL parameter is already well described. The description only restates that the tool tests a URL and does not add any further syntax, formatting, or edge-case details beyond what the schema provides.

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 'Test' and specific resource 'URL reachability from a real mainland-China network', and lists concrete outputs (HTTP status, latency, DNS answers). It also highlights the 'unique vantage point', distinguishing it from sibling tools like domain_check or ssl_check.

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 says this is the 'unique vantage point for checking if your site is blocked or slow in China', which clearly implies when to use it. It does not explicitly name alternative tools or state when not to use it, but the context is sufficiently clear for an agent to select it appropriately.

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?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, covering the safety profile. The description adds context by specifying the data source (official RDAP) and the returned fields, which goes beyond the annotations. There is no mention of rate limits or failure modes, but for a simple read-only tool this is sufficient, earning a 4.

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 a single, well-constructed sentence that front-loads the core purpose and lists the key outputs. It is extremely concise with no 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?

With only one parameter and no nested objects, the description adequately covers the tool's purpose and behavior. An output schema exists, so return values need not be explained. It is complete for its simplicity, though it could mention error conditions for unsupported TLDs, which is a minor gap.

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% (single 'domain' parameter with a 'e.g. example.com' description). The tool description does not add parameter-specific details, so it meets the baseline of 3 without enriching the parameter understanding.

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?

Description specifies a clear action ('Check if a domain is registered') via a specific protocol (official RDAP) and lists the resource details returned (availability, registrar, dates, nameservers). This distinguishes it from sibling tools like ssl_check, which addresses a different aspect of domain inspection.

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 its use for domain registration checks but does not explicitly state when to use it instead of sibling tools like ssl_check. No exclusions or alternative guidance is provided, so usage is implied rather than explicit.

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?

Annotations already declare the tool read-only and idempotent. The description adds behavioral context by explaining the two return modes (conversion vs. table) and that the data is 'live.' No contradiction with annotations is present.

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?

A single, neatly front-loaded sentence concisely conveys the tool's purpose and modes without waste or redundancy.

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 presence of full schema descriptions, output schema, and safety annotations, the description adequately covers the tool's behavior. It explains both operational modes, which is sufficient 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.

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

Schema coverage is 100%, so the schema already documents each parameter. The description reinforces the purpose of 'to' (omit for table) but adds no additional syntax, format, or edge-case information beyond what the schema provides.

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

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

The description clearly states the tool's function: providing live currency exchange rates with two modes—a single pair conversion or a table for a base currency. It distinguishes itself from sibling tools (weather, stock quotes, etc.) by its specific domain 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?

The description provides clear context for when to use the tool (for live currency rates) and the two usage scenarios (pair conversion or base-currency table). It doesn't explicitly exclude alternatives, but sibling tools are obviously different domains, making the intended use clear enough.

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?

Annotations already declare the tool as read-only, idempotent, and non-destructive. The description adds behavioral context by specifying the forecast duration (3-day) and input flexibility (language or coordinates), which go beyond 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.

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

The description is a single, front-loaded sentence that conveys the core functionality and input modes without any redundant words. It is an excellent model of conciseness.

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 simplicity of the tool, the presence of an output schema, and annotations covering safety, the description is largely complete. It covers the main purpose, forecast period, and location input alternatives, though it omits edge cases like invalid inputs or parameter precedence.

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

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

The input schema has only 33% coverage (only city has a description). The description compensates by explaining that coordinates can be used instead of a city name, but it does not fully clarify that latitude and longitude must be used together or how conflicts are resolved. Partial compensation for low schema coverage.

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 provides 'current weather and 3-day forecast' for any city, using a specific verb+resource structure. It distinguishes itself from sibling tools (exchange_rate, domain_check, etc.) by focusing on weather and mentioning worldwide coverage.

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 on when to use the tool (weather queries, any city) but does not explicitly mention alternatives or exclusions. The sibling tools are in different domains, so usage is implied rather than explicitly contrasted.

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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds the specific data fields returned but no additional behavioral context like rate limits or prerequisites. It does not contradict annotations.

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 one sentence, front-loaded with the action ('Inspect the TLS certificate of a domain') followed by a compact list of returned details. Every word earns its place, with no redundancy or filler.

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

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

For a simple read-only tool with one parameter and an output schema, the description adequately conveys purpose and result contents. It lacks explicit differentiation from sibling tools but is otherwise 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 provides a description and example for the single 'domain' parameter, giving 100% coverage. The description adds no extra parameter semantics beyond the schema, so it meets the baseline for full schema coverage.

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 starts with 'Inspect the TLS certificate of a domain', providing a specific verb and resource. It lists concrete outputs (issuer, validity window, days until expiry, trust status, SANs), making the tool's purpose unmistakable and distinct from sibling tools like domain_check.

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

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

The description implies usage for TLS certificate inspection but does not explicitly state when to use it over alternatives such as domain_check. No exclusion criteria or comparison to sibling tools is provided, leaving usage guidance implied rather than explicit.

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?

Annotations already declare the tool as read-only, idempotent, and non-destructive. The description adds the qualifier 'Live-ish' to temper expectations about real-time data, and includes a disclaimer that it is not investment advice. This provides useful behavioral nuance beyond 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.

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

The description is extremely concise: two sentences that cover the tool's purpose, markets, data fields, and a brief disclaimer. Every sentence earns its place with no 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?

The tool is simple with a single parameter and an output schema. The description provides sufficient context on markets, data returned, and a caveat about reliability. No major missing information 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.

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

The input schema fully documents the symbol parameter with examples, providing 100% coverage. The description does not add further parameter semantics, so the baseline score of 3 is appropriate.

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

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

The description clearly identifies the tool as a stock quote provider, specifies the markets (China A-shares, Hong Kong, US), and lists the key data fields (price, change %, open/high/low). This distinguishes it from all sibling tools, none of which are stock-related.

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 establishes the tool's purpose and scope, implying when to use it (for stock quotes across these markets). It does not explicitly mention alternatives or exclusions, but the sibling tools are unrelated, so the context is clear enough.

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