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

Annotations already indicate read-only and idempotent behavior. The description adds useful context: return fields (balance, income/expenditure, runout) and the prerequisite API key, which enriches the agent's understanding.

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 brief and efficiently lists arguments, returns, and requirements. It is front-loaded with the main purpose. Could be slightly more structured but is adequate.

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 balance check with one optional parameter, the description covers the purpose, argument, return values, and a prerequisite. No output schema exists, so the return description helps. It is sufficiently complete.

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 single parameter is fully documented in the schema with description and enum. The description repeats the same info without adding new meaning, so it does not go 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 'Check your RIPE Atlas credit balance and usage statistics', specifying the verb (check) and resource (credit balance/usage). It distinguishes from sibling tools which focus on measurements and probes.

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 notes the required environment variable and mentions the return values, but does not explicitly state when to prefer this tool over alternatives. However, the context makes the purpose 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 readOnlyHint, destructiveHint, idempotentHint, openWorldHint (safe read). The description adds behavioral context by specifying the return includes 'type, target, status, probes, timestamps', which goes beyond annotations. No contradictions.

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 for purpose, two parameter lines, one return line). Information is front-loaded, well-organized with Args and Returns sections. No unnecessary 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 read-only tool with full schema coverage and rich annotations, the description is complete. It covers input (parameters), output (return fields), and the nature of the operation. No output schema exists, so describing the return type is appropriate.

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 baseline 3. The description lists parameters (measurement_id, response_format) but adds minimal additional meaning beyond the schema descriptions (e.g., 'The measurement ID' vs schema 'The measurement ID to retrieve'). No constraints or examples beyond enum and default.

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 'Get detailed information about a specific RIPE Atlas measurement by ID', specifying verb (get), resource (measurement details), and scope (by ID). It distinguishes from siblings like atlas_list_measurements (lists), atlas_get_results (returns results), and atlas_stop_measurement (mutations).

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?

No explicit guidance on when to use this tool versus siblings (e.g., atlas_list_measurements for overviews, atlas_get_results for raw data). The description implies it's for a single measurement's details, but does not state when-not-to-use or alternatives.

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, destructiveHint, idempotentHint, openWorldHint, indicating safe idempotent operation. The description adds useful context about returned fields (country, ASN, etc.) without contradicting 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 short and to the point, with a clear purpose stated first. No unnecessary words, and the structure is logical.

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 lack of an output schema, the description lists important return fields, providing helpful context. It covers the core functionality adequately.

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 fully documents both parameters. The description repeats the parameter meanings and adds an example of returned fields, but no additional semantic insight beyond the schema for parameters.

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 'Get detailed information about a specific RIPE Atlas probe by ID,' using a specific verb and resource. It distinguishes from sibling tools like atlas_search_probes that have a different purpose.

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?

No explicit guidance on when to use this tool versus alternatives like atlas_search_probes for finding probes first. Usage is implied by the need for a specific probe ID.

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 and destructiveHint=false, so the description adds limited behavioral context (e.g., can filter results). It does not contradict annotations and provides some additional detail about return format.

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?

Description is structured with Args and Returns but repeats parameter info already in schema. Some redundancy, but overall clear and front-loaded with key purpose. Could be more concise.

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?

All 6 parameters are documented in both schema and description. No output schema, but description outlines return content (per-probe data like RTT, hops). Provides sufficient context for an AI agent to understand the tool's capabilities.

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 baseline is 3. Description adds value by listing parameters with defaults and explanations (e.g., 'latest (bool): If true, get only latest results (default: false)'), enhancing meaning beyond 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 'Retrieve results from a RIPE Atlas measurement' with specific verb and resource. It distinguishes from siblings like atlas_get_measurement (which gets measurement details) by focusing on result retrieval with filtering options.

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?

Description explains when to use: fetching all results, latest only, or filtering by time and probes. It does not explicitly mention when not to use or alternatives, but the use cases are clearly stated.

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 (readOnlyHint: true) already indicate safety. The description adds that it returns a paginated list, but does not disclose further behavioral traits beyond the schema and 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 well-structured, front-loaded with purpose, and uses a bullet-like list for args. It is concise with no unnecessary words, though slightly long due to parameter count.

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 12 parameters and no output schema, the description adequately states the return type (paginated list) and covers filters. It is sufficient for effective 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%, but the description groups and explains parameters in a user-friendly manner (e.g., 'mine: Show only your measurements (requires API key)'), adding value beyond schema descriptions.

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 'Search and list RIPE Atlas measurements with comprehensive filters,' which uses specific verbs and resource, and clearly distinguishes from siblings like atlas_get_measurement and atlas_measure_ping.

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 when to use (searching with filters) but does not explicitly exclude other tools or mention alternatives. It is clear enough for use, though not explicitly distinguishing.

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?

