Relaystation

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

With no annotations, the description discloses behavioral details: FREE cost, owner/editor access, and the overwrite toggle for full replacement. However, it lacks details on error conditions, concurrency behavior (beyond version_id hint), or what happens if overwrite is false on overwrite-shaped batons.

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 succinct sentences plus an example, all front-loaded with key information. Every sentence serves a purpose: function, cost/access, and usage example.

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 6 parameters and no output schema, the description covers core behavior, access, cost, and example. It omits explanations for contentEncoding and contentType, but the overall operation is clear. Completeness is adequate for a straightforward write 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 low (33%). The description adds value by explaining the overwrite parameter's effect and providing an example. However, it does not explain contentEncoding, contentType, or version_id, leaving gaps that the schema only partially fills.

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 writes to a baton, distinguishing between append and overwrite modes. The description explicitly mentions the two presets (append/append-chained and single-object/checkpoint), which differentiates it from sibling tools like read_baton and 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?

Provides access requirements ('Owner or editor/write-token only'), cost information ('FREE'), and an example usage. It implies when to use (writing to an existing baton) but does not explicitly state when not to use or compare to alternatives like create_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?

No annotations provided, so description carries full burden. It discloses latency (1-15 min, ~10 sec), cost ($0.005, 5 free/day), blocking nature, and behavior when operator is away or disabled.

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 well-structured and front-loaded, but contains several pieces of information (cost, latency, alternatives) that could be slightly more concise. Still efficient.

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

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

Given no annotations or output schema, description covers purpose, usage, behavior, cost, latency, error handling. Lacks explicit return value description, but it's implied. Good overall 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 0% schema description coverage, description compensates well for message and attached_baton_id (explains cost and use case). However, max_wait_seconds is not explicitly tied to the parameter, relying on implicit understanding. Still adds significant value.

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 sends a question to a human operator via Telegram and waits for a reply. It distinguishes from sibling notify_operator and fallback options.

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 (need decision/approval/clarification) and when not (if operator disabled, use in-IDE; for long messages, use ask_operator_email or attach Baton). Also contrasts with notify_operator.

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

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

No annotations provided, so description carries full burden. It discloses read-only nature, free usage, and authentication requirement. Could mention error behavior, but current details are adequate.

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 and an example; every sentence adds value. Front-loaded with purpose, concise and 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, but description mentions balance, credit, and profile. Could be more specific about profile fields, but adequate for a simple 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 has 0 parameters, baseline is 4. Description adds value by explaining the empty input via example 'balance {}' and clarifying no arguments 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 it returns balance, available credit, and account profile. It uses specific nouns and distinguishes from sibling tools like create_contract or mint_token.

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: read-only, free, requires specific key, and scoped to own account. Includes an example. No explicit when-not-to-use or alternatives, but context 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?

No annotations are provided, so the description carries the burden. It discloses that the tool dispatches through identical auth, billing, and validation as a direct call, and lists non-dispatchable tools. However, it does not mention error handling, rate limits, or response format, which would improve transparency.

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

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

Description is two sentences plus an example, very concise. Front-loaded with the main purpose, no wasted words. 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 does not explain the return value (presumably the result of the called tool). Also missing error handling notes. However, the tool is simple and the essential information is present.

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 description must compensate. It explains that 'name' should be a tool from search_tools, and 'arguments' are the wrapped tool's arguments. An example is provided. This adds meaning beyond the schema's type definitions, though the exact structure of arguments is left to the wrapped 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?

Description clearly states the tool runs a tool found via search_tools by name and passes its arguments. It distinguishes itself by specifying which tools are dispatchable (safe/billable utility) and which are not (consequential), with examples. This provides a specific verb+resource and sibling differentiation.

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

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

Explicitly tells when to use this tool (for utility tools from search_tools) and when not to (consequential tools like create_topup_link, etc., should be called directly). Also states that invocation is free (the wrapped tool bills itself). Provides clear usage context and alternatives.

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

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

No annotations provided, so description carries full burden. It discloses key behaviors: ephemeral nature, free tier up to daily cap, over-cap pricing via Pattern A, TTL defaults to 24h, and that past-TTL addresses bounce inbound messages. This is comprehensive.

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

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

Description is concise, front-loaded with the main action, and includes a relevant example. No superfluous sentences.

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

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

Complete for a tool with no output schema: describes return format (unique address), usage limits, pricing, and TTL. All necessary information for an AI agent to invoke correctly.

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

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

Schema has 0% description coverage, but the description explains both parameters: purpose_label as informational, ttl_seconds default and behavior. It also provides an example usage, adding significant 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?

Description clearly states the tool mints an ephemeral Relaystation address for receiving messages, with specific verb and resource. It distinguishes from sibling tools like create_baton or create_contract by focusing on address creation for 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?

