Agent Index

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

With no annotations, the description carries the full burden; it does disclose the important behavioral trait that output is neutral factual data rather than a ranking, which is real value. It does not say whether the operation is read-only (implied but unstated), how it behaves with an unknown or duplicate slug, or how the results are ordered.

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 short clauses, zero padding, with the scope (2–4 listings) front-loaded ahead of the caveat. Every phrase 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 single-parameter read-style comparison tool with no output schema, the description covers what it does, the input cardinality, and the nature of the result. The remaining gap is what attributes are compared and how results are ordered, which would help an agent decide whether to call it at all.

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?

Only one parameter and schema description coverage is 100%, so the schema already documents the slugs array with minItems 2 and maxItems 4. The description's "2–4 listings" merely restates those bounds and adds no format, ordering, or validity semantics.

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?

Specific verb (compare) plus a named resource (Agent Index listings) and an explicit cardinality bound of 2–4, which implicitly separates it from the single-item get_agent and the broader search_agents. It stops short of naming a sibling, so differentiation relies on inference.

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?

"Compare 2–4 ... side by side" implies the use case (evaluating multiple agents at once) and "not a ranking or recommendation" signals what the tool is not for. There is no explicit statement of when to prefer it over search_agents or chained get_agent calls, leaving the alternative-selection decision to the agent.

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 usefully discloses that the response includes the canonical page URL and source citations, which is real added value, but says nothing about behavior when the slug is unknown (error vs empty), auth needs, or rate limits.

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 front-loaded sentence with the identifier and the returned payload, and no filler. 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 one-parameter read tool with no output schema and no annotations, this covers what it returns and how it is keyed. The main missing piece is not-found behavior, which matters for a slug lookup but is a minor gap overall.

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 single slug parameter already carries a description and example ('vanta'). The description restates the lookup-by-slug semantics without adding format, normalization, or fallback details 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?

States a specific verb (get) and resource (one Agent Index listing) plus the lookup key (slug) and the payload (canonical page URL, source citations). It reads clearly as a single-item lookup, distinguishing it in spirit from search_agents and compare_agents, though those siblings are never named.

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 is only implied: the required slug suggests the agent should already have a slug, presumably from search_agents, but the description never says so and offers no when-not-to-use or alternative routing.

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 load. It does add useful context about the result (accreditation registry URLs for official cross-checks) and signals a verified-data guarantee, but it doesn't cover behavior on an unknown or unverified slug, or whether the response is a single record.

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 sentence with no padding, with the key qualifier ('one verified audit firm by slug') front-loaded and the payload note following efficiently.

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 one-parameter read tool with no output schema, the description is adequate: it says what entity is returned and highlights the registry URLs. The only gap is error/not-found behavior, which matters less given the tool's simplicity.

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 includes an example value (schellman), so the schema already defines the parameter fully. The description only restates that lookup is by slug, adding nothing beyond the schema – baseline 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?

States a specific verb and resource: retrieves a single 'verified audit firm' identified by slug. The singular 'one' implicitly contrasts with the search-style siblings, but no sibling is named, so it falls short of the top mark for differentiation.

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 'by slug' phrasing implies this is a lookup for an auditor you can already identify, as opposed to search_auditors. However, there's no explicit statement about when to use it versus search_auditors or what to do with an unknown slug.

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 exist, so the description carries the full burden. It discloses the return type ('canonical theagentindex.io URLs') and rules out ranking behavior, but says nothing about result ordering, pagination via limit, rate limits, or auth requirements.

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 short, front-loaded sentences with zero wasted words. The scope, return type, and the 'not a ranking' caveat are all delivered efficiently.

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?

Adequate for a parameterized search tool with 80% schema coverage and 0 required params: it identifies the corpus and return format. But with no output schema and no annotations, it omits result structure, ordering/pagination behavior, and routing versus siblings, leaving meaningful gaps.

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 80%, so the schema already documents query, category, framework, and pricing_model semantics. The description adds no parameter-level detail, which is acceptable given the high coverage but earns no extra credit.

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 (Search) and resource (Agent Index open dataset of GRC, security, and operations AI agents), and clarifies it returns canonical URLs and is 'not a ranking'. This distinguishes it implicitly from compare_agents (ranking/comparison) and get_agent (single fetch), though it never names those siblings.

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 offers no explicit when-to-use guidance or alternatives. 'Not a ranking' mildly signals it is not for ranked comparison, but an agent must infer from sibling names whether to use search_agents vs compare_agents vs get_agent.

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, so the description carries the full burden; it does add real value by disclosing data provenance (cross-checked against ANAB/UKAS/NABCB/etc.) and the caveat that results are not ranked. It omits return shape, pagination behaviour beyond the limit default, and ordering of results, which matter for a 503-item corpus.

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 sentences, front-loaded with the action and the corpus size, followed by the provenance list and the disclaimer. No filler and nothing redundant with the schema.

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?

Covers what is searched and where the data comes from, which is the main ambiguity for a directory tool. With no output schema and no annotations, the description should also say what a result record contains and whether the 503+ set is exhaustively listed, and it does not.

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 80%, so the baseline is 3, but the description adds meaning by naming the accreditation registries that the accreditation_body filter draws from (ANAB, UKAS, PCI SSC, HITRUST, FedRAMP, Cyber AB, CERT-In), helping the agent pick valid filter values. It says nothing about how query interacts with country/framework filters.

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 ... compliance audit firms') with a clear scope (503+ verified firms). This distinguishes it from get_auditor (single firm) and the search_agents/compare_agents siblings, though it never names those alternatives explicitly.

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 is only implied: an agent can infer this is the discovery/listing tool and that get_auditor is the detail lookup, but nothing states when to use this versus those siblings. The 'Not a ranking or endorsement' caveat is useful framing but is not usage guidance.

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