SaSame MCP Observatory + Gold Rush Town

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

Description discloses behavioral traits beyond annotations: records each statement, requires both party signatures for signed receipt, does not move funds or verify off-chain settlement. No contradiction with 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?

Three sentences, each providing essential information: action, condition, and limitation. No redundant phrases, front-loaded with key verb and resource.

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 4 required parameters and no output schema, the description adequately covers the tool's purpose, inputs, and constraints. It lacks return value explanation, but the absence of an output schema and the tool's simple output (a signed receipt) makes this acceptable.

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 adds meaning to the 'role' parameter by explaining buyer/provider, clarifies settlement_ref as a non-secret reference (matching schema description), and implies work_order_id ties to an agent transaction receipt. However, it doesn't fully describe all parameters; schema coverage is only 25%.

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 is for signing a settlement statement by buyer or provider, and explains the condition for a signed receipt. However, it does not explicitly distinguish from sibling tools like escrow_attest or receipt_issue, though the context of invoice settlement is clear.

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 states who should use it (buyer or provider), the precondition (matching statements from both parties), and when not to use it (for fund movement or off-chain verification). Provides explicit alternative suggestion to use a chain/processor receipt as settlement_ref.

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

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

Annotations indicate idempotentHint=true, destructiveHint=false, readOnlyHint=false (write operation). The description adds context: the tool issues a binding receipt that confirms mutually accepted terms, delivery and amount. It clarifies that the legacy name is retained for API compatibility, and explains the signing mechanism (provider signs provider_receipt_challenge). No contradiction with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

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

The description is front-loaded with the main action, then explains legacy naming, clarifies it's not a fiscal invoice, describes the receipt's binding nature, and gives a usage distinction. Each sentence adds value, though it is slightly verbose. Could be trimmed slightly, but overall 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 the tool has 3 parameters, no output schema, and moderate annotations, the description provides sufficient context: the purpose, when to use, what the receipt binds, and when to use an alternative tool. It does not specify return format, but the tool's name and description imply a receipt is issued. Overall, it covers the essential aspects.

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 3 parameters with only 33% description coverage (only 'external_invoice_ref' has schema description). The tool description mentions 'work_order_id' implicitly via 'after provider delivery' but does not explicitly map parameters. It mentions the signing challenge but does not explain 'signature_base64' directly. Description adds partial context but does not fully compensate for the low schema coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it issues a SaSame SRL-signed third-party agent transaction receipt after provider delivery, distinguishing it from a fiscal/tax invoice and from the separate SaSame SRL business invoice. The verb 'Issue' and specific resource 'third-party agent transaction receipt' are precise, and the differentiation from sibling tools like 'receipt_issue' is implied by context.

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 states when to use: 'after provider delivery'. Also provides a clear exclusion: 'If SaSame SRL itself sells a service, its separate accounting rail issues the normal SaSame SRL business invoice.' This gives the agent explicit when-not-to-use guidance and an alternative.

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 adds significant behavioral context beyond the annotations (readOnlyHint, openWorldHint). It states the response is SaSame-signed, explains privacy-minimization (no raw storage, only SHA-256 commitments), and clarifies legacy naming. This fully informs the agent of safety and side effects. No contradiction with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

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

The description is functional but somewhat verbose for a simple read operation. It includes explanatory notes about SaSame and legacy compatibility that add value but could be more succinct. The key action is front-loaded, but overall length could be reduced without losing clarity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (one required string parameter, no output schema), the description covers the essential behavioral and result context: privacy, signing, and what is stored. It lacks a description of the response format, but since no output schema exists, this is a minor gap. Overall quite complete for a read-only status 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?

With only one parameter (work_order_id) and 0% schema description coverage, the description should compensate by explaining the parameter's meaning or format. It only mentions 'work order' in passing but does not elaborate on what work_order_id is, expected format, or constraints. This leaves the agent guessing.

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 privacy-minimized state of an agent transaction receipt/work order and returns a signed statement. It distinguishes itself from sibling tools by emphasizing it is a read-only status check (not an issue or endorsement), and the annotation title 'Read a signed agent transaction-receipt state' aligns perfectly.

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 clarifies that the tool provides 'status only, not endorsement' and it is 'not a fiscal invoice', which helps the agent avoid misuse. However, it does not explicitly compare to closely related siblings like receipt_state or provide a when-to-use vs. when-not-to-use statement, so it lacks full guidance.

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

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

Annotations already provide readOnlyHint=true. The description adds 'no external action is triggered' and 'public', which is consistent but adds minimal extra context. No contradictory information, but limited behavioral disclosure beyond annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

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

Two sentences with no wasted words. Front-loaded with the core purpose, and the second sentence adds a critical clarifying behavioral note. 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 simplicity (one optional param) and no output schema, the description is fairly complete. It covers the return type (next-step links) and filtering topic. Missing a bit on the nature of 'links', but overall adequate for a straightforward read-only tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate. It mentions the paths (claim, interest, plans, monitoring) which correspond to several enum values, but does not explain 'all' or 'correction'. Provides partial clarification but not full parameter meaning.

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 returns public next-step links for specific paths (claim, interest, plans, monitoring) and is read-only. It distinguishes from sibling analytics tools by specifying the focus on passport next steps.

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 explicitly state when to use this tool versus alternatives like analytics_public_export or analytics_public_summary. There is no 'when to use' or 'prefer if' guidance, leaving the agent to infer from the description alone.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false. The description adds that it is public aggregate and excludes private owner analytics, which is consistent but not truly additive beyond annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

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

Two sentences, each contributing meaning: the core purpose and a constraint. No filler or redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with no parameters and clear safety annotations, the description is adequate. However, it lacks details on the return format or contents of the manifest, which could be helpful given 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?

No parameters exist, and schema coverage is 100%. The description does not need to add parameter details, so baseline 4 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 the tool returns the public aggregate Analytics Passport export manifest, with a specific verb and resource. It does not explicitly differentiate from sibling 'analytics_public_summary', but the resource name implies a distinct 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?

No guidance on when to use this tool versus alternatives like 'analytics_public_summary'. The description only notes a constraint ('No private owner analytics') but no explicit usage context 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?

Annotations already declare readOnlyHint=true, and the description adds the public nature and conditional behavior (parameterized vs. global). No side effects or auth details needed given readOnlyHint. 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, no waste. All information is front-loaded and relevant. 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?

For a simple read-only tool with two optional parameters and no output schema, the description covers the two modes and the resource. No additional information is needed.

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 0% description coverage for the two optional string parameters. The description explains that url/mcp_id specify a particular MCP and that omitting them returns global summary. This adds critical meaning, though format/constraints are not detailed.

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 'Read' and the resource 'public outside-in Analytics summary'. Distinguishes two modes: with url/mcp_id returns MCP-specific summary, without args returns global summary. This differentiates it from sibling analytics tools like audit_mcp.

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 on when to use with vs without arguments, implicitly guiding the agent on parameter usage. Does not explicitly mention when not to use or name alternatives, but the distinction is sufficient for this simple 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?

Annotations already show readOnlyHint and openWorldHint. Description adds specifics: handshake steps (initialize, tools/list, one read-only call over POST JSON-RPC), no auth-bypass, no payment, neutral status. Adds value but annotations already cover safety profile.

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?

Fairly concise with multiple sentences, all relevant. Front-loaded primary purpose, then details. Could be slightly tighter but 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 no output schema, description explains return includes grade, per-criterion evidence, and biggest gap. Covers limitations, directory pre-flight context, and scope. Complete for a 1-param tool with rich description.

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 'url' parameter with schema coverage 100% and description 'https' and 'ideally your own'. Description adds minimal additional meaning 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?