Description explicitly states the use case: to receive messages from other agents. It does not provide when-not-to-use or compare with alternatives, but the context is clear enough for an AI agent to decide.

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 is billable, charged at create, funded from balance via rs_live_* key, content limited to ≤3MB with base64 for binary, and the hash-chained restriction leading to a 422 error if violated. It also mentions the auto-inclusion of a prepaid witness for hash-chaining.

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 purpose and then elaborates in a logical order. It is verbose but every sentence adds value, including examples and caveats. Minor improvement could be more structured (e.g., bullet points) but overall it's effective without being wasteful.

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 10 parameters, nested objects, and no output schema, the description covers creation, presets, tiers, content, flags, customShape, billing, error conditions, and references sibling tools. However, it does not describe the return value (e.g., baton ID), which could help the agent understand the full flow. Still, it is quite 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 has only 10% description coverage (only 'tier' has a description), but the description extensively adds meaning: it explains each preset's purpose, valid tiers per preset, the use of flags, content encoding, and customShape fields. It goes beyond the schema by giving practical usage constraints and examples.

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 in the first sentence: 'Create a baton — a prepaid storage object.' It distinguishes from siblings like append_to_baton and read_baton by focusing on creation and enumerating presets. The mention of hash-chained batons needing empty creation further clarifies its role.

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

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

The description provides explicit guidance on when to use this tool, including the requirement to quote before creation via quote_baton, the billing implication, and the crucial caveat that hash-chained batons must be created empty. It also gives examples for both regular and hash-chained creation, effectively telling the agent how to proceed.

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 all behavioral traits: hash-chained, tamper-evident, billable, appends blocks, signer methods, and that it's not legally binding. With no annotations, this fully informs the agent of side effects and 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?

The description is long but well-structured: starts with purpose, then lays out key characteristics, input, output, and an example. Every sentence adds value, though some redundancy exists (e.g., repeating 'not legally binding').

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 clearly states return fields and usage hints. Covers all parameters, behavior, and post-invocation actions (handing tokens). No significant 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?

Adds rich meaning beyond the schema: explains 'terms' must not contain blocks, 'requiredSigners' format with identity/kind semantics (wallet vs account), 'arbitration' boolean effect, and 'signingWindowSeconds' default. Schema coverage was 0%, so description fully compensates.

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 'binding-by-goodwill agreement' and returns contract details. It distinguishes from siblings like 'sign_contract' by emphasizing creation, and specifies limitations (not legally binding, no escrow).

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

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

Explicitly describes when to use (creating agreements), what it does not do (no legal enforcement, no money movement), prerequisites (Idempotency-Key), and provides a usage example. Clearly contrasts with alternatives.

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

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

With no annotations provided, the description carries the full burden. It clearly states that no money moves immediately—only a URL is returned, and balance credits occur upon payment. It also notes that the call is free and requires specific auth keys, providing good 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 a single, well-structured paragraph of about 4 sentences. It front-loads the main purpose, then clarifies behavioral nuances, usage context, auth, and an example. No 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 tool with 3 parameters and no output schema, the description explains the core purpose and outcome (returns a URL), auth, and an example. However, it omits documentation for the two optional parameters (cancelUrl, successUrl), which are important for the 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?

The input schema has 3 parameters but only 'amountUsd' is described in the description ('dollars (whole cents)'). The optional 'cancelUrl' and 'successUrl' are not mentioned. With 0% schema description coverage, the description should compensate, but it leaves two parameters undocumented.

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 one-tap Stripe Checkout link to add credit to the user's balance. It uses a specific verb 'create' and resource 'topup link', distinguishing it from sibling tools like 'create_baton' or 'create_contract' 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 provides explicit context: use when balance is insufficient, and notes that the link is handed to a human for payment. It mentions auth requirements (rs_live_* key) and that it's not for x402 callers. However, it does not explicitly state when not to use the tool or mention alternative tools.

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

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

No annotations provided, so description carries burden. Mentions 'FREE', which hints at cost behavior, but does not disclose read-only or side-effect-free nature. Example adds some transparency but not comprehensive.

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 filler. Front-loaded with purpose and method, includes a concrete example. Every word earns its place.

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

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

Simple tool with one parameter and no output schema. Description covers purpose, parameter usage, and example. Could mention return format but not critical given the simplicity. Adequately 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 description must compensate. It adds semantics by specifying the parameter is the exact tool name from search_tools and provides an example ('pdf_merge'), adding meaning beyond the plain string type.

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?

Clear verb 'Get' combined with specific resource 'tool's full description and input schema'. Differentiates from sibling 'search_tools' by specifying exact name requirement and referencing search_tools 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?

