SaSame Research + Engagement Agent

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

The description explicitly states it is read-only and describes the actions (fetch, summarize, suggest), which discloses the tool's behavior. No annotations are provided, so the description carries the burden and does so adequately, though it could mention any external dependencies 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?

The description is extremely concise—two sentences—with no wasted words. The first sentence covers the core functionality, and the second provides input guidance. Every sentence 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?

Given no output schema and no annotations, the description covers the tool's purpose, input format, and read-only nature. It is mostly complete for a simple tool, though details about output format or error handling would improve it further.

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 parameters 'a' and 'b' are plain strings with 0% schema coverage. The description adds meaning by stating they are 'domains or agent-card URLs', which is essential for correct usage. This compensates for the schema's lack of 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 uses the specific verb 'introduce' and clearly states the resource (two agents), including the actions: fetch agent-cards, summarize, and suggest chaining. It clearly distinguishes from the sibling 'agent_card_fetch' which handles only one agent.

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 specifies the input format ('Give two domains or agent-card URLs') and states it is read-only, which provides clear guidance. However, it does not explicitly mention when not to use this tool or suggest alternatives, though the sibling list implies differentiation.

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 are provided, so the description must disclose behavior. It states the tool uses 'polite GET + LEGITIMATE MCP handshake' and 'one read-only tool call,' indicating safe, non-destructive behavior. It also notes 'no auth-bypass, no payment.' This is adequate but could mention rate limits or error handling.

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 moderately concise, with each sentence adding value (purpose, method, return, usage advice). It front-loads the main action. A minor improvement would be to shorten the parenthetical remark about the census.

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 tool has one parameter and no output schema, the description provides sufficient context: what it does, how it works, what it returns, and when to use it. It does not cover error scenarios or pagination, but those are not critical for this simple audit 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?

There is only one parameter (url) with 100% schema description coverage, so the baseline is 3. The description adds context about the handshake but does not provide additional parameter semantics 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?

The description clearly states the tool's purpose: audit an MCP server against the Agent-Tool Discoverability Standard using a polite GET and MCP handshake. It specifies the return value (grade, breakdown, biggest gap). It is distinct from sibling tools like verify_mcp_cert or census_search.

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 advises 'Best run against YOUR OWN server,' providing clear context for use. It mentions the tool is free and uses legitimate methods, implying it should not be used against others without permission. However, it does not explicitly list when not to use or compare with siblings.

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 explicitly discloses that the tool is 'Read-only and HONEST: an empty log returns 0, never fabricated activity.' It also notes the log is append-only and neutral, providing behavioral insight beyond the annotations (which are absent). 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 four sentences, front-loaded with the purpose, then behavioral guarantees, then filtering options, and finally use case. Every sentence adds value with no redundancy. It is efficient and well-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?

Given no output schema and no annotations, the description covers purpose, behavior, filtering parameters, and use case. It does not mention output format or pagination behavior despite the limit parameter. However, for a query tool, it is largely complete; mentioning output structure would improve clarity.

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 description mentions filtering by meter_id, agent_id, kind, or since (ISO timestamp), naming all parameters except limit. It adds context for kind (e.g., meter_charge/meter_reject/receipt_issue) and since format. Schema description coverage is 40%, so the description compensates well but could also describe limit's role (e.g., max results).

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 'Query', the resource 'SaSame's append-only neutral audit log', and lists specific event types (meters opened/charged/rejected, receipts issued). This distinguishes it from sibling tools like meter_charge, meter_open, and receipt_issue, which perform those actions rather than querying the log.

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 says 'Use to reconstruct what happened across agents from a source neither party controls,' which implies the usage context but does not explicitly state when not to use this tool or mention alternative tools. There is no guidance on when to prefer this over other query tools.

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 are provided, and the description does not disclose behavioral traits such as read-only nature, cost, or caching. However, for a simple list tool with no parameters, the transparency is adequate but minimal.

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 with no wasted words. It efficiently conveys the tool's purpose.

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 no output schema and simple operation, the description sufficiently states that the tool returns categories with counts. It is complete for the tool's complexity, though it could specify output format.

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 tool has zero parameters, and schema coverage is 100% (empty). The baseline score of 4 applies as per guidelines, and the description adds no further parameter 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?

The description uses specific verb 'List' and resource 'all categories' with 'counts', clearly stating the tool's function. It differentiates from siblings like 'census_search' or 'census_stats' which imply search or statistical operations.

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 alternatives like census_search or census_stats. The context of listing all categories is implied but not 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?

With no annotations, the description must fully disclose behavior, but it only states 'Search' without mentioning crucial traits like case sensitivity, field search scope, ordering, pagination, or response format. The agent lacks essential behavioral context for reliable invocation.

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 18-word sentence that immediately states the purpose and scope, with no redundant or vague phrasing. Every word contributes value, making it highly efficient.

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 tool has 4 optional parameters, no annotations, and no output schema, the description is too brief. It omits details on default behavior (e.g., what happens with no parameters), return format, error handling, and ordering, leaving the agent ill-equipped to use the tool confidently.

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 0%, so the description must compensate. It partially does by mapping 'keyword/kind/category' to query, kind, and category parameters, but does not explain the limit parameter or elaborate on enum values ('mcp_server', 'x402_service'). Adds meaning but not comprehensively.

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's action ('Search'), the specific resource ('Gold Rush Agent Census' with size info), and the search dimensions ('by keyword/kind/category'), making it unambiguous and distinguishing it from sibling tools like census_categories or census_stats.

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 (e.g., census_categories for browsing categories, census_stats for statistics) or when not to use it. The agent receives no contextual cues about optimal usage scenarios.

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 of behavioral disclosure. It only hints at a read operation by specifying 'stats' and 'counts,' but it does not explicitly state that it is read-only, mention any side effects, authentication needs, or rate limits. The lack of transparency is a significant gap.

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 that conveys the essential purpose without any fluff. It is front-loaded with the key information and earns its place with no wasted 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 tool with no inputs, the description covers the basic purpose but lacks detail on the output structure. It mentions 'counts by kind/category' and 'priced count' but does not explain these terms or the format of the response. Given no output schema, the description is adequate but not fully 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 tool has zero parameters and 100% schema description coverage, so the description does not need to add parameter information. The description adds value by clarifying what the output contains, which is appropriate given the baseline of 4 for zero-parameter tools.

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 that the tool provides stats of the Gold Rush Agent Census, specifically counts by kind/category and priced count. This clearly indicates the resource (census stats) and the action (providing statistics), distinguishing it from sibling tools like census_categories and census_search. However, it could be more explicit about what 'kind/category' and 'priced count' mean.

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 guidance on when to use this tool versus alternatives like census_categories or census_search. There is no mention of context, prerequisites, or exclusions, leaving the agent to infer usage from the tool 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?

