Agent Company Index

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

Annotations already indicate readOnlyHint=false, idempotentHint=true, and destructiveHint=false. The description adds the verified-domain prerequisite and the review-timing constraint, which are useful. However, it does not disclose what happens on approval (e.g., immediate publication, potential failure modes) or any side effects beyond the act of approving.

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-loads the core action, and then adds constraints. Every word earns its place; there is no fluff or repetition.

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 five required parameters, no output schema, and zero parameter descriptions, the description is far from complete. It leaves the agent without an understanding of what the parameters represent or what the tool returns. While the purpose and preconditions are clear, operational details are 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 0%, so the description must explain the five parameters. It does not. The only vague link is 'exact draft revision' which points to the 'revision' parameter, but it fails to clarify the meaning of 'reference', 'listing_token', 'approver_role', or 'schema_version'. This is a significant gap.

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: 'Approve publication of the exact draft revision on behalf of the company.' It identifies a specific verb, resource, and scope. It does not explicitly contrast with sibling tools, but the purpose is unambiguous enough to distinguish it from the other listing-related 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?

The description gives explicit preconditions: 'Requires a verified domain' and 'Only call after the company has reviewed the draft.' This tells the agent when it is appropriate to use the tool, though it does not mention alternative tools or when to avoid it beyond these conditions.

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 safety profile is covered. The description adds behavioral details: 'published' (status filter) and 'stable, non-commercial order' (ordering guarantee). However, it doesn't disclose pagination behavior (limit/cursor) or response format. With annotations covering safety, this is a modest but not complete disclosure.

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, concise sentence with no wasted words. It front-loads the primary action ('List') and is appropriately brief for a straightforward listing operation. It could be slightly richer, but it earns a 4 for economy.

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 limit and cursor parameters, the description omits any explanation of pagination, which is essential for correct usage. It also doesn't clarify the return format or the meaning of 'stable, non-commercial order'. For a list tool with no output schema, this is incomplete. It meets only the minimal purpose statement.

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 0%, so the description must explain parameters. It does not mention 'limit', 'cursor', or 'schema_version'. The agent must infer semantics from names, which is insufficient for correct invocation, especially for pagination parameters. This is a critical gap.

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 a specific verb 'List' and a clear resource 'published ACI offerings', with an ordering detail ('stable, non-commercial order'). It clearly indicates a read-only listing operation and is distinguishable from siblings like 'get_offering' (single item) or 'request_listing' (create). However, it doesn't explicitly name alternative tools, so it stops short of a perfect 5.

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 guidance is provided on when to use this tool versus alternatives like 'get_offering' or 'get_listing_status'. There is no mention of typical use cases, exclusions, or prerequisites, leaving the agent to infer usage context from the name alone.

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 agent knows this is a safe read operation. The description adds no behavioral context beyond the phrase 'against the published ACI corpus', which hints at a static dataset but does not disclose output behavior, error conditions, or effects of incomplete inputs. With annotations covering safety, the description contributes little additional behavioral 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 a single sentence with no filler or redundant phrasing. It front-loads the action and object. It is appropriately concise, though its brevity contributes to the lack of contextual completeness.

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 has a complex, deeply nested input schema and no output schema. The description is too sparse to cover what the agent needs to know: what 'evaluate' returns, how results are formatted, how incomplete situations are handled, or any error behavior. Given the complexity and missing output schema, the description is clearly insufficient.

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 50% – the 'situation' parameter is richly documented in the schema, but 'schema_version' is not described. The tool description itself adds no meaning to either parameter; it merely repeats the phrase 'structured situation' which adds no information beyond the schema's already detailed description. Given the moderate coverage, the description should compensate but does not.

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 a specific verb, 'evaluate', and a specific resource, 'structured situation against the published ACI corpus'. This distinguishes it from the sibling tools, which all deal with listings, offerings, or domain verification. However, 'evaluate' is somewhat ambiguous (match? score? classify?), so it stops short of fully specifying the operation's semantics.

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 no explicit indication of when to use this tool versus alternatives. It does not mention any preconditions, exclusions, or related tools (e.g., 'use discover_offerings if you need to search offerings'). The intended context is only weakly implied by the verb and resource, but an agent gets no direct 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 already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds a behavioral nuance: the full draft is only returned 'once prepared', implying a state-dependent response. This goes beyond the annotations and helps the agent set expectations, though no additional traits like rate limits or auth are mentioned.

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, tightly worded sentence that front-loads the core action ('Read the state') and then specifies the conditional output. There is no redundancy or fluff; every word contributes to the meaning.

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 three required parameters and no output schema, the description is too sparse. It does not explain what the parameters represent, how the response is structured, or any preconditions beyond 'once prepared'. The agent lacks sufficient information to correctly call the tool without external knowledge.

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 0%, and the description provides no explanation of the three required parameters (reference, listing_token, schema_version). The agent must rely on parameter names alone, which are ambiguous without context. The description fails to compensate for the missing schema descriptions, leaving the agent unsure of what values to provide.

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 a specific verb ('Read') and identifies both a resource ('listing request') and a conditional outcome ('full draft with its revision digest and every fact and source'). This clearly distinguishes it from siblings like approve_listing or get_offering, and the agent can infer exactly what operation this performs.

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 checking status or retrieving a prepared draft, but it does not explicitly state when to prefer this over siblings like get_offering or evaluate_situation. No exclusions or alternative routing is provided, leaving the agent to infer the appropriate context from the name and purpose.

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 non-destructive hints, so the description's job is lighter. It adds the qualifiers 'published' and 'public,' indicating a safe, publicly accessible read. However, it does not disclose return format, error behavior, or whether an offering must be currently published – acceptable 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?

