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

With no annotations, the description carries the full disclosure burden. It reveals the cost model (FREE, prepaid writes budget), the auth requirement (owner or editor/write-token only), and the destructive semantics of overwrite=true (replace in full on overwrite-shaped batons). It stops short of describing edge cases or errors, but the key behavioral traits are covered.

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 terse sentences plus an illustrative example. The core distinction (append vs overwrite) is front-loaded, and every sentence earns its place 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?

For a 6-parameter write tool with no output schema and no annotations, the description covers the main invocation modes, permissions, cost, and content format. But it does not address version_id usage, contentType, overwrite defaults, or what happens when the overwrite flag does not match the baton's preset shape, leaving meaningful gaps for an agent to infer.

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 only 33%, so the description must compensate. It adds meaning for content (text or base64), overwrite (replace in full), and id via the example. However, it leaves contentType unexplained, does not state overwrite's default, and ignores the 'binary' contentEncoding option in the enum, making the compensation only partial.

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

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

The description opens with a specific verb and resource ('Write to a baton') and immediately distinguishes two behaviors: append for append/append-chained presets and overwrite for single-object/checkpoint presets. This makes the operation unambiguous and clearly different from sibling tools like read_baton or create_baton.

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

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

It gives explicit conditions for when each mode applies based on preset shape, and states the required permission level. It does not name sibling tools or say when not to use this tool, but the provided context is sufficient to pick the correct mode for a write operation.

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 present, the description carries the full burden and does so thoroughly: it discloses blocking behavior, typical latency ranges, cost and free-tier limits, immediate fallback behavior when the bridge is disabled, and the fact that replies return to the agent in the conversation.

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 longer than typical but every sentence adds a distinct operational detail: how to trigger, when to use, latency, cost, fallback, alternatives, and an example. Information is front-loaded with the core action and selection criteria.

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 three parameters, no annotations, and no output schema, the description covers nearly everything an agent needs to invoke correctly: input format, blocking semantics, timeout-adjacent latency expectations, fallback behavior, alternatives, and example usage. No critical operational context is missing.

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

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

Schema description coverage is 0%, so the description should compensate. It does clarify message via an example and attached_baton_id as a way to save long content, but max_wait_seconds is never explained even though it directly relates to blocking/wait behavior. This leaves a meaningful gap for one of the three 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 opens with a specific verb and resource: 'Send a question to the human operator via their Telegram and wait for their reply.' It clearly differentiates itself from sibling tools by contrasting ASK (blocking) with notify_operator (one-way) and referencing ask_operator_email as a long-message alternative.

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: 'when you need a decision, approval, or clarification you can't infer from the conversation.' It also gives concrete alternative routes for long messages, operator-disabled bridge fallback, and one-way notification usage, leaving little ambiguity for an agent.

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

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

With no annotations provided, the description carries the full behavioral burden. It discloses read-only semantics, zero cost, required credentials (rs_live_* key or wallet-JWT/MCP token), and account-level scoping. The 'post-hold' credit detail also adds useful behavioral nuance about how holds affect available balance.

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 one dense, front-loaded sentence covering purpose, cost, auth, and scope, followed by a minimal example. There is no filler, repetition, or redundant restating of schema fields.

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 adequately covers what the agent will get back (balance, available post-hold credit, account profile), how to authenticate, and how to invoke it. It does not describe the exact response structure, but no output schema exists and the prose-level return summary is sufficient for this simple 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 zero parameters and 100% schema coverage, so there are no parameter meanings to document. The example 'balance {}' usefully reinforces that the tool takes no arguments. No further parameter semantics are needed.

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

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

The description clearly states the resource: current Relaystation balance, available post-hold credit, and account profile. It makes the operation type explicit with 'Read-only' and distinguishes itself from siblings like read_baton, create_baton, and mint_token by focusing on account-level balance and credit. An agent can immediately tell what this tool does and what it is for.

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 strong contextual guidance: it is read-only, free, and scoped to your own account, which tells the agent this is the safe account-information tool. It does not explicitly name a 'when not to use' alternative, but the resource description makes its role clear among the sibling tools.

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

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

With no annotations, the description carries the full burden and does so well: it discloses the auth/billing/validation path, that invoking call_tool itself is FREE, that the wrapped tool bills itself, and that consequential tools are NOT dispatchable. This goes beyond a generic 'call a tool' statement and anticipates the agent's safety concerns.

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

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

Every sentence adds distinct value: the action, the dispatch scope, the exclusion list, the billing note, and the example. It is longer than a one-liner, but it is front-loaded and each clause justifies 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?