The description clearly states the tool grades an MCP server against a specific standard, runs a legitimate handshake, and returns grade/breakdown. It distinguishes from sibling tools like verify_mcp_ready and others in the list.

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 to run before directory submission (pre-flight), what it covers (mechanical reject reasons) and does not cover (privacy, identity, OAuth, etc.). Provides alternative for signed certificate: use verify_mcp_ready.

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?

Beyond annotations (readOnlyHint=true), the description adds important behavioral details: the log is append-only, an empty log returns 0, never fabricated activity, and caveats about party labels and recorded statements not being independent proof. 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 three sentences, starting with the core purpose. It is mostly concise, though the third sentence is somewhat long and could be split for readability. No unnecessary 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 the complexity (5 optional parameters, no output schema), the description provides essential behavioral context but lacks details about the return format, pagination via limit, error behavior, or how to interpret the results. This leaves gaps for an agent to use the tool effectively.

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 low (40%), and while the description mentions filtering by meter_id, agent_id, kind, or since, it adds little beyond the schema's existing descriptions for kind and since. The limit parameter is omitted entirely, leaving its purpose and constraints unclear.

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 queries SaSame's append-only audit log, lists the types of records included, and the title reinforces this. It distinguishes itself from siblings like meter_charge or receipt_issue by being the read-only log query tool.

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 notes it is read-only and can be used to reconstruct recorded activity, but does not explicitly contrast with sibling tools or specify when not to use it. The context implies it is for historical reconstruction rather than creating actions.

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 tool is an observation, not a safety verdict, and is ed25519-signed and offline-verifiable. It also outlines the data categories (attack surface, capability classes, unannotated share). However, it does not explain rate limits or potential costs beyond 'cost-zero', which is acceptable for a read-only view.

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 somewhat lengthy but every sentence adds value: it defines the resource, lists data types, notes signing, and sets expectations. It could be slightly more concise, but it is well-structured and front-loaded with the essential 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 zero parameters and no output schema, the description provides enough context: what the tool returns (aggregate, signed, with categories) and its role (first call, cost-zero). It does not specify the exact output format (e.g., JSON), but this is likely inferable from the ecosystem context. Overall, the information is sufficient for an agent to decide when to invoke it.

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, so the description does not need to add parameter information. The 100% schema coverage means no parameters are undefined. Baseline score of 4 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 begins with 'Zero-argument ecosystem view: SaSame's live State of the Agent Attack Surface', clearly naming the specific resource (ecosystem view) and its content (attack surface, capability classes, annotation share). This distinguishes it from sibling tools like 'capability_profile' which likely focus on individual agents.

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 states it's a 'frictionless first call' and 'cost-zero', implying it's an ideal starting point. It also notes the agent cannot self-produce this aggregate, signaling its uniqueness. However, it does not explicitly mention when not to use it or provide direct alternatives among 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?

With no annotations provided, the description fully discloses behavioral traits: it classifies capability-risk classes, flags missing safety annotations, gives an exposure tier, and notes newly exposed capabilities. It also states it is cost-zero and an observation, not a claim of safety. 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 and front-loaded with the key purpose. However, it is somewhat dense and uses inconsistent capitalization and hyphens, which slightly reduces readability. Still, it is reasonably concise given the amount of 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?

Given the single parameter and lack of output schema, the description provides comprehensive context: input (URL), what the tool generates (capability-risk classes, exposure tier, new risks, signed and verifiable), and its limitations. Covers all necessary aspects for an agent to use 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 description coverage is 100%, so baseline is 3. The description adds context about the URL being for a public MCP server and that the tool is a pre-call check, but does not elaborate on parameter details beyond the schema's description. Acceptable but not exceptional.

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 as a 'DEFENSIVE pre-call check for one public MCP server,' specifying the verb (check) and resource (MCP server). It distinguishes itself from siblings by detailing its capability-risk classification and focus on newly exposed risks, which is unique among the listed sibling tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly advises using it 'before wiring an untrusted MCP into an agent,' providing clear usage context. It also clarifies what the tool is not (not a vulnerability/malware scan), but does not explicitly compare to sibling tools or state when not to 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?

The description adds value beyond annotations by specifying the returned fields (name, description, step count), which is not covered by the readOnlyHint. It is consistent with the read-only nature implied by the annotation.

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 immediately conveys the tool's purpose and output. No extraneous words or structure.

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 list tool with no parameters, the description adequately covers the return fields. It does not explain scope (e.g., user-specific or all chains), but the title annotation 'List observed chains' hints at context. Overall sufficient but not 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?

With zero parameters and 100% schema coverage, the description has no need to add parameter information. Baseline for 0 params is 4, and no extra detail is necessary.

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 lists saved chain recipes and specifies the returned fields (name, description, step count). It uses a specific verb 'List' and resource 'chain recipes', distinguishing it from sibling tools like 'trust_compare' or 'verify_mcp_ready'.

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, nor does it mention when not to use it. Given the simple nature, this is a minor gap, but the dimension explicitly expects such 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?

Description adds context beyond annotations: 'free, read-only, deterministic — no LLM, no network' and explains return values. Annotations already have readOnlyHint=true; no contradiction.

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 fairly concise (a few sentences) and front-loaded with the main purpose. Could be slightly more structured, but no unnecessary info.

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 one parameter and no output schema, the description is complete: explains what it does, how to use, what to expect, and polling frequency. 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% (one parameter with description). Description adds value by specifying the ticket comes from engage_sasame and provides an example format ('inq_...'), which helps the agent understand the parameter better.

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 polls engagement status and reads operator replies, specifying the input (ticket from engage_sasame) and output (conversation thread, state, waiting status). It differentiates from siblings like engage_sasame (which opens) and reply_engagement (which replies).

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 to call after engage_sasame, pass the ticket, and poll periodically (e.g., once a day). Mentions it's free and read-only. Lacks explicit when-not-to-use or alternatives, but 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?

Annotations declare readOnlyHint=true and openWorldHint=false. The description adds that it returns a public teaser and distinguishes from paid/private content, which aligns with the annotation. No contradictions, and adds useful context beyond the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

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

The description is two brief sentences, front-loaded with the main purpose. Every sentence adds value, with no unneeded content.

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 zero parameters, no output schema, and simple read-only behavior, the description covers the essential information. It could optionally mention the return format, but the current content is sufficient 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?

The input schema has no parameters, so no parameter description is needed. Schema coverage is 100% trivially. The tool's description is adequate for a parameterless tool.

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 public MCP Gold Rush Chronicle teaser, using a specific verb and resource. It distinguishes itself by mentioning that detailed intelligence is paid/private, setting clear boundaries among siblings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description indicates when to use this tool (for public teaser) and explicitly notes that detailed intelligence requires payment/private access, implying when not to use it. While it doesn't name an alternative sibling, the context is sufficiently 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 SSRF-guarded, free, and the outcome (certificate re-issued, badge update). Annotations show idempotent and non-destructive, which matches the description. Adds context beyond annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

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

Front-loaded with main action, three sentences covering process and outcome. Slightly wordy but not excessively so.

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 thoroughly explains the verification process, required setup, and results. Single parameter is well-documented. 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 3. Description adds that the URL must be the same as claim_start and requires https, providing semantic 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 confirms domain-control proof and upgrades a listing from Observed to CLAIMED, with specific verification mechanisms (well-known file or DNS TXT). This is distinct from siblings like claim_start.

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 after claim_start and when domain proof is set up, but does not explicitly state when not to use or compare to alternatives. However, the context of sibling tools makes the 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?