With no annotations, the description must fully disclose behavior. It mentions SSRF guarding and auto-pay behavior, plus template substitution. However, it does not describe error handling, return format, or what happens if the chain does not exist. These gaps reduce 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 with three sentences. It front-loads the main action, uses efficient template notation, and avoids fluff. Every sentence adds value.

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 no output schema, the description should explain what the tool returns (e.g., chain results). It does not. It also omits error scenarios. For a tool with two parameters and no output schema, this is incomplete.

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 0%, but the description adds meaning by explaining how '{{input}}' is replaced, which relates to the 'input' parameter. It does not elaborate on the 'name' parameter beyond what the schema provides. For a 2-parameter tool with low coverage, this is adequate but not exemplary.

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 'run' and the resource 'saved chain recipe'. It explains the template substitution behavior, which distinguishes it from listing or saving chains. However, it does not explicitly differentiate from the sibling tool 'chain_run', which might have a similar 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?

The description provides some context like 'SSRF-guarded, no auto-pay', but it does not specify when to use this tool versus alternatives. There is no guidance on prerequisites, when not to use it, or which sibling tools to consider instead.

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?

Without annotations, the description describes a read-only operation ('list'), but does not explicitly state the absence of side effects or other behavioral details. Adequate for a straightforward listing 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?

The description is a single concise sentence with no filler, front-loading the verb and resource. Every word contributes 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?

Given the tool's simplicity (no parameters, no output schema), the description fully covers its purpose and output. It is complete for an agent to invoke 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 has zero parameters, so schema description coverage is 100%. The description adds value by stating what the output contains, which compensates for the lack of parameters, but no additional parameter semantics are needed.

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 'list' and the resource 'saved chain recipes', specifying the returned fields (name, description, step count). It effectively distinguishes from sibling tools like chain_save and chain_invoke.

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 listing recipes but provides no explicit context on when to use versus alternatives or when not to use. For a simple list tool, the lack of guidance is acceptable but not exceptional.

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 full burden. It discloses SSRF-guarded, no auto-pay, max steps, and return of each step's result. However, it lacks details on error handling, timeouts, or behavior on step failure. The information is adequate but not exhaustive.

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 plus a parenthetical, each sentence adding new information: main purpose, usage details and constraints, and a summary label. It is front-loaded, dense, and contains 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?

Given the tool's complexity (chaining multiple calls) and simple schema (one parameter, no output schema), the description covers the core concept, usage pattern, constraints, and return structure. It could include more on error handling or output format, but it is largely complete for practical 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 0%, so description must compensate. It does by defining the steps structure as [{url,tool,args}] and explaining the {{prev}} variable injection. This adds meaningful guidance beyond the bare schema, though it doesn't enumerate all properties (e.g., required fields are implied).

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 action: 'Chain multiple MCP tool-calls across peer agents in ONE request.' It specifies the resource (MCP tool-calls across peer agents) and verb (chain). It distinguishes from sibling tools like chain_invoke, chain_list, chain_save by labeling it as the 'connect agents into a pipeline primitive'.

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 explains how to use the tool: steps array with url, tool, args and the {{prev}} injection syntax. It also provides constraints (Max 5 steps, SSRF-guarded, no auto-pay). However, it does not explicitly mention when not to use it or compare to alternatives like chain_invoke.

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?

Without annotations, the description discloses the steps structure, max 5, placeholders, and bounded storage. However, it does not mention overwrite behavior, naming constraints, or success/failure outcomes, which would enhance 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 extremely concise, using one sentence with a parenthetical and two short sentences. No unnecessary words, fully front-loaded with key 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?

Given no output schema, the description should mention what the tool returns. It does not. It also omits validation behavior for steps. However, it provides enough context for a simple save operation, hence a 3.

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 0%, so the description must explain parameters. It details the steps format and placeholders, but does not explain the 'name' or 'description' parameters. This partial coverage gives a baseline score 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 clearly states the tool's purpose: 'Save a reusable chain as a named recipe' with details on steps format. It distinguishes from sibling tools like chain_invoke by explicitly mentioning 'Replay later with chain_invoke'.

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 provides clear context for when to use this tool ('save a reusable chain') and references the alternative for replay (chain_invoke). Could be improved by mentioning when not to use it, but still effective.

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 provided, the description fully describes behavioral traits: claiming triggers a SaSame Audit endpoint check, ghosts are rejected, verification is not legal ownership, and removal requires email. This goes beyond minimal 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?

The description is concise (5 sentences), front-loaded with purpose, and every sentence adds value: context, process, clarification, and alternative action. No superfluous 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 explains the outcome (verified or ghost rejected) and mentions removal. Without an output schema, it provides enough context for an agent to understand the tool's effect. Minor gap: not specifying the response format if verification fails, but still sufficient.

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 all three parameters. The tool description does not add significant meaning beyond the schema's parameter descriptions; it merely restates context. Baseline score 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 states the tool's purpose clearly: 'Claim your listing in the SaSame Agent Census.' It specifies the action (claim), the resource (listing in census), and distinguishes from removal via email.

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 explains when to use the tool: if your agent/MCP was auto-indexed and is 'unclaimed'. It also states when not to use: for removal, email instead. It does not explicitly name sibling tools but provides sufficient context for decision-making.

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 provides key behavioral traits: read-only, no auto-pay, no custody. This adds value beyond the schema, though rate limits and authentication are not 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 concise, front-loaded with the main purpose, and every sentence contributes necessary information without 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 lack of output schema and annotations, the description adequately covers the tool's inputs, outputs, and safety profile. It lacks error handling details but is sufficient for an agent.

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 described in the input schema (100% coverage). The description does not add additional semantic detail beyond what the schema already provides, so baseline 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's purpose: verifying a third-party provider and obtaining a live x402 payTo address and quote. It differentiates from siblings like 'verify_agent' by emphasizing the unique output (commission record) and read-only nature.

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 verification before settlement and states 'no custody, no skim, no human latency,' but it does not explicitly list when not to use this tool or suggest 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?