The description is sufficient for a dynamic dispatcher: it explains discovery, eligibility, billing, security gating, and gives a full invocation example. No output schema exists, but 'identical auth + billing + validation as a direct call' reasonably implies the wrapped tool's result is returned.

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

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

Schema coverage is 0% and there are two parameters, so the description must compensate. It explains that name is the tool found via search_tools and that arguments are passed through, then provides a concrete example showing the nested arguments structure. It leaves the argument schema intentionally generic because it depends on the target 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 opens with a specific verb and object: 'Run a tool found via search_tools by name, passing its arguments.' It clearly differentiates itself from siblings by naming which tools it dispatches and explicitly listing consequential siblings (create_topup_link, create_baton, mint_token, ask_operator) that must not be routed here.

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

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

It states when to use: for safe/billable utility tools already discovered via search_tools, and explicitly tells the agent to call consequential tools directly by name so the client can gate them with per-tool consent. This gives concrete selection criteria and names the alternative behavior.

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 carries the full burden and does so thoroughly: it discloses ephemerality, per-customer binding, daily mint cap, over-cap pricing with a default, TTL default of 24h, and bounce behavior for expired addresses. This is unusually rich behavioral disclosure.

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

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

The description is dense but every sentence earns its place: main purpose, return value, cost model, parameter semantics, and a concrete example. No filler or redundant restating of the schema.

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

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

For a tool with two optional parameters and no output schema, the description covers return format, cost, defaults, expiration behavior, and provides an example. Nothing critical for correct invocation is missing.

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

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

Schema description coverage is 0%, so the description must add meaning for both parameters. It states purpose_label is informational and explains ttl_seconds default of 24h and its effect on inbound messages. The example further demonstrates usage of purpose_label.

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

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

The description opens with a specific verb and resource: 'Mint a new ephemeral Relaystation address for this agent to receive messages from other agents.' It clearly states the tool's function and distinguishes it from siblings like message_agent (send) and mint_token (different minting 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?

The description clearly implies when to use the tool: when the agent needs an address to receive messages from other agents. It provides context on costs and defaults. However, it does not explicitly name alternatives or state when not to use it, so it stops short of a 5.

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

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

With no annotations, the description carries the full behavioral burden and succeeds: it discloses that creation is billable and charged once, that payment comes from rs_live_* balance, the 3MB content limit, the 422 error path, and that hash-chained batons must be created empty. This is far beyond minimal disclosure.

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

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

The description is long, but the tool is complex and every sentence adds a decision-relevant fact: preset definitions, billing, content rules, the hash-chaining constraint, and examples. Critical constraints are front-loaded before the examples.

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

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

It is remarkably complete for a creation tool: presets, cost, key funding, constraints, error handling, and follow-up writes are all covered. The main gap is that no output schema exists and the description never states what the create call returns (e.g., a baton identifier/address), which an agent would need to chain read_baton or append_to_baton.

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 only 10%, so the description compensates by explaining the meaning of preset values, content size/encoding constraints, flags.hashChaining, and the role of customShape. It does not spell out every auxiliary parameter (name, tags, contentType, contentEncoding, customShape sub-fields), but the decision-critical parameters are well covered.

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

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

The description opens with a specific verb and resource ('Create a baton — a prepaid storage object') and then defines each preset by its intended behavior (store, share, append log, snapshot, tamper-evident log). This clearly distinguishes creation from the sibling read_baton/append_to_baton 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?

It explicitly tells the agent to quote the shape first with quote_baton, to pass content inline or defer to append_to_baton, and provides two concrete call examples. It even states the invalid case (hash-chained content returns 422), so the agent knows when not to include content.

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

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

With no annotations, the description fully carries disclosure: billable charge-on-attempt, tamper-evident hash-chained record, auto-appended signature/arbitration blocks, exact signer identity requirements, and the constraint that terms must not include those blocks. This is unusually thorough.

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 purpose and return values, then structured into behavior, constraints, input/return shape, and example. Though long, every sentence adds operational information needed to call the tool correctly.

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

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

Covers purpose, non-legal caveat, billing, required headers, parameter semantics, exact signer methods, return payload, and post-call distribution of tokens. Given no annotations and no output schema, nothing material is missing.

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

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

Schema description coverage is 0%, but the description defines each parameter: terms, requiredSigners with identity/kind semantics, arbitration, signingWindowSeconds with default, plus an explicit example. This fully compensates for the empty 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?

Description states specific action 'Create a binding-by-goodwill agreement' and the immediate return values (contractId, termsHash, per-signer read tokens). It clearly differs from siblings like sign_contract by defining this as the creation step with no legal/enforcement standing.

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?