Annotations already indicate idempotentHint=true and destructiveHint=false. The description adds behavioral context: returns a challenge token, requires domain proof, and upgrades the listing with a new certificate. No contradiction; additional transparency is provided.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

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

Four sentences, no redundancy. Each sentence is essential: states purpose, describes the token, explains verification options, and notes the outcome. Structured for quick parsing.

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 tool with no output schema, the description explains the entire workflow, return value, and consequences. Lacks mention of error handling or rate limits, but still fairly 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% with a clear description for the 'url' parameter. The description mentions the token is bound to the endpoint but doesn't add further semantic details beyond the schema. Baseline 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 starts with 'Start claiming YOUR MCP server' which is a specific verb-resource pair. It clearly distinguishes from the sibling tool 'claim_confirm' by describing the initial step and prompting the next step.

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 states when to use (to start claiming) and provides detailed instructions on the two verification methods (serving token or DNS TXT record) and the follow-up call to claim_confirm. It also mentions it's free, setting 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?

Annotations already declare readOnlyHint=true, but the description adds value by emphasizing honesty ('no fabrication') and the 'LIVING GATE posture' that empty results reflect empty data. It details the return fields, going beyond annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

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

The description is concise and front-loaded, with every sentence providing essential information. No redundant or vague phrasing.

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 parameters and the read-only nature, the description fully explains the tool's purpose and outputs. Despite no output schema, it lists the key fields returned, making it 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?

There are zero parameters, so the schema provides no additional detail. Baseline for 0 params is 4, and the description does not need to add parameter information; it focuses on outputs instead.

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 provides an aggregate of agent requests via register_intent and passive logging, listing specific outputs like top need phrases, match percentages, total sessions, and time window. It differentiates itself from siblings like register_intent by describing its aggregation 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?

The description implies the tool is used to get a summary of agent demand, but it does not explicitly state when to use it over alternatives like audit_query or ecosystem_search. No exclusions or when-not-to-use 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?

Annotations already declare readOnlyHint and openWorldHint. The description adds value by noting the tool is 'FREE' and returns ranked matches with price, quality score, category, and URL, which are behavioral details beyond the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

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

The description is two sentences, front-loaded with the key feature 'FREE' and the action. It is highly concise with no unnecessary words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple search tool with one parameter and no output schema, the description covers the main aspects: what it searches, what it returns, and its utility. It could mention pagination or limits, but overall it is fairly 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 schema covers the single parameter 'query' with a description, and the tool's description does not add additional semantic information beyond what the schema provides. With 100% schema coverage, 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 searches the x402 agent-economy catalog for services relevant to a query and returns ranked matches with specific fields. It distinguishes itself from sibling tools like capability_landscape and recommend_mcp by focusing on live search across thousands of payable APIs.

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 indicates the tool is useful for discovering other agents/APIs to delegate to, which implies usage context. However, it does not explicitly state when not to use it or mention alternatives, though the sibling list provides many options.

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 key behavioral traits beyond annotations: it returns a ticket, the process is async with human review, no auto-sending, and credentials are redacted. This complements the annotations (readOnlyHint=false etc.) and adds significant value.

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 reasonably concise and front-loaded with purpose. Each sentence provides value, though the length could be slightly reduced. It's well-structured for an agent.

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 (5 params, no output schema), the description is comprehensive. It explains the full workflow, return type (ticket), related tools for follow-up, and security warnings. It covers all needed context for an agent to use 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 descriptions for all 5 parameters. The description adds meaning for 'ref' (linking to refer tool), 'need' (be specific with examples), and 'contact' (optional vs. default channel). This goes beyond the schema alone.

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: 'Commission SaSame to BUILD or OPERATE an AI system.' It explains what SaSame does (builds MCP servers, LLM integrations, etc.) and that the tool is for opening an engagement. It differentiates from sibling tools like check_engagement and reply_engagement by focusing on initial submission.

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 guidance: call this to open an engagement, describe the work, optionally provide contact info, and then use check_engagement and reply_engagement for follow-up. It also states that a human reviews every request and that it's free to submit. While it doesn't explicitly list when not to use it, the context makes it unambiguous.

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 beyond annotations: authorization structure, SaSame's non-custodial nature, terminality, double-release refusal. No contradiction with 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 moderately verbose with a typo ('SaSame' repeated). Front-loaded with purpose but includes extra behavioral notes that could be more succinct. Still 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?

Completes the picture for a tool with no output schema: explains output (signed authorization) and lifecycle constraints. Covers when to use, why, and what happens after. Very thorough.

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 descriptions exist for all params. The description adds context on the authorization content (escrow_id, outcome, amount, ts) though amount and ts are not explicit parameters. This adds 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 the action (sign authorization) and resource (open escrow). Differentiates from siblings like escrow_open and escrow_status by specifying the context of outcome reported/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?

Explicitly says when to use (once outcome reported/verified) and when not to (already settled). Provides alternatives: pair with audit_mcp for objective conditions, and explains behavior for subjective deliverables.

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 provides extensive behavioral details beyond annotations, including that SaSame holds no funds, uses an append-only ledger, signs envelopes, and that money movement depends on the settlement venue's configuration. No contradiction with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

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

The description is a single dense paragraph that front-loads the purpose. It is concise but could benefit from slightly more structure, though it remains highly informative 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 tool's complexity (7 parameters, no output schema), the description explains the mechanism well but does not explicitly state what is returned (e.g., the signed envelope record). This leaves a gap in completeness.

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 with descriptions. The description adds operational context (e.g., settlement_ref is where funds sit, condition is release condition) that helps understanding, going beyond the schema's 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 states it opens a non-custodial conditional-release escrow, specifying that SaSame holds no funds and moves no money. It distinguishes itself from siblings like escrow_attest and escrow_status by emphasizing its non-custodial 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 explains when this tool is appropriate: for conditional-release escrows where the settlement venue honors SaSame's signature. It does not explicitly mention when not to use or provide alternative sibling 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?

Annotations already declare readOnlyHint=true and openWorldHint=false. The description adds value beyond annotations by explaining that the returned statement is signed and offline-verifiable, and that each attestation carries its own signed authorization. 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, front-loaded with the main purpose. Every sentence adds meaningful information without waste. Highly concise 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 a single parameter, no output schema, and annotations covering read-only behavior, the description fully covers what the tool returns (terms, release condition, settlement, signed attestations) and the signed nature. No gaps remain for this use case.

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 100% schema coverage and only one parameter, the description adds context by specifying that escrow_id comes from escrow_open, which clarifies the prerequisite. This goes beyond the schema's minimal description.

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 reads an escrow's current state and enumerates what is included: terms, release condition, settlement, and signed attestations. It also specifies that the returned statement is ed25519-signed and offline-verifiable, distinguishing it from sibling tools like escrow_attest.

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 after escrow_open by referencing escrow_id from escrow_open, but it does not explicitly state when to use this tool versus alternatives like escrow_attest or escrow_open. No 'when not to use' 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?

Discloses read-only nature, that the badge is a re-checkable measurement not an endorsement, and that it changes with grade. Adds context beyond readOnlyHint annotation without contradiction.

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 detailed but each sentence serves a purpose. Some minor verbosity, but overall efficient and front-loaded with the primary 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?

Explains return format (markdown+HTML snippet, certificate URL) and behavior when server unobserved. No output schema, but description fully compensates.

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 100% of parameter descriptions. Description does not add new semantic meaning for the 'url' parameter 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 it gets an embeddable badge rendering the latest grade observed. It distinguishes from sibling tools like audit_mcp and claim_start by referencing them.

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 tells when to use (to get a badge), what to do if server isn't observed (run audit_mcp), and how to make listing owner-confirmed (claim_start). Also notes read-only and no signup.

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

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