With no annotations, the description carries full burden for behavioral disclosure. It does not state if the tool is read-only, requires authentication, has rate limits, or the format of results. The brief description omits critical operational details.

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 fluff, but it lacks necessary detail. It is front-loaded with the verb, but the brevity compromises informativeness.

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 tool with 2 parameters and no output schema, the description is incomplete. It does not explain what the comparison yields (e.g., list, scores) or how to interpret results. More context is needed 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 description coverage is 0%, so the description must compensate. It only implicitly mentions 'category' and does not describe the 'limit' parameter or explain how quality/price affect parameters. No extra meaning 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?

The description states it compares payable agent services by quality and price within a category, which is a specific verb+resource combination. It distinguishes from siblings like 'find_services' or 'find_cheapest_service' by implying a side-by-side comparison, but the nature of the output (e.g., ranked list) is not specified.

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 on when to use this tool versus alternatives like 'find_services' or 'find_cheapest_service'. The description does not provide context for selection, exclusions, or prerequisites.

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?

Without annotations, the description carries full burden. It discloses key behavioral traits: no fabrication, returns empty when no data, is a living aggregate. However, it omits details on authentication needs, rate limits, or performance implications.

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 two sentences covering the core functionality and output. It is front-loaded but could be more structured. No wasted words, but the second sentence is a bit fragmented.

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 (no params, no output schema), the description is complete. It explains the data source, honesty policy, and what the output includes. No additional context is necessary.

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 tool has zero parameters, and the baseline is 4. The description adds value by detailing the output fields (top need phrases, % matched, total sessions, time window), which goes beyond the empty 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 the tool's function with specific verbs and resources: 'aggregate of what agents have asked for via register_intent'. It distinguishes itself from siblings by focusing on demand aggregation, not search or other actions.

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 alternatives. It lacks context about the intended use case and does not mention exclusions or alternative tools.

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 provided; description lacks explicit statement on read-only nature, rate limits, or side effects. Mentions live catalog and varying size but insufficient for full 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?

Two concise sentences, front-loaded with key info (FREE, live catalog, return fields). 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?

Covers purpose, return fields, and usage context, but lacks output schema and fails to mention pagination or result limits. Adequate for a simple search 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 has 100% coverage and describes query parameter. Description adds minimal extra 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?

Clearly states the tool searches a live catalog for relevant services, returning ranked matches with specific fields. Distinguishes from siblings by specifying the x402 agent-economy catalog.

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?

Provides context that the tool is FREE and useful for discovering agents/APIs, but does not explicitly state when not to use it or mention alternative tools like find_services.

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 takes full burden. It discloses key behaviors: submission is free, reviewed by a human, nothing is auto-sent. This is sufficient for safe usage, though it doesn't detail response format or error handling.

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 paragraph, front-loading purpose and usage. All sentences are justified and no fluff. Slightly longer due to listing services, but efficient for the information provided.

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 simple input schema (4 params, no output schema), the description adequately covers the tool's purpose, usage, and behavior. For a submission tool, it provides enough context for an agent to invoke it 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% with parameter descriptions. The tool description adds context by specifying what 'need' and 'contact' mean in the engagement context, and notes optionality of budget/urgency. This adds value 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?

The description clearly states the tool commissions SaSame to build or operate AI systems, with specific examples of what SaSame does (MCP servers, integrations, RAG, agents). It distinguishes this tool from siblings, which are mostly generic utilities.

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 explicitly says when to use this tool ('if your user needs MCP/Claude/RAG/agent work built') and explains the process (submit, human reviews, not auto-sent). It provides clear context but does not explicitly list exclusions or alternatives, though siblings are unrelated.

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 provided, but the description fully discloses behavior: cross-checks with on-chain resolver, returns verdicts 'match' or 'mismatch' with poisoning warning, and optional ed25519 receipt. No contradictions with non-existent 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?

Description is dense but well-structured: core function, verification, use case, optional feature. At around 100 words it is slightly long but every sentence adds value. Could be slightly more concise, but still effective.

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 no output schema, the description explains return values (verdict, warning, receipt). It covers main use case, edge case (poisoning attack), and optional signing. With 2 params and full schema coverage, it is 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?

Input schema has 2 parameters with 100% description coverage. The description adds significant value beyond schemas: explains auto-detection, cross-checking logic, verdict meanings, and signing behavior. Schema descriptions are minimal; description enriches them.

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 performs ENS resolution with on-chain cross-checking for fund safety. It distinguishes itself as 'the single most fund-critical ENS lookup' and explains auto-detection of direction, which is specific and not a tautology.

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 explicitly states when to use the tool: for fund-critical lookups where trusting one vendor is risky. It explains the auto-detection of direction and the verdict system, and mentions optional signing. No explicit exclusions but provides clear context.

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 are provided, so the description carries full burden. It only states the purpose but omits behavior details such as output format, authentication requirements, rate limits, or the meaning of 'payable' and 'x402'.

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?

Single sentence with no wasted words. However, the conciseness comes at the cost of omitting important details, which is a trade-off.

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 annotations, output schema, and low schema coverage, the description is highly incomplete. It fails to explain return structure, pagination, or the ranking mechanism, leaving significant gaps for the agent.

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 adds no meaning beyond parameter names. It does not explain the 'category' format or the 'limit' parameter's role, leaving the agent without necessary context.

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 'Find' and the resource 'cheapest payable (x402) agent services in a category'. It effectively distinguishes from sibling tools like find_services (which likely lists all) and compare_services (which compares).

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 versus alternatives like compare_services or competitive_scan. The context signal of many related tools suggests a need for such guidance. Usage is implied but not clarified.

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, description carries full burden. It discloses that listings are content-verified and payable via x402, and that ghosts are filtered. Lacks details on pagination or limits, but is adequate for a read-only discovery 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?