Gives clear context: use for goodwill agreements only, explicitly excludes legal enforcement and escrow/money movement, and explains required Idempotency-Key and the per-signer token handoff workflow. It does not explicitly name alternative sibling tools, so not a full 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?

With no annotations provided, the description carries the full burden and handles it well. It discloses the delayed-effect behavior (balance credited only after human pays), returns only a URL, is free to call, and has specific authentication constraints.

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

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

Every sentence carries distinct value: purpose, no-money-moves behavior, usage trigger, parameter semantics, auth requirements, and an example. It is front-loaded with the core action and remains compact despite covering many essential facts.

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

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

Covers purpose, side effects, timing of credit, when to use, auth, and the main parameter. It does not describe the exact shape of the returned response or mention optional redirect URLs, but for a simple one-required-parameter tool with no output schema, it is nearly complete.

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

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

Schema coverage is 0%, so the description must compensate. It explains the critical amountUsd unit and provides a concrete example. It does not explicitly define cancelUrl or successUrl, but their names and the optional uri format in the schema make their meaning reasonably clear.

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

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

States a specific verb (create), a specific resource (Stripe Checkout link), and the goal (add credit to your balance). It clearly differentiates from siblings like create_baton or mint_token by describing a human-facing payment link and explicitly stating no money moves here.

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 it ('Use when you hit insufficient balance'), when not to use it ('not for x402 callers'), and what credentials are required. This gives an agent unambiguous context for choosing and invoking the 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?

No annotations are present, so the description carries the burden. It adds 'FREE' to signal no cost, and clarifies the return content (full description and input schema). However, it does not disclose error behavior for unknown names, case sensitivity, or whether authentication is required, which are relevant for robust agent selection.

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 short phrases plus an example, with the action verb and resource front-loaded. 'FREE' and the example are high-signal and not redundant. Zero 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 single-parameter metadata-lookup tool with no output schema, the description gives the action, the input source and format, and an example. It omits error cases and return formatting, but the tool's simplicity makes these minor. The lack of annotations and output schema is only partially compensated by the 'FREE' note and example.

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 provides only `name: string` with 0% description coverage, so the description must compensate. It adds that the name must be exact and gives its source (search_tools), plus a concrete example `{name:'pdf_merge'}`. This is enough to correctly populate 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?

Description states 'Get one tool's full description and input schema by exact name'—a specific verb, resource, and method. The example and reference to search_tools differentiate it from sibling search_tools, which is for finding tool names, while describe_tool retrieves full details for one exact name.

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

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

The phrase 'by exact name (as returned by search_tools)' tells the agent to first discover names via search_tools and then call describe_tool with that name. It implies that search_tools is the alternative when names are unknown, and provides an example usage. Does not explicitly list exclusion conditions, but for a trivial lookup tool the guidance is sufficient.

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

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

With no annotations, the description carries the behavioral burden and does well: it discloses same-Relaystation routing only, the specific error for external domains, no per-message cost, recipient inbox quota, and the 30-day retention window. It does not cover delivery guarantees or response behavior, but the disclosed constraints are substantial.

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 main action is front-loaded, followed by routing constraints, cost, quota, use cases, an alternative, and a concrete example. Every sentence adds useful information without redundancy.

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

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

The description covers the primary parameters, constraints, cost model, and example usage, which is strong for a tool with no output schema. It falls just short of complete because the optional subject and especially attached_baton_id semantics are not explained despite 0% schema coverage.

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 explains to_address with the address format and demonstrates body via the example, but subject and attached_baton_id are left to inference. The parameter names are partially self-explanatory, but attached_baton_id's role is not actually described.

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

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

The description states a specific action—'Send a message to another Relaystation agent's ephemeral address'—and includes the address format and an example. This clearly differentiates it from siblings like create_baton or call_tool by focusing on agent-to-agent messaging.

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

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

It explicitly says to use this tool for multi-agent coordination: 'delegating subtasks, sharing context, building chains.' It also provides a clear alternative for ongoing high-volume coordination: 'For ongoing coordination involving 30+ messages, prefer a shared LEDGER or SCRATCHPAD Baton.'

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

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

With no annotations, the description carries the full burden. It discloses that the operation creates a token, is free, is owner-only, has a 100-token cap, supports optional constraints, and returns a token id (tok_…) to share as the credential. It does not mention revocation or whether minting affects existing tokens, but it is substantially transparent.

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

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

The description is dense and front-loaded, with no filler. It states the purpose first, then enumerates options and constraints, and ends with a concrete example. The 'FREE' emphasis is slightly promotional but 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?