Annotations show readOnlyHint=true, and the description confirms it's a read operation that returns snippets. It adds behavioral context by stating 'This is a status mark, not an endorsement,' which clarifies the nature of the output beyond what annotations provide.

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, immediately stating the tool's purpose and listing output types. No unnecessary words, 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 no output schema, the description compensates by listing the types of snippets returned. It also clarifies the semantic difference (status vs endorsement). For a simple read tool with 2 parameters, this is fairly 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 description coverage is 100% (both url and name have descriptions). The tool description does not add additional parameter-level details; it remains at a high level. Baseline 3 is appropriate as the schema already adequately describes the 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?

Description clearly states it returns copy/paste snippets for turning a SaSame observation into visible status marks. It lists specific snippet types (README badge, HTML badge, MCP instructions, etc.) and distinguishes itself as a status mark rather than an endorsement, setting it apart from siblings like get_badge.

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 obtaining status mark snippets but does not explicitly state when to use this tool versus alternatives like get_badge or verify_mcp_ready. No exclusion criteria or alternative suggestions are 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 provided, so the description must disclose behavioral traits, but it only mentions returning snippets. It does not clarify if the operation is read-only, what happens on failure, or any authentication 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 a single sentence with no wasted words, but it is too brief to convey meaningful information. It sacrifices clarity for brevity.

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, the presence of two unspecified parameters, and a sibling tool with a similar name ('get_mark_snippet'), the description is incomplete. It fails to specify return format, parameter details, or use case differentiation.

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 0% schema description coverage, the description must compensate but it does not explain the 'url' and 'name' parameters. Their purpose and format remain unclear, leaving the agent with insufficient 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?

The description states it returns snippets for a 'signed SaSame Record Mark,' but the term is domain-specific and not explained. It does not distinguish from the sibling tool 'get_mark_snippet,' which likely has 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?

No guidance on when to use this tool versus alternatives like 'get_mark_snippet.' The description provides no context on prerequisites or appropriate 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?

Annotations already declare readOnlyHint=true, so the description's claim of returning state is consistent. It adds contextual details about revenue rails but does not disclose additional behavioral traits such as rate limits or authentication 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 a single, focused paragraph that front-loads the purpose. It is concise and contains no redundant information, though it could be slightly streamlined.

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 no parameters and no output schema, the description adequately covers what the tool returns: the monetization state with details on free and paid components. It is sufficient for the tool's 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?

The input schema has zero parameters, so there is nothing to explain. The description does not need to add parameter information. Baseline score of 4 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 returns the current Gold-Rush-only monetization state, with specifics on free vs revenue-generating features. It is distinct from the sibling 'town_prices' which likely returns town-specific prices. However, it could be more explicit about the exact output format.

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 this tool is for checking monetization state, but does not explicitly state when to use it vs. alternatives like 'town_prices'. No exclusions or when-not-to-use 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?

Annotations declare readOnlyHint=true, and the description adds behavioral context: criteria are bound to spec/registry/crypto/measurement, ensuring reproducibility. It explains what the tool provides beyond the annotation, though it could mention if the output is static or versioned.

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 core purpose. Every sentence adds value, 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?

Given zero parameters and no output schema, the description fully covers what the tool returns and its nature. It explains the standard's scope, criteria, and openness, leaving no ambiguity.

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, so no param explanation is needed. The description adds meaning about the standard's content and guarantees, exceeding the baseline of 4 for no 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 'Agent-Tool Discoverability Standard (v0.1)' and explains its purpose: a falsifiable criteria set for MCP/agent servers. It differentiates from siblings by focusing on the standard itself, not audit or verification.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies use for reference ('Free and open forever') but does not explicitly state when to use this tool vs alternatives like audit_mcp or verify_mcp_ready. No when-not or alternative 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 provided, so description must disclose all behavioral traits. Mentions a side effect ('creating Observed mark if needed') but lacks details on conditions, permissions, or idempotency. Fails to fully compensate for missing 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?

Single sentence, but contains a typo and is unclear. Acceptably concise but could be better structured to front-load key info.

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, no annotations, and a side effect are not explained. Description lacks details on return format, error conditions, and creation triggers. Incomplete for a tool with side effects.

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%, yet description provides no information about the parameters ('url', 'name'). The description adds no value beyond what the raw 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?

Description states verb 'return' and resource 'badge URLs/embed code', but uses unclear term 'SaSame Record Mark' (possible typo). Does not clearly distinguish from sibling tools like 'get_badge' or 'get_mark_snippet'.

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. The description implies a side effect (creating Observed mark) but does not specify prerequisites or 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?

Annotations already declare readOnlyHint=true. The description adds that hints are 'broad' and specifies the paid/private dichotomy, but no further behavioral traits are disclosed.

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-load the purpose 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 read-only tool with no parameters and no output schema, the description provides sufficient context about the data scope, though it could hint at the return 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?

No parameters exist, schema coverage is 100%. The description adds context about the result content, 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 'broad public Gold Vein hints' and contrasts with 'specific build opportunities' that are paid/private, using a specific verb and resource.

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 public hints by contrasting with paid/private opportunities, providing context but no explicit when-to-use or alternatives.

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

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

Annotations indicate readOnlyHint=true; description confirms read-only operation. Adds details about content_verified filtering and 'ghost' agents, providing transparency beyond annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

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

Three sentences covering purpose, output, and usage. Slightly wordy but front-loaded and efficient. Could be trimmed but still good.

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?

Explains what is returned (roster with verification status, recent posts), and how to use. No output schema, but description compensates. Adequate for a feed 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?

No parameters in schema. Description adds no parameter info, but none needed. Baseline 4 as per guidelines for 0 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?

Clearly states the tool reads an agent activity feed, lists subresources (participant roster, recent posts), and differentiates from sibling tool join_guild. Verb 'Read' with specific resource.

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?

States use case: discover other agents and latest activity. Provides alternative (join_guild) for appearing. Lacks explicit when-not-to-use, but 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 human moderation, content verification via SaSame Audit, identity self-claimed, and labeling. Adds significant behavior beyond annotations (idempotentHint=true, destructiveHint=false). No contradiction.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

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

Four sentences with clear flow: purpose, process, outcome, value. Front-loaded and no unnecessary words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Explains the full lifecycle from submission to publication with verification status, but lacks detail on immediate return value (e.g., success indicator, post ID). Adequate for a simple submission 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 covers 100% of parameters. Description adds value by contextualizing the URL parameter as checked by Audit, and content as a short note, but does not introduce new parameter semantics 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 the tool joins the Gold Rush Guild to broadcast an agent/service, differentiating it from siblings like `guild_feed` which likely views the feed. It is specific and action-oriented.

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 low-threshold discoverability for new agents but lacks explicit when-to-use or when-not-to-use guidance vs. alternatives. No mention of alternative tools or constraints.

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

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

Annotations already provide readOnlyHint and openWorldHint. The description adds the clarifying context that the record is a measurement record, not a security audit, which informs the agent about the nature of the data beyond the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

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

Two sentences, no unnecessary words. The first sentence front-loads the core purpose, and the second sentence adds a clarifying note. Excellent structure.

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 does not describe return values or behavior when parameters are omitted or conflicting. The tool is simple, but the description could still be more complete by specifying that at least one parameter is expected.

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 0% description coverage. The description mentions 'MCP URL or mcp_id' implying these are alternative identifiers, but does not define their format or constraints, leaving ambiguity. The description adds minimal 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 clearly states the verb 'look up' and the resource 'public Gold Rush Passport', differentiating it from sibling lookup tools like lookup_readiness by specifying it's a measurement record, not a security audit.

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 hints at when not to use it (for security audits) by stating 'not a security audit', but does not explicitly name alternatives. This provides some context for usage decisions.

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

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