Three sentences, front-loaded with purpose, no redundant phrases. Every sentence adds value.

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 simple schema and no output schema, description provides sufficient context for a discovery tool, including contrasting with sibling. Minor omission: no mention of result limits or pagination, but not critical.

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 has 100% coverage on the single optional parameter 'category'. Description does not add beyond the schema's example values. Baseline 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 it discovers VERIFIED, payable AI-agent services, and explicitly distinguishes from ecosystem_search for unverified catalog. The verb 'discover' and resource 'AI-agent services' are specific.

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?

Provides explicit alternative (ecosystem_search for unverified) and implies when to use: when you need verified and payable services. No explicit when-not-to-use but alternative covers that.

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 provided, so description carries full burden. Discloses multi-feed querying, bridging through USD/EUR for exotics, returned fields (median, per-source rates, deviation, staleness, verdict), and optional ed25519 receipt. Also highlights potential 23-hour old ECB fixing, enhancing 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?

Description is concise, front-loaded with core purpose, and every sentence adds essential information. No redundant or vague phrases, making it highly efficient.

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 no output schema, description sufficiently details return fields (median, per-source rates, max deviation bps, staleness_sec, verdict) and notes the ed25519 receipt option. Lacks mention of error handling or unsupported currencies, but overall complete for intended 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% with descriptions for all parameters. Description adds value for the 'sign' parameter by explaining its effect (attaches ed25519 receipt), but does not further elaborate on other parameters beyond schema. Baseline 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?

Clearly states it provides a triangulated, multi-feed FX rate with timestamped reconciliation. Distinguishes itself by noting it is a strict superset of fx_rate, exposing ECB fixing staleness and source divergence, which differentiates it from sibling tools like price_verified.

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?

Implies usage for scenarios needing reconciled rates and awareness of staleness, but does not explicitly state when to use over alternatives or list exclusions. The mention of being a superset provides some guidance, but lacks comprehensive comparison with all siblings.

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 are present, so the description carries the burden. It states the standard is 'Free and open forever', indicating no cost or restrictions. However, it does not mention read-only behavior, idempotency, authentication needs, or other traits.

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 the core action, then expands on the standard's attributes. It is slightly verbose but each sentence adds informational value. Could be trimmed for tighter 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 no output schema, the description describes the standard's content and philosophy but does not specify the return format (e.g., JSON, text, structure). This leaves some ambiguity for the agent about what to expect.

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?

With zero parameters and 100% schema coverage, the description adds no parameter-specific detail but effectively communicates the tool's simplicity. The description adds meaning by explaining what the standard contains, compensating for the lack of 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 the tool returns 'the open Agent-Tool Discoverability Standard (v0.1)' with a specific verb 'Return'. It defines the standard's purpose and distinguishes from sibling tools like verification or auditing 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?

No explicit guidance on when to use this tool versus alternatives. It does not mention prerequisites, alternatives, or scenarios for use. While the context implies it's for retrieving the standard, no comparative guidance is provided.

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 are present, so the description carries full burden. It discloses that the tool returns a roster with content_verified or unverified entries, filters out 'ghost' agents, and includes recent posts. It mentions 'open standards' and 'machine-readable.' While it lacks details on pagination, rate limits, or authentication requirements, for a read-only tool this is sufficient 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 three sentences with no wasted words. It front-loads the main purpose and function, then adds usage guidance and a call to action. Every sentence serves a purpose.

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 no output schema and no annotations, the description explains the main return values (roster, posts) and the verification attribute. It also mentions free usage and how to appear. It does not specify the exact return format or data types, but for a simple feed tool, the description is reasonably complete. A 5 would require more detail on the structure of posts or pagination behavior.

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 zero parameters, so schema coverage is 100%. The description does not need to explain parameters. It adds value by describing the output structure (roster with verification status, posts), which compensates for the lack of an output schema. According to rubric, 0 parameters gives a baseline of 4, and the description meets that.

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 reads the guild feed, returning a roster and recent posts. It uses a specific verb (Read) and resource (guild feed). It mentions discovery of other agents and SaSame's activity, and distinguishes from join_guild by noting 'To appear here yourself, call join_guild.' However, it does not explicitly differentiate from other sibling tools like saloon_roster or agent_card_fetch, so it falls short of a 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?

The description instructs 'Use to discover other agents and SaSame's latest activity,' providing a clear use case. It explicitly points to join_guild for those wanting to appear in the feed. However, it does not provide exclusions or comparisons to other similar tools (e.g., saloon_roster), missing full guidance on when not to use this tool.

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 bears full burden. It discloses human moderation, content-verification check (SaSame Audit), self-claimed identity, and that it is free. It does not mention destructive actions (likely none) but provides good transparency for a registration 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?

The description is concise at 4 sentences, with a logical flow: purpose, process, identity aspect, and value summary. Every sentence contributes useful information without 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?

The tool has 4 parameters and no output schema. The description covers the process and outcomes (published, verified/unverified) but does not describe what the agent receives upon joining (e.g., confirmation message). Still fairly complete 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%, so baseline is 3. The description adds minor context (e.g., '1-3 sentences' for content, 'short headline') but does not significantly extend understanding 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 the verb 'join' and the resource 'Gold Rush Guild' with the purpose to broadcast an agent/service to SaSame's open agent feed for discovery. It distinguishes from siblings like 'guild_feed' (fetch feed) and 'saloon_sign' (similar but not identical) by specifying the action of joining and broadcasting.

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: 'a low-threshold way to gain discoverability' and outlines the process (submit note, human moderates, published). However, it does not explicitly state when not to use this tool or compare to alternatives like 'saloon_sign' or 'wanted_post'.

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 behavioral traits: SaSame audits the endpoint, ghosts rejected, no reselling, free listing. However, it doesn't describe the full lifecycle (update, removal), success/failure conditions, or potential limits (e.g., rate limits). With no annotations, more detail would be beneficial.

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 (3 sentences) and front-loaded with the primary action. No superfluous text. However, it's a single block; breaking into bullet points could improve readability.

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 covers the marketplace context, audit process, and revenue model. However, it lacks details on the response format, error handling, or constraints. For a 6-parameter tool with no output schema, this is adequate but not comprehensive.

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 baseline is 3. The description adds minimal context beyond the schema (e.g., endpoint is audited, price examples). It doesn't significantly enhance parameter understanding 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 purpose: listing a paid AI-agent service in the Gold Rush Market. It uses specific verbs ('list') and resources ('paid AI-agent service', 'Gold Rush Market'), distinguishing it from sibling tools like find_services (search) and compare_services.

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 context (free to list, human-moderated) but lacks explicit when-to-use or when-not-to-use guidance compared to alternatives. It doesn't exclude scenarios or mention prerequisites like having an endpoint, though it implies the endpoint is needed.

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, description carries full burden. Discloses sources (wikipedia, hackernews, duckduckgo), honesty about coverage gaps (no Crunchbase/Pitchbook/proprietary data), and that disagreements are surfaced not blended. Could mention idempotency but not required.

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 purpose, no wasted words. Could be slightly more structured but very efficient.

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?