Explicitly states 'by exact name (as returned by search_tools)', providing clear context for when to use. Includes an example usage. Lacks explicit 'when not to use' but the context with sibling tools implies 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, description fully covers behavioral traits: ephemeral address format, same-Relaystation routing, free but subject to inbox quota, 30-day retention window, and error for external domains. Could mention if delivery is guaranteed or async, but still strong.

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 paragraph with multiple sentences, front-loaded with purpose. Information dense but not overly verbose. Could be structured with bullets, but current format is clear and 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, no output schema, and no annotations, description explains purpose, usage, constraints, alternatives, cost, and quota. Lacks details on output or success/error indicators, but comprehensive overall.

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

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

Schema description coverage is 0%, so description must compensate. It explains 'to_address' format and 'body' with example, but does not describe 'subject' or 'attached_baton_id'. Partially adds meaning but misses two 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 'Send a message to another Relaystation agent's ephemeral address' with specific verb and resource. It distinguishes from sibling tools by contrasting with Baton tools for ongoing coordination, and mentions the address 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?

Explicitly states when to use: 'Use for multi-agent coordination: delegating subtasks, sharing context, building chains.' Provides alternative: 'For ongoing coordination involving 30+ messages, prefer a shared LEDGER or SCRATCHPAD Baton.' Also notes routing constraint and error for external domains.

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

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

No annotations provided, so description carries burden. It discloses cost (FREE), ownership restriction, token limit, and return value (token id). It lacks details on failure behavior or idempotency, but for a token minting tool, transparency is adequate.

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 + example) and front-loaded with the primary purpose. It could be slightly more structured, but there is minimal 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 7 parameters, no output schema, and no annotations, the description covers purpose, constraints, and most parameters. It is missing explanation for require_fingerprint and does not describe what happens on failure. Adequate but not fully comprehensive.

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

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

Schema description coverage is 0%, so description must compensate. It explains type, reads_allowed, writes_allowed, expiry, and ip_allow_list in prose and example. However, it omits require_fingerprint entirely and does not detail format for expires_at. Partially adds value.

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: 'Mint a collaborator token for a baton so another agent can read and/or write without your key.' It specifies the verb (mint) and resource (collaborator token for a baton), and the context distinguishes it from siblings like create_baton and read_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?

Provides clear context: 'Owner only', 'FREE', 'Up to 100 tokens per baton', and advises to share the token id. It does not explicitly state when not to use or compare to alternatives, but the guidelines are sufficient for typical 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?

With no annotations, the description carries full burden. It discloses key behaviors: free usage, two addressing modes, and handling of large vs. small content (presigned URL or inline). Missing error cases, but core behavior is well-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 relatively long but each sentence adds value. It is front-loaded with the main action and structured logically. A minor reduction in redundancy could improve it, but it remains 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 adequately covers return behavior (inline vs. presigned URL) and addressing options. Context about siblings is implicitly clear given the tool's distinct purpose.

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%, but the description adds meaningful context: it explains that 'id' can be a baton id or a collaborator token (tok_…), and that the token itself serves as the credential. This goes beyond the schema's 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 'Read a baton's content + metadata.' It uses a specific verb ('Read') and resource ('baton'), and distinguishes from siblings like create_baton and append_to_baton by focusing on reading.

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 guidance on when to use each addressing method (owner id requires your key, collaborator token is the credential). It also explains billing ('FREE') and gives a concrete example.

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

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

No annotations provided, but description mentions it's FREE, read-only search behavior, and outlines output control via detail parameter. Lack of explicit read-only flag is minor given context.

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

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

Three sentences front-loaded with purpose, followed by usage flow and parameter details. Every sentence adds value, 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?

Covers key aspects: purpose, usage, parameters, and costing. Lacks explicit return structure details, but for a search tool the description is sufficient 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?

Despite 0% schema coverage, the description explains all three parameters: query is free text, detail controls output verbosity with enum values listed, limit defaults to 5 with range implied. Completely compensates for schema gaps.

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 searches the tool catalog by keyword and returns best matches. It distinguishes itself from sibling tools like describe_tool and call_tool by positioning as the first 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 instructs to use this first, then describe_tool for schema and call_tool to run. Provides query examples and explains parameter defaults, giving clear when-to-use guidance.

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

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

No annotations provided, so description carries full burden. It discloses that signing appends consent, contract becomes executed when last required signer signs, and returns updated view. The EIP-712 specifics and domain info are included.

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 packs essential details without fluff. It covers all key aspects efficiently, though slightly front-loaded with technical EIP-712 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?

Given no output schema, the description states 'returns the updated contract view,' which is sufficient. It covers two methods, authentication, and execution condition. Missing details like error cases but generally 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 coverage, the description adds full meaning: explains id, method enum, walletAddress and signature for wallet method, and account method requirements. Examples and typed data details compensate for schema gaps.

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 appends consent to a contract, distinguishing between two signing methods (wallet/account). It specifies the action on a specific resource and differentiates from siblings like create_contract.

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 wallet vs account method, including authentication requirements. It notes 'no cross-method satisfaction' and that the last signer triggers execution. However, it does not explicitly state when not to use the tool.

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