ICANN registrar accreditation status

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

Beyond the readOnlyHint annotation, the description reveals the surprising behavior that the tool returns a LIST and that ten IDs carry two records due to differing ICANN/IANA name spellings, with both records returned rather than one chosen. This is valuable, non-obvious behavioral context an agent needs before invoking the tool.

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?

Two dense, well-structured sentences: the first front-loads the complete data scope, and the second adds the critical duplicate-record caveat. There is no filler or redundancy; 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?

For a read-only single-parameter lookup with an output schema and safety annotations, the description is complete: it states what is returned, scopes the request, and flags the main edge case (duplicate records). Nothing an agent needs to call it correctly is missing.

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 fully documents the single iana_id parameter with examples. The description reinforces that the ID is the lookup key but adds no new parameter-level detail, 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 states the tool fetches the full record for a single IANA registrar ID, enumerating the specific data returned: accreditation status, RDAP base URL, and enforcement notices. It is unambiguous in scope (one ID) but does not explicitly differentiate itself from sibling tools like list_enforcement_actions or resolve_registrar.

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 scope 'for one IANA registrar ID' implies this is the per-ID lookup, but the description never states when to prefer it over alternatives such as list_enforcement_actions, resolve_registrar, or verify_quote. There is no explicit when/when-not guidance or exclusion, only an inferable use case.

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 and no destructive effect, so the safety profile is covered. The description adds meaningful behavioral context: results are ordered newest first, dates appear exactly as ICANN prints them (not normalized), and each entry includes a notice PDF and a verbatim quote. These details help the agent set the right expectations beyond the structured 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 a compact two-sentence structure: a strong leading question, then a dense enumeration of contents, ordering, and filter options. Every clause contributes new information with no filler 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?

For a read-only list tool with three optional, fully documented parameters and an output schema, the description covers purpose, result contents, ordering, and filtering. The output schema handles return shape and annotations handle the safety profile, so nothing an agent needs to correctly invoke this tool is missing.

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%, and each parameter already has a clear description. The description only restates that filtering by action type or date is possible, adding no new semantic detail. The 'date as ICANN prints it' nuance is also already present in the since parameter's schema description, so the description adds minimal value here.

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 opening question 'Which registrars has ICANN acted against?' plus 'Lists the Contractual Compliance notices' gives a specific verb and resource. It enumerates the notice types (breach, suspension, termination) and the exact fields returned (registrar, date, PDF, quote), making the purpose far more specific than the title and clearly distinct from the sibling tools (registrar lookup and quote verification).

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 use case — exploring ICANN compliance actions against registrars — and tells the reader they can filter by action type or date to see recent enforcement. However, it does not reference the sibling tools or state when not to use this one, so the guidance is more implied 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 signal read-only non-destructive behavior. The description adds beyond that by disclosing that results include accreditation status, ICANN enforcement actions, and the page and verbatim quote the information was read from, which tells the agent the tool returns source-backed evidence.

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?

Four sentences, each earning its place: a scoping prompt, the search mechanism with examples, the return payload, and the routing guidance. It is front-loaded and avoids 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 two parameters, a complete output schema, safety annotations, and explicit sibling routing, nothing essential is missing. The description fully equips an agent to select and invoke this 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% for both parameters, so the schema already documents them. The description adds value by clarifying query semantics: partial names, case-insensitive substring matching, and concrete examples like 'GoDaddy', 'Tucows', and 'namecheap'.

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?

States a specific verb and resource: search ICANN's accredited-registrar register by name or IANA ID. It also gives concrete search examples and explicitly distinguishes itself from get_registrar, so an agent can tell them apart immediately.

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?

Directly provides routing guidance: 'Use this first when you have a name; use get_registrar when you already have the IANA ID.' This makes the selection decision explicit rather than leaving it to inference.

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 no contradiction exists. The description adds valuable behavior beyond that: it explains the three possible comparison outcomes (match, appears only in verbatim quote, or differs with the register's value) and promises to return the source page and quote for traceability. This gives the agent a realistic expectation of the tool's semantics.

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 the user's implicit question, and every clause earns its place. It explains the tool's purpose, input semantics, output categories, and traceability without repetition 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 read-only verification tool with a high-coverage input schema and an output schema, the description fully covers what an agent needs: what the tool does, what it checks against, what outcomes it reports, and what supporting evidence it returns. No critical behavioral or prerequisite information is missing.

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 schema fully documents claimed_value, iana_id, and field. The description reinforces that the claim should be taken literally and that omitting field means all fields are checked, but it adds little beyond what the schema already provides. A baseline 3 is appropriate because the description is not needed to compensate for gaps.

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 opens with the pointed question 'Is this right?' and states a specific verb and resource: 'Check a claim about a registrar ... against the register.' It enumerates example claims (accreditation status, name, enforcement date) and clearly distinguishes itself from a data-fetch or listing tool by emphasizing verification over retrieval. This gives an agent an unambiguous understanding of the tool's unique role.

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 conveys when to use the tool: whenever a claimed registrar fact needs to be checked 'instead of trusting it.' It does not explicitly name sibling alternatives such as get_registrar or resolve_registrar, nor does it state when not to use it, so it stops short of a full 5.

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