Despite no output schema, description fully explains return structure, source list, and honesty policy. Covers all necessary context for an agent to understand what the tool does and its limitations.

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. Description adds context about output shape and sources but does not enhance individual parameter descriptions beyond schema. No additional parameter guidance.

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?

Clearly states the tool does 'corroboration-graph contract for market or competitive research' with specific verb and resource. Differentiates from sibling 'research_corroborate' by focusing on market/competitive landscape. Detailed output structure and sources are given.

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?

Implies usage for market research requiring independent-source corroboration, but does not explicitly state when to use this vs siblings like 'research_corroborate' or alternatives. No when-not scenarios mentioned.

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 adds important behavioral info: SSRF protection, 20s timeout, payment policy. This helps the agent understand side effects and limitations. Could mention error handling or result 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?

Extremely concise: one sentence covering purpose, followed by key constraints. No fluff, front-loaded with main 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?

Given no output schema and 0% parameter coverage, the description covers core functionality, security, timeout, and payment. Missing parameter details and error handling make it moderately 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?

Schema coverage is 0%, and the description does not explain individual parameters (url, tool, args). While 'tool' and 'url' are implied, 'args' is not described. The description fails to compensate for the lack of 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 clearly identifies the tool as calling a tool on another MCP server via SaSame. It uses specific verb('Call') and resource('tool on another MCP server'), distinguishing it from sibling tools like mcp_introspect.

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 context for usage ('route a request through SaSame to a peer agent') and constraints (SSRF-guarded, timeout, no auto-pay). It doesn't explicitly state when not to use it, but the context is 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?