The description discloses the creation of a measurement, return of an ID, and API key permission requirement. Annotations indicate readOnlyHint=false and destructiveHint=false. The description adds value beyond annotations by noting the return type and that omitting target uses the probe's resolver.

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 well-structured with a lead sentence, purpose paragraph, bulleted arg list, and separate lines for returns and requirements. It is concise but could reduce redundancy (e.g., repeating 'probe_count, from_country, etc.' while schema already covers them).

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 26 parameters and no output schema, the description covers core functionality, permissions, and probe selection. It mentions 'Returns: Measurement ID(s).' and enumerates key arguments, though it could better explain the response_format parameter or post-creation steps. Overall adequate.

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 baseline is 3. The description adds meaning by highlighting key parameters (e.g., query_argument with example 'example.com', query_type list, protocol enum) and summarizing default values, though not all 26 parameters are listed.

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 creates a DNS measurement on the RIPE Atlas network using distributed probes. It distinguishes from sibling tools (e.g., ping, traceroute) by specifying DNS lookups and enumerating key DNS-specific parameters like query_argument and query_type.

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 (perform DNS queries from global probes) and provides context like requiring an API key. However, it lacks explicit when-to-use or when-not-to-use guidance versus alternatives, though the sibling names and tool focus make the purpose clear.

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 indicate non-read-only, non-destructive, non-idempotent, and open-world. The description adds context about requiring an API key with 'create measurement' permission, returning a measurement ID, and making external HTTP requests, which goes 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 fairly long with a bullet list of arguments. It is front-loaded with purpose but repeats some schema information. Could be more concise while maintaining clarity.

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 25 parameters, no output schema, and annotations present, the description covers purpose, return value, permissions, and key parameters. It is complete enough for an agent to understand the tool's functionality and requirements.

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 descriptions for all 25 parameters. The description adds value by summarizing key parameters (e.g., method, path, port, probe selection) and grouping them, but baseline is 3 due to high coverage; the extra context earns a 4.

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 it creates an HTTP measurement on the RIPE Atlas network, making HTTP requests from distributed probes. This specific verb+resource combination distinguishes it from sibling tools like atlas_measure_ping, atlas_measure_dns, etc.

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 HTTP measurements but does not explicitly state when to use this tool versus alternatives. Sibling tools exist for other protocols, providing context, but no explicit exclusions or 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.

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

Annotations indicate it's a write operation (readOnlyHint=false). The description clarifies the creation nature and adds a requirement for a specific API key permission. No contradictions, but could mention side effects like credit consumption.

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 clear sections for purpose, arguments, returns, and requirements. Every sentence adds value, though it could be slightly more structured.

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?

No output schema is provided; the description states 'Returns: Measurement ID(s)' but does not explain the asynchronous nature or how to retrieve results. Sibling tools for results may infer, but it's not fully self-contained.

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 description coverage is 100%, so the description offers a high-level grouping (e.g., 'Probe selection') but does not add significant new meaning beyond the schema definitions.

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 'Create an NTP measurement' with specific verbs and resource, and the name and title distinguish it from sibling tools like atlas_measure_dns or atlas_measure_ping.

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 mentions the required API key permission but does not explicitly state when to use this tool versus other measurement types or provide any exclusion criteria. Given the many sibling tools, more guidance would help.

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 show destructiveHint=false and readOnlyHint=false, but the description adds important context: it requires an API key with 'create measurement' permission, and explains it creates a measurement and returns IDs plus a results link. It does not disclose cost implications or asynchronicity, which would improve transparency.

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 (≈150 words), front-loaded with the main purpose, followed by a compact param summary and essential notes on returns and permissions. Every sentence contributes meaningfully.

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 19 parameters, one required, and no output schema, the description provides a reasonable overview. It covers the primary action, key parameters, return format, and auth requirement. However, it omits that measurements are asynchronous and that results are fetched later via atlas_get_results.

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 description's brief param list adds no new information beyond defaults and ranges already in the schema. The description does not clarify relationships between parameters (e.g., from_country vs from_probes) or provide examples, so it only meets the baseline.

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 'Create a ping measurement' and specifies it sends ICMP echo requests. It distinguishes from sibling tools like atlas_measure_dns or atlas_measure_http by explicitly naming 'ping' and 'ICMP'.

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?

No explicit when-to-use or when-not-to-use guidance is provided. While the description implies usage for ping/ICMP measurements, it does not compare with siblings or note prerequisites (e.g., 'Use for latency checks; not for DNS resolution'). The lack of explicit alternatives lowers the score.

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?