For a tool with 7 parameters, no output schema, and no annotations, the description covers the core workflow, return value, constraints, and an example. It is missing require_fingerprint and does not fully explain the id parameter, but overall it gives an agent enough to call 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 description coverage is 0%, so the description must compensate. It explains type, reads_allowed/writes_allowed caps, expiry, and IP restriction, and the example clarifies id. However, require_fingerprint is not described, and id is only shown in an example rather than explicitly defined, leaving gaps for a 7-parameter 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 uses a specific verb and resource: 'Mint a collaborator token for a baton.' It clearly states the purpose—letting another agent read/write without your key—and this distinguishes it from sibling tools like create_baton, read_baton, and append_to_baton.

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

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

It gives clear context: use this when you want to grant another agent access to a baton. It also states a key restriction ('Owner only') and a limit ('Up to 100 tokens per baton'), but it does not explicitly contrast with sibling tools or say when not to use it beyond the owner restriction.

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 carries the full disclosure burden and meets it: it reveals the no-per-call-charge/egress-budget behavior, credential semantics, and conditional response behavior (presigned URL/page hint vs inline). This goes well beyond a bare read-only statement.

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 purpose and each sentence adds distinct operational information: cost, addressing, response behavior, and an example. It is slightly denser than necessary but still well-structured and free of filler.

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

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

For a single-parameter read operation with no output schema, the description covers auth, cost, and high-level return formats, including how large results are handled. Nothing needed to correctly invoke the tool is missing.

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

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

The schema already describes the single id parameter at 100% coverage, so the baseline is 3. The description adds meaningful context beyond the schema: owner id requires your key, tok_ is itself the credential, and bat_<id> is the example format.

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

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

The description starts with a specific verb and resource ('Read a baton's content + metadata'), making the tool's purpose immediately clear. It also supplies concrete addressing modes and an example, which distinguish it from baton-creation and mutation siblings like create_baton and append_to_baton.

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

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

It clearly states the two ways to address a baton (owner id with key, collaborator token) and explains the large-vs-small response path, routing to list-entries for paging. It does not explicitly name an excluded sibling or say 'use X instead,' but the contextual cues are strong enough.

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

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

With no annotations, the description carries the behavioral disclosure burden. It provides useful traits: 'FREE', ranked 'best matches', configurable detail levels, and a default limit. It does not describe edge cases like empty results or exact response structure, but for a read-oriented search tool the disclosed behavior is reasonably complete.

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

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

The description is dense but efficient: purpose, workflow, parameter semantics, and an example are all included in a few sentences. Every clause adds value, and the most important information 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 tool with three parameters and no output schema, the description explains how to invoke it, what each parameter does, and what kind of results are returned. Minor gaps remain around exact response formatting and error behavior, but these are not critical 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 description coverage is 0%, so the description fully compensates by explaining all three parameters: query as free text with examples, detail with its three enum values and default, and limit with its default of 5. This adds meaning well beyond the bare 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 a specific action ('Search the full Relaystation tool catalog by keyword') and a concrete outcome ('get back the best matches'). It also distinguishes its role from sibling tools by positioning it as the first step before describe_tool and call_tool, so an agent can easily tell it apart.

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

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

The description explicitly says 'Use this first to find a tool, then describe_tool for its schema and call_tool to run it', giving a clear workflow. It also mentions the alternative of 'call a named hot tool directly', which helps an agent decide when searching is necessary versus when to skip 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?

With no annotations, the description carries the full burden and it delivers: it discloses that wallet signing needs no account, that the signature itself is the authentication, that the last required signer triggers execution and witnessing, and that the call returns the updated contract view. It also reveals the exact EIP-712 domain/type, which is far beyond the schema's capability.

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?

Dense but efficient: the core purpose is front-loaded, and every subsequent sentence adds a necessary constraint, authentication detail, data shape, or return value. The example at the end is a practical summary rather than 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?

For a tool with no annotations and no output schema, this is unusually complete. It explains the two authentication paths, the hash-chain effect, the EIP-712 payload shape, the threshold side effect (executed/witnessed), and the return value. Remaining details like precise error handling are not essential for a competent 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 0%, but the description fully compensates by mapping 'id' to contractId, explaining the 'method' enum's two modes, and specifying that walletAddress and signature are required for the wallet form while only id and method are needed for the account form. The example reinforces these parameter shapes.

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?

Opens with a specific verb+resource ('Append your consent to a contract') and immediately defines the artifact as an entry on the contract's hash chain. It also distinguishes two signing methods, which separates it from the sibling create_contract (creation vs. signing). The purpose is unmistakable.

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?

Clearly explains when to use the wallet method vs the account method and the authentication expectations for each, including the 'no cross-method satisfaction' constraint. It does not name alternative sibling tools explicitly, but the method-selection guidance is concrete enough for choosing the correct call.

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