Discloses key behaviors: read-only and SSRF-guarded. With no annotations provided, this is valuable. Lacks details on error handling or response behavior, but sufficient for a simple 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 succinct sentences, front-loaded with action and objective. Every sentence adds value, no waste.

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 purpose, usage context, and safety. For a simple tool with no output schema, it's mostly complete. Could explicitly mention that it returns a list of tools, but not required.

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 only parameter 'url' is described as 'Streamable HTTP URL', adding crucial context beyond the schema type. Could be more specific about format, but adequate.

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 (connect, list) and resource (another MCP server's tools), and distinguishes from sibling tools like mcp_call by specifying it's for discovery before chaining.

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?

Provides usage context ('before chaining to it') and mentions SSRF-guarded, read-only nature. However, no explicit when-not-to-use or direct comparison with 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?

With no annotations, the description fully carries the burden. It discloses enforcement, signed denial on rejection, and return values (remaining + signed line-item). Lacks side effect details but is transparent for a charge 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?

Three concise, front-loaded sentences. Every sentence adds value: purpose, behavior, and context. No unnecessary words 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?

Given 3 parameters, no output schema, and no annotations, the description covers the core behavior and return. Missing details like error handling or auth, but overall adequate for an agent to understand usage.

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 covers all 3 parameters with descriptions. The description reiterates the general purpose but adds no new meaning beyond the schema. 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?

Clearly states the verb 'Record a charge' and the resource 'against a meter', and emphasizes the enforcement of a cap. This distinguishes it from sibling tools like meter_open and meter_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?

Explicitly describes the rejection scenario when budget is exceeded, and explains why this tool exists (budget enforcement in code, not trusting agent self-regulation). Could be improved by noting when to use other tools first, but sufficient.

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 provided, the description fully carries the burden. It discloses behavioral traits: tamper-evident, third-party, no funds held, ed25519-signs, returns signed receipt verifiable with trust_pubkey. This is comprehensive for a meter-opening 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?

The description is a single, well-structured paragraph front-loaded with the core purpose. Every sentence adds value, and there is no redundancy or fluff. It is concise yet informative.

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 tool's novelty and lack of output schema, the description covers the purpose, usage guidelines, return values (meter_id + signed receipt), and behavioral guarantees thoroughly. It is complete for an agent to understand and invoke 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?

Since schema description coverage is 100%, the baseline is 3. The description adds minimal new parameter information beyond repeating the schema, but it does provide context like 'budget cap in your own units' and 'unit label free text'. No significant enhancement.

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 'open' and the resource 'meter', and it distinguishes this tool from siblings like 'meter_charge' and 'meter_status' by explaining it creates a budget enforcement mechanism. It is specific about the neutral, tamper-evident nature.

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 explicitly says 'Use when a principal/orchestrator wants to give a sub-agent a capped budget and enforce + audit it.' It also clarifies what SaSame does not do (holds no funds, not a payment processor), but lacks explicit when-not-to-use or alternative tools.

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 are provided, so the description carries the full burden. It discloses that the log is append-only and tamper-evident, and explains re-verification. The verb 'Read' implies idempotence and safety, but the description stops short of explicitly stating read-only or no side effects. Additional details like authentication or rate limits are not needed given the simple read nature.

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, somewhat dense sentence but packs essential information: the tool's action, data fields, and key properties. It is front-loaded and avoids wasted words, though it could be slightly more structured (e.g., splitting into two sentences).

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?

Despite having no output schema, the description thoroughly describes the expected return values (budget, spent, remaining, signed line-item history) and additional context (tamper-evident, re-verifiable with trust_pubkey). For a tool with one parameter and a straightforward read purpose, this is fully 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 input schema has 100% coverage for the single parameter meter_id, with description 'The meter_id from meter_open'. The tool description does not add any further meaning about the parameter beyond what the schema already provides, 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 uses the specific verb 'Read' and clearly identifies the resource ('meter's current state') and the data returned (budget, spent, remaining, signed line-item history). It distinguishes from sibling tools like meter_charge and meter_open by focusing on reading 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 description implies usage for reading meter state and mentions re-verification with trust_pubkey. It does not explicitly state when not to use or provide alternative tool names, but the context from siblings and the verb 'Read' make the primary usage 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?

No annotations provided, so description carries burden. States reade-only extraction (no destructive side effects), reveals use of tesseract, free status, and return fields. Does not mention rate limits or image size constraints, but adequate for a simple extraction.

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 concise sentences: function, return values, paid alternative. No superfluous information, front-loaded with key details.

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 extraction tool with one parameter, description covers purpose, output, and limitations. Lacks output schema, but mentions 'text preview + confidence' sufficiently. No major 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?

Single parameter with full schema description (100% coverage). Description adds that image URL must be public, which aligns with schema's 'Public URL'. No additional value 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?

Clearly states verb 'extract text from an image URL' using SaSame OCR. Distinguishes free vs paid endpoint, and mentions returns text preview + confidence. No ambiguity.

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?

Explains that free version returns preview, while full extraction requires paid endpoint. Provides context on cost and truncation, but does not explicitly state when to use alternatives among sibling tools (though none are OCR-specific).

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 fully discloses behavior: reconciliation across 2-3 providers, per-RPC values, block pinning, consensus verdict, max deviation bps, and the risk of stale answers. 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 informative but somewhat lengthy; it front-loads the main purpose but could be more concise. Every sentence adds value, but minor redundancy exists (e.g., the first sentence already covers the second).

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?

Without an output schema, the description mentions return elements (per-RPC value, block, consensus, deviation) but lacks precise structure or examples. It is adequate but could be more detailed for a tool with 6 parameters and no output schema.

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 each parameter has a decent description. The tool description adds overall context but does not significantly enhance individual parameter understanding beyond what is in 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?

Description clearly states it performs multi-chain onchain reads reconciled across 2-3 RPC providers, listing specific operations (block_number, gas_price, etc.) and positioning it as a focused primitive that collapses several eth_* calls. It distinguishes itself from sibling tools like chain_invoke or chain_run.

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 explains when to use (for verified onchain reads detecting staleness) and implies it replaces separate eth_* calls. It does not explicitly mention when not to use or point to alternative tools, 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.

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

With no annotations, the description carries full burden. It discloses the three sources checked, the reconciliation logic, and the return types including a signed attestation. However, it omits behavioral details like network call timeouts, error handling specifics, or authentication requirements. Still, it provides substantial transparency for a complex 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?

The description is a single, well-structured paragraph that is concise yet informative. It uses bullet points for sources and return values, is front-loaded with the core purpose, and every sentence adds value.

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 no output schema and no annotations, the description covers the essential aspects: inputs, sources checked, and return types. It could mention error scenarios or the exact attestation format, but the four possible results cover common cases. For a reconciliation tool with three parameters, it is largely 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?

Schema coverage is 100% (all parameters described). The description adds context beyond the schema: it explains that declared_price is reconciled against a live 402 quote and that check_agent_card defaults to true. It reinforces the purpose of each parameter in the cross-check process.

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: 'Cross-source liveness-vs-declared reconciliation for any agent/service endpoint.' It lists three specific sources checked and possible return values. It distinguishes from sibling tools by noting it works for any directory, not just SaSame, and is for pre-spend validation.

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 specifies when to use: 'before committing spend' and 'to validate a row from ANY directory.' It does not explicitly mention when not to use or provide alternatives, but the context is clear and the sibling list implies alternatives exist. A slight lack of exclusions prevents a 5.

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 provided, but description fully discloses behavior: parallel queries of multiple feeds, reconciliation to median, return of per-source values, deviation, staleness, verdict, and optional signing. 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?

Two sentences with no wasted words. First sentence packs key functionality and output; second provides usage guidance. Efficient 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?

With no output schema, description explains all key return values. All 3 parameters documented. Sibling tools include fx_verified for forex, providing contrast. Complete for a data-fetching 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 coverage is 100%. Description repeats parameter defaults and max ids limit already in schema, but adds minor context about sign returning a 'portable ed25519 receipt'. Baseline 3 with slight addition.

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?

Clearly states it provides cross-source-reconciled crypto/asset prices, specifies output includes reconciled median, per-source values, max deviation, staleness, and verdict. Distinguishes from sibling fx_verified by focusing on crypto.

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?

Describes that it is a strict superset of a single-source fetch and advises using for financially-load-bearing decisions. Does not explicitly state when not to use, but provides clear context for appropriate use.

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?

Without annotations, the description carries the transparency burden. It details return structure, states no free-text upsell, and implies read-only retrieval. However, it omits potential cost, rate limits, or idempotency, so it is good but not fully transparent.

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 the key verb and object, and is only four sentences. Each sentence adds value, though the middle sentence listing fields could be slightly more concise. Overall efficient.

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 no output schema, so the description compensates by detailing the return format. It covers the main expected data but lacks mention of error conditions, empty results, or invocation prerequisites. Sufficient for a retrieval 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 coverage is 100%, so the baseline is 3. The description adds no per-parameter meaning beyond what the schema already provides (e.g., n defaults, topic, intent_token, freshness_days). It only gives output context.

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 'Full-resolution PubMed evidence retrieval' and enumerates the returned fields (PMID list, per-paper details). It distinguishes itself by contrasting with 'pubmed_lookup preview', making the purpose specific and actionable.

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 context by saying it replaces a 'thin preview' with a 'corroboration-aware structured response', but does not explicitly state when to use this versus alternatives like 'research_corroborate' or when not to use it. The guidance is implicit, 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?

With no annotations, the description carries full burden. It discloses determinism, honesty about zero values, and that answers are computed from real data without fabrication. For endpoint lookups, it specifies returning audit record and attestation. It could mention read-only nature explicitly but adds significant behavioral context.

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 efficient with 4 sentences, front-loading purpose and scope. Each sentence adds distinct value: core function, data source, behavioral promise, and concrete examples.

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 no output schema and simple params, description covers purpose, data source, behavior, and example queries. It omits return format for general questions but clarifies endpoint-specific output. Adequate for an agent to assess applicability.

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%, providing baseline. Description adds value by explaining the optional endpoint parameter's purpose (specific lookup), imposing a max length on question, and giving examples of answers. It enhances understanding 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 the tool does deterministic Q&A over census and audit data, with specific examples. It distinguishes from siblings like census_stats and census_search by emphasizing factual, non-fabricated answers and specific endpoint lookups with attestations.

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 examples of when to use the tool (factual questions) but lacks explicit guidance on when not to use it or alternatives. It implicitly suggests usage for specific endpoint lookups versus general stats but does not contrast with sibling tools.

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 full burden. It discloses that the receipt is signed, tamper-evident, and verifiable offline. It also describes the output format (signed_by, signature, canonical_json), providing transparency beyond just the input schema.

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 purpose, and contains no unnecessary words. It efficiently conveys key 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?

Given the three parameters and no output schema, the description covers purpose, usage, and output format well. It would benefit from mentioning prerequisites or limitations, but overall it is sufficient for an AI agent.

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 adds limited meaning beyond the schema. It provides example values for 'action' and mentions the output structure, but does not significantly enhance 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?

The description clearly states the tool retrieves a signed receipt for an action, using a specific verb (get) and resource (receipt). It distinguishes from the sibling 'verify_receipt' by focusing on issuance.

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 explains the need for third-party signing due to LLM fabrication risks and mentions use cases (audit trails, dispute evidence). It does not explicitly list when not to use or alternative tools, but the context is 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?

With no annotations, the description discloses key behaviors: cost-zero, no LLM in path, deterministic, returns three items, and demand aggregation via demand_radar. It could mention idempotency or side effects, but current detail is good.

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 a single paragraph that front-loads key info. It is concise but includes some parenthetical asides. Could be broken into bullet points for easier parsing, but overall efficient.

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 no output schema, the description thoroughly explains return values (token, nearest tool, note) and mentions demand aggregation. It also covers cost and determinism. Sufficient for an agent to use 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% and descriptions are clear. The tool description adds context but does not significantly enhance understanding beyond the schema. Baseline 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?

Description clearly states 'ONE-FIELD survey wall' and verb 'tell us what you are trying to do'. It specifies the resource (intent registration) and distinguishes from sibling demand_radar by describing its output and relation to aggregated demand.

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 implies usage context (register intent, get nearest tool) and mentions cost-zero, no LLM. However, it does not explicitly state when to use this tool vs alternatives like ecosystem_search or demand_radar, nor does it provide 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?

No annotations are provided, so description carries full burden. It discloses injection quarantine, output structure with corroboration counts and freshness, source list, and zero upsell. This covers safety, data quality, and behavioral traits comprehensively.

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?

At ~100 words, the description is dense but every sentence adds value. It front-loads the core value proposition and then details output and parameters. Slightly long but well-organized.

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, but description thoroughly explains the structure of the evidence graph (claims, source_index, coverage, corroboration, disagreements, freshness). Covers all key aspects for a complex tool with 5 parameters and rich output. No 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 coverage is 100%, so baseline is 3. Description adds meaning beyond schema for all parameters: explains intent_token origin, freshness_days behavior (flag vs drop), min_corroboration default, and sources as a subset. This is above average but not extremely elaborate.

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?

Clearly states it returns a structured evidence graph with claims, source index, and coverage, contrasting with web_research's free-text brief. The verb 'corroborate' and resource 'evidence graph' are specific and distinguish it from 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?

Explicit comparison to web_research (same generality but structured output) and notes caller can restrict sources. While not exhaustive, it provides clear context for when to choose this tool over a similar one.

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 provided, so description carries full burden. It discloses deterministic nature, heuristic method, no network/LLM call, and return content (estimate + breakdown). Missing performance limitations but adequate for this 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?

Three sentences, front-loaded with main purpose, each sentence adds value. No wasted 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?

Tool is simple, schema covers parameters, description mentions return content (estimate + breakdown). Could detail the breakdown structure, but overall sufficient.

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. Description adds context about heuristic calibration and why model_family matters (differ on code vs prose), but does not significantly enhance parameter 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?

Description clearly states it estimates token count deterministically, using a heuristic calibrated to GPT/Claude tokenizers. It distinguishes from siblings that involve LLM calls by explicitly stating 'No LLM call, no network.'

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?

Includes explicit usage context: 'For budget planning before sending text to an LLM.' Does not explicitly state when not to use or mention alternative tools, but the context is 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?

Given no annotations, the description explains the key type and purpose, and implies a safe read operation. It omits potential side effects but there are none expected. Additional context on caching or key rotation 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 mostly concise with three sentences, but the last sentence is slightly verbose. Front-loads the core action well.

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 parameterless, no-output-schema tool, the description fully explains what the tool returns and its significance in the verification ecosystem.

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?

No parameters exist; schema coverage is 100%. The description does not need to add param info, meeting the baseline for zero-parameter tools.

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 returns SaSame's ed25519 public key, explaining its purpose for offline verification. It distinguishes from siblings like verify_receipt that depend on this key.

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 as a prerequisite for verification but does not explicitly state when to use or not use, nor compare to 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?

With no annotations provided, the description fully carries the behavioral disclosure burden. It clearly states that payment is read-only (never auto-pays), describes the filtering by audit data, and specifies the returned items (payTo, grade, attestation). However, it lacks details on side effects, idempotency, rate limits, or permissions, which would warrant a 5.

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 dense paragraph that front-loads the core purpose ('ONE-CALL discover->quote->pay loop'). It efficiently conveys the steps and constraints without wasted words, but could be improved with clearer structure (e.g., bullet points or separate sentences for distinct behaviors).

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 tool's complexity and lack of output schema, the description adequately covers the main functionality, edge case (empty state), and key behavioral constraint (read-only payment). However, it does not fully describe the output structure (e.g., exact fields, types) nor explain 'ghost-filter' in enough detail, leaving some gaps for a tool that combines multiple operations.

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 four parameters are fully described in the input schema (100% coverage), so the description adds no new parameter-specific information beyond the schema. The description's procedural details (ghost-filter, fetch quotes) are related to the overall behavior but do not clarify parameter usage or constraints 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?

The description clearly states that this tool performs a three-step process (discover, quote, pay) in one call, specifically searching the census for capabilities, filtering by audit data, fetching live quotes, and returning payment info. It distinguishes itself from siblings by explicitly claiming to eliminate the 'discover->verify->quote 3-hop pattern'.

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 context on when to use this tool (to collapse multiple steps into one) and mentions an edge case (empty state). However, it does not explicitly list alternatives or state when not to use it, missing an opportunity to differentiate from sibling tools like census_search or x402_inspect.

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, description fully discloses behavior: returns specific fields, does independent fetch, never auto-pays for x402 quotes, and provides signed attestation. Also shares statistical warning about ghost endpoints.

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?

Every sentence provides value: core purpose, return fields, broad applicability, a key statistic, and conditional behavior. No wasted 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?

Despite having no output schema, the description enumerates all return fields and explains key behaviors. Covers all parameters and provides additional context (ghost filter evidence, x402 behavior). Complete for a verification 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 coverage is 100%, so baseline is 3. Description adds context beyond schema (e.g., 'optional ed25519 signed attestation' for sign, 'live x402 quote' for expect_x402, 'cached audit' for max_audit_age_days).

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?

Clearly states it does independent liveness and content verification of any agent/MCP/x402 endpoint. Distinguishes itself from SaSame-specific tools by noting it works on any HTTPS endpoint.

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?

Provides clear context for use (before spending), and mentions optional x402 reconciliation. However, lacks explicit when-not-to-use or direct comparison to sibling tools like agent_handshake.

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 are provided, so the description carries the full burden. It discloses that the tool performs ed25519 signature verification, does not make external calls, and returns validity and grade/subject. It could additionally mention error handling or side effects, but it's sufficiently transparent.

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 long, front-loaded with the primary purpose, and every phrase adds value—no filler. Achieves maximum conciseness while conveying all essential 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?

For a single-parameter verification tool with 100% schema coverage and no output schema, the description covers the algorithm, inputs, outputs, and distinctiveness. It lacks explicit return format but is otherwise complete for its 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?

Schema coverage is 100%, and the description reiterates the required fields (signed_by, signature, canonical_json) in plain language, but adds no new information beyond what the schema already documents. 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 verifies an MCP-Ready Certificate offline, specifies the algorithm (ed25519), and distinguishes itself from siblings by noting it never needs to call SaSame and can be replicated in ~10 lines.

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 explicitly tells the user to pass the certificate object with three required fields, explains the purpose (offline verification), and distinguishes when to use this tool vs alternatives (e.g., no need for SaSame). It also mentions the openness, providing clear usage context.

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 fully carries the behavioral disclosure burden. It transparently details the signing algorithm (ed25519), offline verifiability, honesty caps (grade capped at B, delivery UNVERIFIED), and the output format (canonical JSON + signature).

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 dense and informative but could be slightly more concise. It front-loads the main purpose and includes all necessary details without excessive verbosity.

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?

Despite no output schema, the description explains the output (certificate as canonical JSON + signature) and covers limitations like honesty caps. The tool is simple with one parameter, and the description is fully adequate for an agent to understand invocation and expected result.

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 'url' with schema coverage 100% and a clear description. The description confirms the URL must be https, which is already implied in the schema. No additional semantics beyond the schema are provided, so baseline 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 audits an MCP server and issues an ed25519-signed certificate, with specific details about the certificate format and honesty caps. It distinguishes from siblings like 'audit_mcp' and 'verify_mcp_cert' by emphasizing offline verifiability and no callback.

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 explains what the tool does but does not explicitly guide when to use it over alternatives like 'audit_mcp' or 'verify_mcp_cert'. The mention of honesty caps and offline verification provides implicit context but lacks explicit when-to-use 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?

With no annotations, the description must disclose behavior fully. It explains the verification process and purpose, but does not mention potential failure modes, performance characteristics, or whether it is idempotent/safe. The description is adequate but not exhaustive.

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, front-loaded with the core action, then explaining use case. Every sentence adds value without redundancy. The description is efficient and well-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?

The tool is simple (one parameter with nested object, no output schema). The description explains the tool's purpose, input, and a typical use case (closing the portable-evidence loop). However, it does not describe the return format, which could be useful but is not critical.

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. The description adds value by explaining the receipt parameter in context: 'The receipt object returned by a *_verified call with sign:true'. This helps the agent understand where the value comes from and its format.

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 'Verify' and the resource 'ed25519 receipt'. It distinguishes from siblings by specifying receipts from '*_verified tools' with examples like 'price_verified', making it easy for an agent to select this tool correctly.

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 explains when to use the tool (after obtaining a receipt) and what it achieves (confirms attestation, unmodified status). It provides context for a downstream agent in a 'portable-evidence loop'. However, it lacks explicit guidance on when not to use it 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?

No annotations provided, so description carries full burden. States it inspects WITHOUT paying and is SSRF-guarded, implying read-only and safe operation. Could mention lack of side effects more explicitly, but sufficient.

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, zero waste. Front-loaded with main action and purpose. Efficient and clear.

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 simple tool with one parameter and no output schema, description covers essential aspects: what it does, safety, and intended use. Could mention output expectations, but not critical for basic comprehension.

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 'url' with 0% schema coverage. Description adds that it's a URL, which is helpful but lacks format constraints or examples. Adequate but minimal compensation.

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?

Clearly states the tool inspects x402 payment requirements (price/network/payTo) for a URL without paying. Verb 'inspect' plus specific resource (x402 payment requirements) makes purpose unmistakable. Distinguishes from siblings by unique function.

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?

Explicitly says 'For agents to quote a paid call before committing', indicating when to use. Does not mention when not to use or alternatives, but context is clear enough for an agent.

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