The description discloses that the tool creates a measurement (non-read-only) and requires specific API key permissions, adding value beyond the annotations (which only indicate readOnlyHint=false, destructiveHint=false, etc.). However, it does not mention behavioral details like cost implications, rate limits, or what happens to existing data.

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 introductory sentences, then a structured list of args, returns, and requirements. Every part adds value, though the list format could be more tightly integrated. It is front-loaded with the primary action.

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 17 parameters and no output schema, the description is insufficient. It barely explains the return value ('Measurement ID(s)') and omits details on output format despite a response_format parameter. No error handling or prerequisites beyond API key are mentioned, making it incomplete for a complex tool.

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 description coverage is 100%, so the baseline is 3. The description lists parameter names (target, port, probe_count, etc.) but adds no significant extra meaning beyond the schema's own descriptions. It is redundant rather than enhancing 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?

The description clearly states the action ('Create') and the resource ('TLS/SSL certificate check measurement'), with specifics about retrieving TLS certificates from distributed probes. It distinguishes this from sibling tools like atlas_measure_ping or atlas_measure_dns by focusing on TLS certificate retrieval.

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 lists required permissions (RIPE_ATLAS_API_KEY with 'create measurement' permission) and indicates usage for TLS certificate checking, but does not explicitly state when to use this tool versus alternatives or when not to use it. The sibling tools provide context, but no direct differentiation 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?

Annotations show readOnlyHint=false, but the description adds context: requires API key with 'create measurement' permission, returns measurement ID(s). It does not mention credit consumption or side effects, but covers key behavioral traits 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.

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

The description is front-loaded with purpose and has a structured Args section. It includes some explanatory text (e.g., 'Traces the network path...') that is useful but slightly verbose. Overall, it is concise for a complex tool.

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 27 parameters and no output schema, the description covers the creation process and returns measurement ID(s). However, it lacks details on the structure of the returned ID or how to interpret/use it. This leaves completeness gaps for new users.

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?

Input schema has 100% description coverage, so baseline is 3. The description's 'Args' section repeats defaults and descriptions already in the schema, with little added value. Grouping of probe selection parameters is helpful, but overall redundancy keeps score at 3.

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 'Create a traceroute measurement on the RIPE Atlas network' and explains it traces the network path. The verb 'Create' and resource 'traceroute measurement' are specific. It distinguishes from sibling tools like atlas_measure_dns by focusing on traceroute.

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 does not provide explicit guidance on when to use this tool versus sibling tools (e.g., atlas_measure_ping). It only implies usage for traceroute, but does not mention alternatives or conditions. Usage is implied but not 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, non-destructive, idempotent, and open-world. The description adds behavioral context: 'Returns: Paginated list of probes with ID, country, ASN, status, tags.' This clarifies the output structure and pagination, going 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 concise: a one-line summary, a well-organized parameter list with clear formats, and a return statement. No redundant information; every sentence is useful and front-loaded.

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 tool with 13 parameters and no output schema, the description covers the purpose, parameters, and return structure. It lacks explicit pagination limits or usage advice, but the details are 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.

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 lists parameters with brief explanations, but these largely mirror the schema descriptions (e.g., status mapping). It does not add significant new semantics beyond what the schema already 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 purpose: 'Search for RIPE Atlas probes worldwide with filters for location, network, and status.' It uses a specific verb ('Search') and resource ('probes'), and the tool is distinct from siblings like 'atlas_get_probe' which retrieves a single probe by ID.

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 lists many filters but does not explicitly guide when to use this tool versus alternatives (e.g., 'atlas_get_probe' for a specific probe). However, the tool's name and parameter set imply its use case, and the context signals show sibling tools without confusion.

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 indicate destructiveHint=true and idempotentHint=true; the description adds context about requiring authentication and permissions. It does not contradict annotations, but could elaborate on behavior for already stopped measurements.

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?

Three sentences, each adding value: main action, argument, return, requirement. No filler, appropriate length.

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 stop operation with one parameter, the description covers action, param, return, and requirement. It could mention error handling but is adequate.

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 a description for measurement_id that matches the description. The description adds no extra meaning beyond the schema, so baseline of 3.

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 'Stop a running RIPE Atlas measurement' with a clear verb and resource. It distinguishes from siblings like atlas_get_measurement (read) and atlas_measure_ping (create).

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 mentions 'Requires: RIPE_ATLAS_API_KEY with appropriate permissions' and implies usage when a measurement is running. It lacks explicit when-not-to-use or alternatives, but 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.