Annotations already indicate readOnlyHint=true. The description adds valuable behavioral context: no live probe, instant result, offline verification of returned attestation, and that status is not an endorsement. 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 front-loaded with the main purpose and includes necessary detail. It could be slightly more concise by removing minor redundancies (e.g., 'a neutral third party's measured record...'), but overall it's well-structured and not overly verbose.

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 what the tool returns (freshly signed attestation, offline verifiable) and how to handle missing records. It covers purpose, behavior, alternatives, and limitations (not a trust verdict). Complete for a read-only lookup 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?

The input schema has 100% description coverage for the one parameter 'url'. The description does not add additional meaning beyond what the schema already provides, so baseline score of 3 applies.

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 looks up SaSame's existing, independently signed readiness attestation for an MCP/agent endpoint. It distinguishes itself from siblings like audit_mcp (for adding if not found) and readiness_report, and clarifies it's a pure read operation.

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 provides an alternative (call audit_mcp if record not found) and sets expectations: pure read, no live probe, no network. While it doesn't list all when-not-to-use scenarios, the alternative and context are sufficient for correct selection.

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

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

Annotations already include readOnlyHint=true, so the description's 'Public-safe latest status' aligns. The additional note 'not an endorsement' adds behavioral context. However, it does not cover edge cases or auth requirements beyond 'public-safe'.

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 redundant information. Every word 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?

No output schema, so the description should describe the return value. It only mentions 'latest status' and 'not an endorsement', but lacks details on response structure or error handling. Given the tool's simplicity, it partially satisfies but leaves gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%. The description clarifies that either url or mcp_id can be used, but lacks format constraints, examples, or which is preferred. It adds some meaning over the schema but does not fully compensate for missing parameter 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 states the verb 'look up' and the resource 'public SaSame MCP Registry entry'. It specifies the input types 'MCP URL or mcp_id', which distinguishes it from sibling lookup tools like lookup_passport and lookup_readiness.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description mentions 'Public-safe latest status only; not an endorsement' but provides no explicit guidance on when to use this tool versus alternatives or when not to use it. No comparison or context for tool selection among 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?

Annotations already declare readOnlyHint=true, so the safety profile is clear. The description adds behavioral context by specifying 'Aggregate measurement context only' and 'not a recommendation', which helps set expectations about the data's nature and limitations. 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 extremely concise (two sentences) and front-loaded with the core purpose. Every clause earns its place: the first sentence states the action and resource, the second clarifies scope and disclaimer. No unnecessary words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given there is no output schema, the description could provide more detail about what 'aggregate measurement context' includes (e.g., fields, data types, or examples). While the tool is simple, the description is vague about the return value, leaving uncertainty 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?

There are zero parameters, so the baseline is 4. The description does not need to add parameter details. It does not include any redundant parameter information. The schema coverage is 100%, so no compensation 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 tool returns public aggregate MCP Market Context, with a specific verb ('Return') and resource. It distinguishes from siblings by being a public, aggregate read, and the title from annotations reinforces this. 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?

The description provides no explicit guidance on when to use this tool versus alternatives. It only adds a negative note ('not a recommendation'), but lacks context such as when other related tools (e.g., analytics_public_summary) would be more appropriate. Adequate for a simple read tool but lacks proactive direction.

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 goes beyond annotations by explaining that charges exceeding remaining budget are rejected with a signed denial, and that the tool returns remaining + a signed line-item. This adds significant behavioral context that annotations (readOnlyHint=false, destructiveHint=false) alone do not convey.

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 with no wasted words. Each sentence adds value: the first states the core action, the second explains the rejection behavior, and the third provides rationale and return value. 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?

Despite no output schema, the description specifies return values (remaining + signed line-item) and explains the denial mechanism. It covers the essential behavior for a charge tool, though it could mention error handling or prerequisites.

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% description coverage, so the schema already explains each parameter. The description adds no additional parameter-level information beyond what is in the schema, resulting in 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 records a charge against a meter and enforces a cap. It uses a specific verb ('Record') and resource ('charge against a meter'), and distinguishes itself from siblings by emphasizing budget enforcement in code.

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 that the tool enforces the cap in code because an autonomous agent cannot trust itself to do so. This provides clear guidance on when to use it (when cap enforcement is critical), though it does not explicitly state when not to use it or mention 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?

Discloses behavioral traits beyond annotations: it creates a signed receipt, is offline-verifiable, and returns meter_id and signed receipt. No contradiction with 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?

Two sentences, front-loaded purpose, no wasted words. Each 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 4 parameters and no output schema, the description adequately explains return values and security aspects, making it complete for agent invocation.

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, so the description adds minimal extra meaning to parameters, though it does provide context about the budget cap and return values.

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 'usage/budget meter', and explains its unique context of SaSame's append-only ledger, distinguishing it from siblings like meter_charge 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 says 'Use when' a principal wants to give a sub-agent a capped budget, and clarifies what the tool does not do (holds no funds, not a payment processor), guiding appropriate usage.

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

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

Annotations already declare readOnlyHint=true, and the description adds value by explaining the signed statement, offline verifiability with trust_pubkey, and that line items are not separately signed. 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. The description is front-loaded with the core purpose and then provides critical details about signing and verification.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple read tool with one parameter and no output schema, the description covers the returned structure (statement summary and line items) and signing behavior. It is sufficient for an agent to understand what the tool returns.

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 sole parameter meter_id is described in the schema as 'The meter_id from meter_open', which is clear. The description does not add further semantic detail beyond the schema, but schema coverage is 100%, meeting the baseline of 3.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool reads a meter's current state including budget, spent, remaining, and line-item history. It distinguishes itself from sibling tools like meter_charge and meter_open by focusing on read-only 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?

Usage is implied as a read operation, but no explicit guidance on when to use this tool versus alternatives like meter_open or other read tools is provided. No exclusions are 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?

The description adds behavioral context beyond annotations: it clarifies that the returned data are candidates (not definitive), are measurement records only, and carry no SLA or endorsement. This is valuable despite annotations already indicating read-only.

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 totaling 14 words, with the main action front-loaded. Every word adds value, and there is no redundancy or filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (no parameters, no output schema), the description covers essential aspects: what it returns, the scope (public), and limitations (measurement only, no SLA). However, it could specify the return format or structure for greater completeness.

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 compensates by explaining the nature of the tool's output—public measurement receipt candidates. It adds meaning 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 verb 'Return' and the specific resource 'public monitoring receipt candidates'. It also distinguishes from siblings like 'receipt_issue' and 'receipt_state' by emphasizing 'measurement records only, no SLA or endorsement', indicating a different purpose.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides context that this tool returns measurement records without SLA/endorsement, implying it's for non-critical public data. However, it does not explicitly state when to prefer it over alternatives or when not to use it.

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?

Description adds return specifics (text preview + confidence) and limitation (truncated in free) beyond annotations. No contradictions.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

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

Two concise sentences with front-loaded key info ('FREE') and zero 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?

Complete coverage for a simple tool: purpose, output description, limitation, and pricing comparison. No additional context needed.

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 description adds no new info beyond schema's parameter description.

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 'extract text from an image URL' with specific verbs and resource. Distinguishes free version from paid full extraction 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?

Explicitly indicates free vs paid usage, implying when to use each. No direct guidance on when not to use, but 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?

The description discloses key behaviors beyond annotations: returns per-RPC value, block pinned, consensus verdict, max deviation bps, and detects lag/stale answers. This adds significant context that readOnlyHint and openWorldHint annotations do not cover.

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, front-loads the core concept, and every sentence adds value. No fluff or redundant 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 read tool with no output schema, the description adequately explains the return structure (per-RPC value, block, consensus verdict, deviation). It also clarifies the tool's advantage over separate RPC calls. Given the complexity and lack of output schema, it is sufficiently complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so baseline is 3. The description adds context by explaining the overall reconciliation process and the nature of the 'op' values, but does not elaborate much on individual parameters beyond what schema provides. The added context raises it to 4.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool performs a multi-chain onchain read reconciled across 2-3 RPC providers, lists specific operations (block_number, gas_price, etc.), and explains it collapses several eth_* functions into one primitive. This provides a specific verb and resource with clear distinction from separate RPC calls.

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 this tool (for reconciled multi-provider reads) and mentions that a lone RPC can lag or return stale answers, implying it's useful for reliability. However, it does not explicitly state when not to use it or compare to sibling tools, which are many.

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

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

Annotations already set readOnlyHint=true. Description confirms read-only and adds output content details but no additional behavioral traits (e.g., rate limits). No contradiction.

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. First sentence states purpose, second clarifies safety. Front-loaded and no extraneous text.

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; description gives high-level return info but lacks specifics on pricing overview structure. Adequate for a simple tool but could detail the overview content.

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 no parameters and coverage is 100%. With zero parameters, baseline is 3. Description does not need to add parameter info.

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 pricing overview and checkout link existence per plan. Verb 'Return' specifies action. However, does not explicitly differentiate from sibling 'get_pricing'.

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 safe read-only usage but lacks explicit guidance on when to use vs alternatives like 'get_pricing' or when not to 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?

Beyond annotations (readOnlyHint, openWorldHint), the description reveals that the tool is gated (requires intent_token) and that abstract full text is not returned inline. It also notes the response format is structured JSON without free-text upsell.

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 that front-loads the purpose and efficiently conveys key details, though it could be slightly more concise. 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 adequately explains the return format (fields per paper) and important caveats (no abstract, gated). It covers the essential context for an agent to use the tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%; the description adds minimal additional meaning beyond the schema descriptions (e.g., default for n, topic description). No new semantic constraints or usage tips are provided.

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 'PubMed citation retrieval' and details what is returned (PMID list, per-paper fields). However, it does not explicitly distinguish from the sibling tool 'pubmed_lookup', which may also retrieve PubMed data.

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 implicitly indicates the tool is for citation metadata retrieval, noting that abstract full text is not returned. It does not provide explicit when-to-use or when-not-to-use guidance nor name 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?

Annotations already indicate readOnlyHint and openWorldHint. The description adds specific behavioral context: it returns titles, PMIDs, journals, and is only a preview. This goes beyond annotations by specifying the limited output scope.

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 very concise: two sentences front-loading the key point 'FREE preview' and listing return values. Every sentence adds value with no 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 tool's simplicity (one parameter, no output schema), the description explains what is returned (titles, PMIDs, journals) and the free preview limitation. It lacks details on result count or pagination but is sufficient for a read-only search preview.

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% for the single 'topic' parameter, which already has a clear description. The tool description does not add extra meaning or constraints to the parameter, meeting the baseline but not exceeding it.

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's a free preview of a real PubMed search, returning top article titles, PMIDs, and journals. It distinguishes from a paid tier but does not explicitly differentiate from the sibling tool 'pubmed_evidence', which may have similar functionality.

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 use for free previews and mentions 'no paid research tier is active', suggesting a free alternative. However, it lacks explicit guidance on when to use this tool versus alternatives like 'pubmed_evidence', leaving some ambiguity.

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

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

Annotations already indicate readOnlyHint=true, so the description builds on that by explaining the cost-zero nature, monetization context, and that legal/account requirements are out of scope. This adds meaningful behavioral context beyond the structured data.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

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

The description is slightly lengthy but front-loads the core purpose and lists key features efficiently. Every sentence adds value, though some details (e.g., monetization context) could be trimmed without losing clarity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the lack of output schema and simple parameter structure, the description adequately covers what the tool returns, usage constraints, and behavioral context. It does not describe return format but lists report components, which is sufficient for this 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?

With 100% schema description coverage for the single parameter, the description adds no new meaning beyond the schema's own description of the URL field. Baseline of 3 is appropriate since schema already fully documents the parameter.

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 generates a full MCP readiness report for one server, listing specific deliverables: audit results, evidence, remediation, signed certificate, and next step. It explicitly distinguishes itself from audit_mcp by noting it runs the same audit but returns more comprehensive output.

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 using it as a directory pre-flight and recommends running against your own server. It also scopes out legal/account requirements and clarifies no auth-bypass or payment is needed. However, it does not explicitly compare to siblings like audit_mcp or lookup_readiness to guide tool selection.

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 adds significant behavioral context beyond annotations, explaining the signing process, that SaSame does not independently witness, and that the receipt is offline-verifiable. No contradiction with annotations (readOnlyHint=false is consistent with a write operation).

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 (4-5 sentences) and front-loaded with the main purpose. Every sentence adds value: purpose, details, note, usage examples. No 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 description is fairly complete given no output schema. It explains the receipt structure (signed_by, signature, canonical_json) and the tool's role in audit trails. Minor gaps: no mention of error conditions or parameter validation details.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with clear descriptions for all three parameters. The description adds minimal additional meaning beyond the schema, e.g., emphasizing that 'action' is what happened. 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: 'Get an ed25519 receipt for an action/tool-call you (or a peer) report.' The verb 'get' and resource 'receipt' are specific, and the context of reporting an action distinguishes it from sibling tools like audit_mcp or trust_pubkey.

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 usage context: 'Use for audit trails, dispute evidence, and recording that a step was reported.' It also notes limitations: 'SaSame signs what is reported; it does not independently witness that the action occurred.' However, it does not explicitly compare with sibling tools or specify when not to 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?

Annotations already declare readOnlyHint=true. Description adds significant behavioral context: returns SaSame-signed offline-verifiable statement, error on unknown IDs, empty flags never fabricated. No contradiction.

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 front-loaded with key purpose and detailed outputs, but could be slightly more concise. 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, description comprehensively lists all returned fields (folded status, risk_flags, display_strength, correction chain, audit trail) and handles edge cases (unknown IDs, empty flags). Fully adequate for a read 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% with a minimal description of receipt_id as 'rcp_* or atr_* id'. The tool description echoes that format but adds no new semantic depth 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?

Description uses specific verb 'Read' and resource 'lifecycle state of a receipt', listing concrete fields (folded status, risk_flags, etc.). Clearly distinguishes from sibling write tools like receipt_issue and receipt_status_set.

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 for reading receipt state but does not explicitly state when to use vs alternatives, nor provide exclusions. Usage context is clear but guidance is minimal.

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 goes beyond annotations by explaining the event-sourced design (appends new status, never mutates original), terminal state behavior, and honesty boundary (SaSame signs but does not adjudicate). This adds critical context that annotations (readOnlyHint=false, destructiveHint=false) alone do not convey.

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 dense sentences with no wasted words. Each sentence adds essential information: what it does, how it works (event-sourced), and constraints (terminal, honesty boundary). Models can quickly grasp the tool's behavior.

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 (6 params, no output schema), the description covers the core behavior, constraints, and lifecycle implications. It lacks explicit mention of return values or error conditions, but the event-sourced and terminal details provide sufficient context for correct invocation.

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 83%, and the description adds meaningful usage details: 'corrected_by' is the replacement receipt ID for corrected/superseded, and 'dispute_reason' is for disputed status. These clarifications enhance understanding beyond the schema's parameter 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 states the tool records a lifecycle status against an issued receipt, specifying the exact statuses (revoked, disputed, corrected, superseded) and the receipt ID format (rcp_* or atr_*). This distinguishes it from siblings like receipt_issue (which issues receipts) and receipt_state (likely queries state).

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 usage context: when to record statuses, terminal behavior after revoked/superseded, and the requirement for corrected_by when status is 'corrected'. It does not explicitly state when not to use or compare to alternatives, but the specificity is strong enough for correct invocation.

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

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

Annotations already declare readOnlyHint=true, so the description adds value by disclosing that results include longitudinal trend, signed record, and cite line. It also states 'Free, read-only, no signup' and explains grading criteria, exceeding the annotation baseline.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

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

The description is well-structured, starting with the main action and then adding details, usage tips, and alternatives. It is slightly long but each sentence adds value. Front-loaded with the core 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 the tool's complexity (3 optional params, no output schema), the description fully explains what is returned (endpoints, grades, longitudinal trend, signed record) and covers edge cases (fallback to engage_sasame, claiming servers). 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 each parameter is described. The description adds extra context: defaults for 'limit' (5) and 'min_grade' (B), and explains how 'need' matches against endpoint/host. This goes beyond the schema, earning a 4.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'Get SaSame-observed MCP server recommendations for a capability you need.' It explains the grading system and what is returned, and distinguishes from siblings like engage_sasame and claim_start.

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 tells when to use alternatives: 'If you operate one of these servers, claim it (claim_start). If you can't find a fit and need an MCP/agent BUILT, call engage_sasame.' It also provides context on when not to use (if need building) and mentions free/read-only nature.

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

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

Annotations only show readOnlyHint=false and destructiveHint=false. The description adds that the handle is 'PII-free', 'records provenance only', and 'no referral cash payout or paid checkout link is active'. This contextualizes the non-destructive, non-readonly nature beyond annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

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

The description is two sentences long, front-loaded with the core purpose, and every 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?

Given low complexity, full schema coverage, and no output schema, the description sufficiently covers purpose, parameter semantics, and constraints. It is complete for the tool's scope.

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 meaningful context for 'referrer' (your directory/agent/MCP name or domain) and 'note' (who/what you're referring, or contact for credit), going beyond the 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 states the action 'Register an attribution handle for introductions to SaSame.' with a specific verb and resource. It is well-distinguished from the long sibling list, which includes many unrelated tools like audit, escrow, trust, etc.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit context about when not to use (no secrets/keys, no payout under Gold-Rush model) but does not directly compare to alternatives or state when to use over siblings. The guidance is clear enough, though could be improved with explicit sibling 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?

The description adds behavioral details beyond annotations: 'cost-zero, no LLM in the path, deterministic', and explains the return types. Annotations are minimal (e.g., destructiveHint=false) and description does not contradict them.

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 and front-loaded, with key information in the first sentence. It is well-structured but could be slightly more compact without losing clarity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description explains the three return items clearly. It also notes the nearest_to parameter. However, it could clarify how the intent token is used in intent-gated tools.

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 mentions the 'one-field' nature and that aliases are accepted, but adds little beyond the schema documentation.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: a survey wall for expressing what the user is trying to do. It lists three specific return items and distinguishes the tool from siblings like demand_radar.

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 registering intent when no matching tool is found, referencing intent-gated tools and nearest live tool. However, it lacks explicit guidance on when not to use this tool or how it compares to alternatives like ecosystem_search.

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

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

Annotations indicate the tool is not read-only nor destructive. The description adds that credentials are redacted before storage and that the tool is free and deterministic. This provides behavioral context beyond annotations, such as the direct delivery mechanism and security behavior.

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 several sentences but each adds value: purpose, delivery mechanism, required parameters, and security note. It is front-loaded with the core action and avoids unnecessary fluff. Slightly verbose for a simple tool, but 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?

No output schema is provided, so the description could include return value or error handling, but for a simple 2-parameter tool the current details are sufficient. It covers what the tool does, how it behaves, and important constraints, making it reasonably 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%, so the schema already documents both parameters adequately. The description repeats the parameter names and adds the security warning about secrets, but does not provide additional meaning beyond what the schema offers. 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 adds a follow-up message to an existing engagement ticket opened with engage_sasame. It specifies the action (reply), resource (engagement ticket), and context (operator's inbox). This distinguishes it from siblings like engage_sasame (which opens tickets) and check_engagement (which views them).

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 that messages go directly to the operator's inbox on SaSame's system (no email) and warns against pasting secrets. It names the required parameters (ticket and message). While it doesn't explicitly state when not to use alternative tools, the context of sibling names implies this is the only reply 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?

Beyond the readOnlyHint and openWorldHint annotations, the description details behavioral traits: injection-quarantine, structured output with fields (claims, source_index, coverage), corroboration counting, freshness handling, and absence of contradiction detection. It also clarifies zero-upsell in LLM fields. No contradictions with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

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

The description is compact yet informative, front-loading the core concept and important details. It uses a clear structure with bullet-like enumeration of claim attributes. Minor improvement possible with more explicit formatting, but overall 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 five parameters, no output schema, and two annotations, the description adequately explains the tool's output (structured claims with corroboration, sources, freshness) and key behaviors (gated access, source restriction). Missing explicit output schema is compensated by detailed textual description. Almost complete for an information 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 description adds limited new meaning beyond what parameter descriptions already provide. It reinforces the purpose but does not significantly enrich parameter semantics; 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 defines the tool as an injection-quarantined evidence graph that returns structured claims with corroboration details, distinct from general web search and other tools. It specifies the structured output format and source set, making the purpose unambiguous.

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 research queries requiring structured evidence, but does not explicitly state when to avoid this tool or suggest alternatives among the many sibling tools. It provides some context (e.g., does not detect contradictions) but lacks explicit when-to-use and when-not-to-use guidance.

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

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

Annotations already declare readOnlyHint=true, and the description reinforces 'read-only manifest'. It adds behavioral context by stating it 'returns the shortest path' for various actions, which is useful beyond the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

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

The description is extremely concise: one sentence with a bold 'START HERE' header, followed by a brief explanation. Every word adds value, and the key purpose is front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a zero-argument read-only tool, the description fully covers what it does and what to expect as output (the shortest path for various items). No output schema exists, but the description compensates adequately.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has no parameters, and the description correctly matches that. No additional parameter description is needed, as the tool takes no arguments.

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 explicitly states 'START HERE' and 'read-only manifest', clearly indicating the tool's purpose as an entry point that returns an overview. It distinguishes from sibling tools by positioning itself as the first call, not a specific operation.

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 uses 'START HERE' to signal the intended first use and notes 'Measurement only — not endorsement, not malware scan' to set expectations. It doesn't explicitly list when not to use alternatives, but the zero-argument nature and entry-point role make 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?

The description discloses that the tool is a read operation despite readOnlyHint=false, mentions it is free, and explains the return of a signed trajectory. It also clarifies the optional contact is not auto-contacted, adding safety context beyond annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

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

The description is concise and front-loaded with the key action and result. It is slightly dense but without wasted words. A bit more structure 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?

Given no output schema, the description fully explains the return value (current grade, trend, signed trajectory). It covers purpose, behavior, parameters, and output, making it complete for a subscription 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?

The description adds meaning to all three parameters: target (MCP endpoint), contact (optional return channel, never auto-contacted), and note (why watching). Schema coverage is 100%, but the description provides essential context for usage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action: subscribing to grade changes for an MCP endpoint, and distinguishes it from a one-shot lookup using 'lookup_readiness'. It specifies the unique output (signed trajectory) and the value of ongoing monitoring.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies when to use it (for ongoing monitoring vs. one-time check) and clarifies that no auto-contact happens. However, it does not explicitly name alternatives or provide exclusions.

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

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

Annotations include idempotentHint: true and destructiveHint: false. The description adds that quotes remain separate and unsettled until verified, which provides some behavioral context, but does not fully clarify if calling this triggers any side effects beyond returning an offer.

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; the first is a confusing conditional that may not be necessary. Could be more concise and front-loaded with the core action.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema and no parameters, the description should clearly explain the tool's role. It fails to clarify how becoming a citizen works, what the offer entails, or how it integrates with sibling tools like 'town_buy_plot'.

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 are defined, so schema coverage is 100%. The description mentions return values (hosting offer with prices), which adds value beyond the empty schema. Baseline 4 applies.

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 is vague and confusing. It starts with a conditional 'No MCP server yet?' and mentions hosting, but the tool name implies becoming a citizen. The purpose of retrieving a checkout offer is not clearly stated.

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 or when not to use this tool versus alternatives like 'town_claim_confirm' or 'town_buy_plot'. The description lacks 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?

Description adds value beyond annotations: it mentions content moderation, no charge, and recording of unsettled quotes. This provides behavioral context that complements the readOnlyHint=false annotation. No contradiction.

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, no fluff. Every sentence serves a purpose: stating the action, listing parameters, and providing cost/moderation context.

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 9 parameters, no output schema, and moderate annotations, the description covers core aspects: purpose, prerequisites, side effects, and references. Could be slightly more explicit about error handling or moderation outcomes.

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 tool description lists parameters but adds no new semantic information beyond what is already in the 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 states the tool customizes a claimed building's look and interior, using specific verbs and resources. It distinguishes from siblings like town_buy_plot or town_place_decor by focusing on existing buildings.

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: requires town_key, mentions moderation, and notes no charge. It implies use after claiming but does not explicitly state when not to use or list 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 offering behavioral cues beyond readOnlyHint and destructiveHint=false, the description adds significant value by disclosing that the operation is non-custodial, returns exact transfer instructions, and that the plot location does not move until both transfers verify. This goes beyond the annotations but could still detail failure modes or idempotency.

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 that are front-loaded and efficient. Every sentence adds essential information without wasted words. The structure is clear and easy to parse.

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, the description covers the return value (two transfer instructions) and the two-step verification process. It also mentions prerequisites. However, it omits details like pricing, expiration, or cancellation, which would make it complete for a buy order tool. Still, within the ecosystem of sibling tools, it is adequate.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3. The description adds context by explaining mcp_url as the buyer's claimed building URL, town_key as secret, and listing_id as the id from town_market. This clarifies meaning beyond the schema descriptions, earning a 4.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool creates a non-custodial order to buy a plot, specifying it returns two transfer instructions and that the plot location does not move until both transfers verify. This distinguishes it from sibling tools like town_list_plot or town_market, which serve different purposes.

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 when buying a plot and lists prerequisites (town_key and earning profile), but does not explicitly state when to use this tool versus alternatives or provide exclusions. The guidance is scattered and not fully explicit.

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

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

Annotations already provide idempotentHint=true and destructiveHint=false. The description adds context beyond annotations: explains that cancellation frees the building and that mid-settlement listings are not cancellable. No contradiction with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

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

The description is two sentences plus a short note. Every sentence serves a purpose: purpose, effect, requirement, and exception. No 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 is simple (cancel a listing). The description covers prerequisites (town_key, mcp_url), the effect (free building), and a limitation (mid-settlement). No output schema, so return values are not expected. Missing details about success/failure messages, but still adequate.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, baseline is 3. The description adds meaningful context: 'A listing already mid-settlement can't be cancelled' applies to the listing_id parameter, and 'Requires town_key' reinforces the required parameter. This adds value beyond the schema's 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 states the tool's purpose: 'Cancel (un-list) YOUR active plot listing in the town exchange.' It uses a specific verb and resource, and differentiates from siblings like town_list_plot by focusing on cancellation.

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 explicit context: 'A listed plot LOCKS your building from moving — cancel it to free your building again.' It also mentions a constraint: 'A listing already mid-settlement can't be cancelled.' However, it does not explicitly compare with alternatives like town_list_plot, so not a perfect 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?

The annotation idempotentHint=true contradicts the description stating 'reveals town_key exactly once,' implying the operation is not idempotent. No other behavioral traits are disclosed beyond what annotations provide.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

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

The description is well-structured and front-loaded with the purpose. It is slightly verbose but every sentence adds necessary context for a multi-step process.

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 complexity of the claim process and no output schema, the description sufficiently explains the flow, secrecy requirements, and setup block handling. It is complete 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?

All three parameters are documented in the schema (100% coverage). The description adds context about the origin being the same as town_claim_start and the private nature of claim_secret, adding value beyond schema descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it is Step 2 of claiming a building, specifies the action (submitting origin, claim_id, claim_secret to get town_key), and distinguishes it from sibling tools like town_claim_start and claim_confirm.

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 indicates it is the second step after town_claim_start, lists required inputs, and provides post-response instructions. However, it does not explicitly mention when not to use it 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?

The description discloses that the claim secret is private, expires in 15 minutes, and that claiming is free. It adds behavioral context beyond the annotations, though it does not clarify idempotency (annotations say idempotentHint=true, which is not addressed).

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 wasted words. Efficient and to the point.

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 key return values, expiration, and privacy. Even without an output schema, it provides sufficient context for a simple step-1 tool. However, it could mention the subsequent step (town_claim_confirm) more explicitly.

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, mcp_url, is fully described in the schema with sufficient clarity. The description adds no additional semantic beyond what the schema already provides.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Step 1 of claiming your building' and explains what it returns (claim_id, public token, private claim_secret). It provides specific verb and resource but does not explicitly distinguish from sibling tools like 'claim_start' or 'town_claim_confirm'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives context that it's step 1 and provides warnings about not publishing the secret and expiration, but it does not specify when to use this tool over alternatives or when not to use it.

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?

Beyond annotations (idempotent, non-destructive), the description adds that verified legs cannot be cancelled or reversed, which is important behavioral context. It also describes the verification scope (USDC contract, recipient, amount, buyer wallet, replay protection). However, it does not disclose potential side effects or require explicit permissions.

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, consisting of two sentences. The first sentence states the primary action, and the second adds verification detail. However, the typo 'SaSame' reduces clarity slightly.

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 lacks explanation of return behavior, error conditions, or prerequisites (e.g., existing order). With no output schema and complex context (payment confirmation), these gaps make the tool less 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?

With 0% schema description coverage, the description must explain parameters. It mentions 'one or both' transaction hashes, which likely map to fee_tx and seller_tx, but it does not identify them by name or explain mcp_url, order_id, or town_key. This leaves significant ambiguity.

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 submits one or both Base transaction hashes for an order and that SaSame verifies details. However, it does not explicitly differentiate from sibling tools like town_order_action or town_create_order, which could also handle order-related on-chain 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 provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites (e.g., an order must exist) or when not to use it.

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

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

Annotations only indicate non-read-only and non-destructive. Description adds that transfers are irreversible and not atomic, and fulfilment stays locked until both verify, which is important behavioral disclosure beyond annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

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

Two sentences, front-loaded with purpose, then critical caveats. 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?

Given four required parameters and no output schema, the description provides some context about the return (provider and fee info) but misses explaining other parameters and the full output structure. Moderately complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.