A single, front-loaded sentence that conveys the core purpose with no filler. Every word 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?

With no output schema and no parameter explanations, the agent is left without a description of the ACI projection or the response shape. The description is adequate for a trivial identifier-based read but misses opportunities to clarify the domain-specific 'ACI projection' and the role of schema_version.

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 0%, and the description does not explain what 'slug' or 'schema_version' mean or how they relate. The phrase 'one published offering' weakly implies slug identifies the offering, but this is not explicit. The description fails to compensate for the schema's lack of parameter documentation.

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 a specific verb ('Retrieve') and precise resource ('one published offering's public ACI projection'), which clearly distinguishes it from sibling list/discovery tools like discover_offerings. It doesn't explicitly name sibling tools, so it stops short of full differentiation, but the wording is unambiguous about 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 no information about when to choose this tool over get_listing_status, discover_offerings, or other siblings. It gives no exclusions, alternatives, or contextual conditions; the only implied use is 'retrieve one published offering.'

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 this is a non-read-only, non-idempotent action, and the description adds substantial behavioral detail: the request is reviewed, not guaranteed, nothing publishes until approval, and payment doesn't affect fit or order. It also discloses the return values including a one-time token and domain-control challenge. This goes well 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 three sentences with zero waste. It front-loads the purpose, then returns, then process. Every sentence adds value, and the structure is clean and scannable.

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 request tool with six parameters and no output schema, the description covers the essential aspects: what it does, what it returns, and the review/approval process. It doesn't explain the domain-control challenge in detail, but that's not necessary for invoking the tool correctly. The process transparency helps set expectations.

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 67%, so most parameters already have descriptions in the schema. The tool description does not add any parameter-specific semantics beyond what's in the schema. The optional notes parameter lacks a schema description and the tool description doesn't compensate, but this is a minor gap given the 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 states a specific verb (list) and resource (offering) with a clear actor (ACI) and the company context. It distinguishes the tool from siblings like approve_listing or get_listing_status by focusing on the initial request action. The mention of returns (reference, token, challenge) further clarifies its 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 provides clear context about when this tool is used: to request a listing, with a review and approval process. It doesn't explicitly name alternatives or state exclusions, but the purpose is unambiguous enough that an agent would understand this is the initiating step. The non-guarantee and approval requirement give practical 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 already cover idempotency and non-destructiveness, and the description adds useful context about what is checked (DNS TXT record or well-known file. However, with readOnlyHint=false, the description does not disclose any side effects the verification may have, such as updating listing state.

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 focused sentence with no filler; the action and target are front-loaded and the parenthetical adds specific, useful detail. It is concise, even though it omits deeper parameter and result information.

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 description says what to check and where, but because there is no output schema, return behavior is unexplained and parameter semantics are absent. The workflow prerequisite beyond 'from request_listing' is only implicit, leaving an agent to infer important details.

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 three parameters are required and have zero schema description coverage, and the description does not explain what 'reference' or 'listing_token' mean. The only hint is that the challenge comes from request_listing, which is insufficient for an agent to construct a correct call.

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 names a specific verb ('Check') and a specific resource (the domain-control challenge from request_listing), and goes further by naming the two concrete verification mechanisms: a DNS TXT record or a file at /.well-known/aci-verification.txt. This makes it easy to distinguish from sibling tools like approve_listing or get_listing_status.

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 phrase 'from request_listing' establishes clear workflow context: this is the verification step that follows a listing request. It does not explicitly list alternative tools or state when not to use it, but the intended place in the process is clear enough.

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