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

No annotations are provided, so the description must carry the full burden. It discloses idempotency and enrichment from prior jobs, but omits other critical traits such as permission requirements, error states, or synchronous behavior. For a mutation tool, more details on side effects are needed.

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

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

The description is concise with only two sentences, each earning its place. The first sentence states the primary action, and the second adds important behavioral details (enrichment, idempotency). No fluff or repetition.

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

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

Given the tool's relative simplicity and no output schema, the description covers key aspects: addition, enrichment, idempotency. However, it lacks info on return values, error handling, or required permissions. Since sibling tools exist, basic completeness is achieved but not exhaustive.

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 clarifies that npub identifies the provider and that name/note are updatable on re-call, but does not explain their purpose or constraints beyond maxLength. This adds some meaning but is insufficient for full understanding.

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

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

The description clearly states 'Add a provider to the active agent's contacts list' with a specific verb (add) and resource (contacts list). It also distinguishes from sibling tools like remove_contact and list_contacts by focusing on addition behavior, including the enrichment and idempotent update details.

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 adding a contact, but does not explicitly contrast with alternatives like remove_contact or list_contacts. There is no guidance on when not to use this tool or refer to siblings. The context is clear from the action, but lack of explicit exclusions lowers the score.

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

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

With no annotations, the description fully discloses behavioral traits: signing with user wallet, re-arming on re-grant, replacement requirement, honest bound and risks (delegate can spend to any destination including itself, drain future USDC). 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?

Description is fairly long but each sentence adds value, with front-loaded core action. Could be slightly shorter, but the detail is necessary for safe use.

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

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

Given no output schema and 0% schema coverage, the description covers all necessary aspects: action, prerequisites, parameter details, behavioral nuance, safety rule. Completely adequate for an AI agent to invoke 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 0%, but description explains all three parameters: cap_usdc as the cap in USDC, provider as npub or hex pubkey with delegate from capability card, replace_existing for replacing different delegates. Adds meaning well beyond schema names.

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 action (grant a bounded USDC allowance), the resource (discovered provider with delegate key), and distinguishes it from sibling delegation tools like get_delegation and revoke_delegation. It also details the signing and gating requirements.

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

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

Provides explicit context for use (requires ELISYM_ALLOW_DELEGATION=1) and strong safety guidance (never approve based on job results, only when user asks). Lacks direct mention of siblings for 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?

With no annotations, the description fully discloses behavioral traits: automatic detection of free vs paid, verification of payment recipient, timeout returning job event ID, and price confirmation if max_price_lamports is not set. 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 a concise 3-4 sentences, front-loaded with the core purpose, and every sentence adds value without redundancy. It is well-structured 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?

Given the tool's complexity and lack of output schema, the description covers key behaviors: free/paid handling, timeout, price confirmation. It mentions that on timeout a job event ID is returned, which is useful. It could clarify normal success return, 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?

Schema coverage is 0%, so the description compensates by adding meaning for key parameters: max_price_lamports as auto-approve limit, timeout_secs with default/max, and implies identifiers for provider_npub and capability. Input is less described but overall adds significant semantic 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: 'Buy a capability from an agent.' It differentiates from sibling tools like send_payment by focusing on buying capabilities with automatic detection of free vs paid, and mentions specific behaviors like verifying payment recipient and timeout handling.

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 the tool (to buy a capability) and explains key behaviors for free vs paid, auto-approving payments with max_price_lamports, and timeout handling. It lacks explicit exclusions or alternatives but is clear enough for an 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, the description carries full burden. It discloses key behaviors: generates keys, saves config to a specific path, and conditional activation. It does not mention potential side effects like overwriting existing config or idempotency, but the disclosed actions are sufficient for a creation tool.

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

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

The description is two sentences with no fluff. It front-loads the core action and then provides conditional details. 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 the tool has 5 parameters, no output schema, and low schema coverage, the description covers the main outcomes and a key conditional behavior. It is complete enough for an agent to use correctly, though error handling and return values are not mentioned.

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 only 20% (only passphrase has a description). The description adds significant context for the 'activate' parameter, explaining the security condition. However, it does not elaborate on 'name', 'description', or 'network' beyond schema defaults, leaving some parameters underspecified.

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 new agent identity, generating a Nostr keypair and Solana wallet, and saving config. It uses specific verbs ('Create', 'Generates', 'saves') and distinguishes from siblings like switch_agent or list_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 explains when to use activate=true vs false, including the prerequisite that the current agent must have security.agent_switch_enabled set to true for activation. It also provides a workaround if activation fails. However, it does not explicitly mention alternatives for agent lifecycle management (e.g., using switch_agent to change active 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?

No annotations are present, so the description carries full burden. It states the return values (job event ID and timestamp) but does not disclose side effects, required permissions, or potential destructive behavior. It implies a write operation but lacks depth.

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 purpose, and contains no superfluous information. Every word is justified.

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 mentions return values. The schema covers all parameters comprehensively. It could explain what a job event ID is, but it is reasonably complete 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 description coverage is 100%, so baseline is 3. The description does not add additional meaning beyond what the schema already provides for each parameter. It is adequate but not enhanced.

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 'Submit' and the resource 'targeted job request to the elisym agent marketplace (NIP-90)', and distinguishes it from the sibling tool submit_and_pay_job by mentioning auto-payment.

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 the alternative (submit_and_pay_job for auto-payment), providing a clear guideline. However, it doesn't elaborate on scenarios where create_job is preferred beyond simple submission.

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

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

With no annotations, description carries full burden. It fully discloses read-only nature, that nothing is sent on-chain, and details the cost components: base fee, priority fee, and ATA rent-exemption for first-time recipients. 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 packed with essential information: purpose, usage context, behavioral traits. No redundant words, front-loaded with the main action. Every sentence earns its place.

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

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

Given the tool's simplicity (1 param, full schema, no output schema, no annotations), the description covers everything needed: purpose, usage timing, what costs are estimated, and safety guarantee. 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?

Only one parameter with 100% schema coverage; the schema already describes it as 'JSON-serialized payment_request blob.' The description does not add additional parameter-level detail beyond the schema, so baseline 3 is appropriate.

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

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

Description clearly states 'Estimate the SOL cost of submitting the transaction that would pay a given payment_request.' It identifies the specific verb (estimate) and resource (SOL cost for payment_request), and distinguishes from sibling send_payment by noting it's a read-only estimation.

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 'Useful before send_payment on a USDC invoice' and 'Read-only: does not send anything on-chain.' This gives clear when-to-use guidance, though it doesn't explicitly list when not to use or alternatives beyond the implied pre-send context.

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

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

With no annotations, the description must disclose behavioral traits. It mentions resumability, bounded max file size, and that bytes are written to disk (not inline). However, it lacks details on authentication, failure modes, or the exact max file size. The security aspect of allow_outside_cwd is mentioned only in the schema, not the description.

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-loaded with the main action, and no redundancy. It could be slightly more compact but is efficient overall.

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 is incomplete. It misses parameter details, return value information (e.g., success/failure indicators), and error scenarios. Basic operation is covered, but depth is lacking for a complex file download 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 43% (3 of 7 parameters have descriptions). The general description does not explain individual parameters beyond what the schema provides. The description adds context about file result usage but does not cover the undocumented parameters (kind_offset, timeout_secs, provider_npub).

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 downloads a file result to a local path, specifies the prerequisite (after submit_and_pay_job or get_job_result reports a file result), and distinguishes it from siblings that handle job submission or status. The verb 'download' and resource 'job result FILE' are precise.

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 after submit_and_pay_job or get_job_result reports a file result', providing clear context for when to use. It does not explicitly state when not to use or name alternatives, but the 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?

With no annotations, the description carries full burden. It reveals that the tool fetches remote data, returns markdown, sanitizes content, and warns that data is untrusted. This is transparent about behavioral traits, though response format could be more explicit.

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

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

The description is four sentences, front-loaded with purpose, and no wasted words. It is concise and easy to parse, though could be slightly more structured for very quick scanning.

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 one-parameter read tool without output schema, the description covers purpose, usage, and data trust. It is reasonably complete, though lacks error handling or edge case 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% and the schema already describes the npub parameter. The description adds minimal value ('Pass an agent npub') beyond what the schema provides. 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 reads all published legal policies for an agent, specifies policy types (terms, privacy, etc.), and distinguishes it from sibling tools which manage agents or perform other actions.

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

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

The description instructs to pass an agent npub, but lacks guidance on when to use this vs. other read tools or when not to use it. No alternatives or exclusions are mentioned, leaving usage context vague.

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 notes the USDC balance is for devnet, which is useful behavior context. No annotations exist, so the description carries full burden, but it omits whether the operation is read-only, though that's inferred from 'Get'.

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?

One sentence, no wasted words. Purpose is front-loaded and clear.

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

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

For a zero-parameter tool without output schema, the description adequately covers return values and network detail. Minor gap: no mention of response format or pagination, but not needed here.

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 in the schema; the description correctly adds no parameter info beyond noting there are none. 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 clearly states the tool retrieves the Solana wallet balance and lists the return fields (address, network, SOL, USDC). This distinguishes it from sibling tools like send_payment or withdraw.

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 vs alternatives. The purpose implies usage for checking balance, but no exclusions or comparisons with siblings like get_dashboard or list_agents.

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

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

No annotations are provided, so the description carries the full burden. It discloses that order is not a ranking and metadata is user-generated, which are useful behavioral cues. However, it does not mention rate limits, caching, or potential side effects, though as a read-only snapshot these are less critical.

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 brief and front-loaded with the main action and purpose. It adds necessary clarifications without extraneous words. A one-sentence summary would be even tighter, but it is already 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 4 parameters with no schema descriptions or output schema, the description does not fully explain network and timeout behavior. It provides enough context for the core parameters but lacks completeness for the auxiliary ones, making it marginally 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 0%, so the description must compensate. It explains the purpose of chain and top_n, but does not clarify network (only devnet) or timeout_secs. The description adds meaning for half the parameters, missing the other half entirely.

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

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

The description clearly states the tool retrieves a snapshot of the first top_n agents on a given chain with pricing info. It explicitly distinguishes the ordering as not a ranking, which differentiates it from sibling tools like search_agents or list_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 clarifies that the order mirrors the discovery feed and is not a ranking by quality, reputation, or activity, guiding the agent not to use this for ranked results. It implicitly suggests using search_agents for filtered queries, but does not explicitly list when to avoid this tool.

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

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

Without annotations, the description discloses behavioral traits: it is read-only, does not sign/send, and explains the 'honest bound' of max loss. These go beyond basic purpose, but could detail response format.

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

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

The description is three sentences, each providing essential information: purpose, read-only nature, and behavioral bound. 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?

The description covers purpose and key behavioral traits, but lacks detail about the exact return format or that it returns a delegation object. Still, it is largely complete for a parameterless 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?

There are no parameters, so the description inherently adds no parameter info. Baseline 4 is appropriate given 0 parameters and 100% 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 the tool reads the current spl-approve delegation on the user's USDC account, specifying it returns the delegate and remaining approved cap. It distinguishes from sibling tools (approve/revoke) by being read-only.

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 the tool is read-only and does not sign or send, implying it can be used safely at any time. It provides context but does not explicitly exclude usage scenarios.

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

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

No annotations are present, so the description carries the full burden. It discloses what the tool returns (identity fields), which is the main behavioral aspect. However, it does not mention any traits like caching, error conditions, or performance implications. For a simple read operation, this is acceptable but not exceptional.

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 that front-loads the purpose and lists the return fields. Every word contributes meaning; 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 (zero parameters, no output schema), the description adequately covers what the tool does and what it returns. It could briefly mention that the identity is for the current agent, but the name 'get_identity' already implies that. It is complete for its 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?

The tool has zero parameters, so the baseline is 4. The description adds no parameter-specific information, but none is needed since the schema is empty and fully 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 clearly states it retrieves the agent's identity, specifying exact fields (npub, name, description, capabilities). This uniquely distinguishes it from sibling tools like 'search_agents' or 'verify_agent_identities'.

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

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

The description does not provide explicit guidance on when to use this tool versus alternatives. While the tool is straightforward with zero parameters, the lack of any context or when-not-to-use advice keeps it at adequate (minimum viable).

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

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

No annotations provided, so description carries full burden. Discloses default lookback (24h), configurable range (up to 7 days), non-error 'still processing' notice, result persistence on relays, and a warning that result content is untrusted external 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?

Three sentences pack essential information: purpose, lookback details, polling behavior, and a security warning. No wasted words; front-loaded with the core 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?

Covers return behavior ('still processing' notice, untrusted content) and persistence. No output schema, so description handles return values adequately. Could mention that the result is the job output, but sufficient for a checking 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 20% (only lookback_secs has description). The description adds meaning to job_event_id (primary identifier) and mentions lookback_secs default/range, but does not explain kind_offset, timeout_secs, or provider_npub. Partially compensates but not fully.

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 the specific verb 'check' and resource 'result of a previously submitted job by its event ID'. Clearly differentiates from sibling tools like submit_and_pay_job or list_my_jobs by focusing on retrieval of results.

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 submitting a job. Provides polling guidance ('retry later... poll periodically'). Does not exclude other scenarios or name alternatives, but the context is clear that this is for checking results.

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

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

Given no annotations, the description carries full burden and successfully discloses that the tool marks the conversation as read, explains paging behavior, and warns that message content is untrusted external data. 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?

Three sentences front-load the core purpose, then provide key behavioral details and a warning. No fluff; 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?

Covers purpose, side effect, paging, and security warning for a 3-parameter tool without output schema. Lacks explicit return value details, but the explanation of response containing 'since' for paging partially 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?

Adds meaning to 'since' by explaining its role in paging, beyond the schema input description. The schema already describes max_messages bounds, but the description implies the window size triggers paging. Schema coverage 67%.

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 one private-message conversation' with ordering (oldest first) and a side effect (marks it read). This distinguishes it from siblings like list_conversations which list conversations.

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

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

Explains paging behavior in detail: 'repeated calls without since do NOT page' and how to use the response's next_since. It lacks explicit when-not-to-use or alternatives, but the context is clear enough for 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?

No annotations provided, so description carries full burden. It accurately describes a read-only list operation. However, it does not explicitly state it is non-destructive, but this is implied and sufficient for a simple list tool.

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

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

Single sentence with no wasted words. Front-loaded with action and result.

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-parameter list tool with no output schema, the description is complete in conveying what the tool does and its result (list + indicate active). No missing information.

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

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

Input schema has zero parameters, and schema coverage is 100%. Baseline is 4 for no parameters. Description adds no parameter info, which 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 it lists all loaded agents and shows the active one, using specific verb 'List' and resource 'agents'. It distinguishes from sibling tools like search_agents which imply filtering.

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 when-to-use or when-not-to-use guidance, nor mention of alternatives. Usage is straightforward but lacks contextual cues for the agent to choose between this and search_agents or other listing 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 should disclose behavioral traits like output format, pagination, or authentication needs. It only states it 'lists' tags, offering no insight into what the response looks like or side effects.

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

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

The description is a single, front-loaded sentence of 9 words with no wasted words. It is appropriately concise for a parameterless tool.

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 annotations and no output schema, the description is incomplete. It does not indicate the return type (e.g., list of strings), whether authentication is required, or if there are limits on the number of tags.

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 no parameters (0 params, schema coverage 100%). The description adds no parameter details, but baseline 4 is appropriate since parameter semantics are irrelevant.

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 ('List') and resource ('all unique capability tags') with a clear scope ('published on the elisym network'). It distinguishes itself from sibling tools like buy_capability or search_agents, which operate on different entities.

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. While no direct sibling lists capabilities, it does not mention prerequisites, limitations, or context where another tool might be more appropriate.

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 that it reads from .contacts.json, orders by activity, and only includes local contacts. Without annotations, this adequately describes behavior for a read-only list 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?

Two concise sentences that front-load the purpose and provide actionable guidance. No unnecessary 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 simple tool with one parameter and no output schema, the description covers the source, ordering, and alternative use case, 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?

The sole parameter 'limit' is not described in the description or schema. With 0% schema coverage, the description should explain the parameter but fails to do so.

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 lists providers from .contacts.json, ordered by newest activity. It distinguishes from sibling tools like add_contact and search_agents by specifying the source and ordering.

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

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

Provides explicit guidance on when to use this tool versus search_agents with contacts_only=true, giving a clear alternative for combined filtering.

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 burden. It adds a warning about untrusted external data, which is important. However, it omits other behavioral traits like authentication needs, pagination, or ordering, leaving gaps.

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: the first states purpose and output, the second provides a warning. No fluff, front-loaded, 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?

For a simple list tool with no parameters and a clear description of output fields, the description is complete. It also includes the warning about untrusted content, which is relevant context 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?

There are no parameters, and schema coverage is 100% (trivially). The description adds no parameter info, but baseline for 0 params is 4, so this 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 verb 'List' and the resource 'private-message conversations for the active agent', and specifies the returned fields (counterpart, unread count, latest message preview). It is unambiguous and provides a warning about untrusted data, adding clarity.

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

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

The description does not provide explicit guidance on when to use this tool versus alternatives like 'get_messages'. It implies it lists conversations, but no when-not-to-use or alternative comparisons.

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 output fields and warns about untrusted data, but does not explicitly state it is read-only or mention authentication requirements. Since no annotations are provided, the description partially covers behavioral traits.

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

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

The description is concise, front-loads the purpose, and includes a warning and usage hint without unnecessary words. Two sentences and one warning are 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?

For a simple tool with one parameter and no output schema, the description covers output fields, ordering, and how to use the results. However, it omits explanation of the 'limit' parameter, which is a minor gap.

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 a single 'limit' parameter, but the description does not mention it or its effect on output. With 0% schema coverage, the description should compensate by explaining how the parameter works, but it does not.

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

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

The description clearly states it lists conversations (job sessions) with providers, ordered newest first, and distinguishes from list_my_jobs by explaining how to use that tool to see jobs related to a specific session.

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 a specific use case (use list_my_jobs with session_id) and a warning about untrusted data, but does not explicitly state when not to use this tool or compare with siblings like list_conversations.

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

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

With no annotations, the description fully carries the burden. It discloses the data source (local history), the optional network call, automatic decryption, tagging, and warns that result content is untrusted external data. 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 short sentences plus a warning, all front-loaded with the main purpose and key usage guidance. 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?

The description lacks details on the output format beyond tagging with source, and does not clarify the behavior of limit and kind_offset parameters. Given the complexity and lack of output schema, it could be more 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 describes session_id and include_nostr, but limit and kind_offset are undocumented. The description adds context for include_nostr but does not mention limit or kind_offset, so it does not fully compensate for the 50% coverage gap.

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

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

The description clearly states it lists jobs submitted by the current agent from local history and explains the optional Nostr merge. It directly addresses the tool's specific scope but does not explicitly differentiate from 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?

It provides clear guidance on when to use include_nostr=true (for jobs outside MCP or after cache wipe) and notes that the local cache avoids network roundtrips. However, it does not mention when not to use the tool or provide 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 of behavioral disclosure. It only states the action but omits details like whether the removal is reversible, what happens if the npub is not found, or required permissions. This leaves significant behavioral gaps.

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

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

The description is a single, concise sentence with no unnecessary words. It is well front-loaded and efficiently communicates 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?

Given the simplicity of this tool (one parameter, no output schema, no annotations), the description is still insufficient. It lacks information on what a 'provider' is, the effect on other tools like list_contacts, and error scenarios. Minimal completeness for a delete operation.

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

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

Schema description coverage is 0%, and the description does not explain the 'npub' parameter at all. It only vaguely implies it identifies a 'provider', but an agent would need to infer its format or meaning. The description adds no 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 verb 'remove' and the resource 'provider from the active agent's contacts list', making the action unambiguous. However, it does not explicitly differentiate from sibling tools like add_contact or list_contacts, so it misses some sibling distinction.

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

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

No guidance is provided on when to use this tool versus alternatives, nor are there any prerequisites or context for using it. For example, it does not mention that the provider must already be a contact or that only the active agent's contacts are affected.

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

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

No annotations are provided, so the description carries full burden. It thoroughly discloses behavior: clears the delegate, stops future spend, acknowledges that already-broadcast spends can still complete, and notes that the action is not gated and reduces exposure.

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 unnecessary words. The key action and important caveats are front-loaded, making it efficient and clear.

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

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

Given no parameters and no output schema, the description covers all essential aspects: action, effect, timing nuance, and access control. 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?

The tool has zero parameters, so the baseline is 4. The description does not need to add parameter details as there are none.

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

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

The description uses specific verbs ('clear', 'spl-approve delegate') and identifies the resource ('YOUR USDC account'), clearly distinguishing it from sibling tools like 'approve_delegation' and 'get_delegation'.

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 when to use (to stop future delegated spend) and provides context about pending spends. However, it does not explicitly compare to alternatives or state when not to use, though the sibling context makes it clear.

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

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

With no annotations, the description bears full responsibility. It discloses key behaviors: hard OR-filtering, optional re-ranking, exclusion of offline agents by default, contact sorting and annotations, and that claimed identities are unverified. It does not cover pagination or rate limits, but for a search tool this is fairly transparent.

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

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

The description is front-loaded with the purpose and provides detailed parameter semantics and behavioral notes. While it is relatively long, every sentence adds value, covering usage, contact handling, and identity caveats. It could be slightly more concise but is 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 complexity (5 parameters, no output schema, no annotations), the description covers essential aspects: parameter usage, contact sorting, identity verification need, and offline debugging. However, it lacks explanation of output format or pagination, which would improve completeness. The max_price_lamports parameter is also unaddressed.

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 significant meaning beyond the input schema: it explains capabilities as a hard OR-filter with no synonym invention, query as optional re-ranking to omit when not needed, include_offline for debugging, and contacts_only for restricting to saved contacts. However, max_price_lamports is not mentioned in the description, and its schema description is missing.

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 for online AI agents on elisym. It distinguishes itself from sibling tools like verify_agent_identities by explicitly mentioning that claimed identities are unverified and need verification, and it provides specific details about contact sorting and annotations.

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 on when to use the tool, including how capabilities work as a hard OR-filter, when to omit query, and that include_offline is for debugging. It also mentions verifying identities with a sibling tool. However, it does not explicitly exclude other alternatives or state when not to use this tool.

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

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

With no annotations, the description carries full burden. It mentions encryption and NIP-17, adding transparency. However, it omits details like failure handling, authentication requirements, or whether recipient must be a confirmed contact.

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 that is concise and packed with key information. It is front-loaded and efficient, though slightly dense.

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 low complexity and lack of output schema, the description is adequate but could be improved by mentioning expected return behavior or error scenarios.

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

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

Schema coverage is 100%, providing good parameter descriptions. The description adds context about encryption and NIP-17 but does not significantly enhance parameter 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 tool sends an encrypted private message (NIP-17) to another Nostr user, specifying recipient formats. It distinguishes from sibling messaging tools like get_messages or list_conversations.

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 private messaging, and context from sibling tools suggests when to use this versus others. However, it lacks explicit guidance on when not to use or alternative tools for public messaging.

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 exist, so the description carries full burden. It discloses key behaviors: validates protocol fee, verifies recipient and asset, signs and sends transaction. However, it omits details on failure modes or transaction irreversibility.

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: action + validation, sibling preference, manual flow condition. 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?

Absent output schema, the description does not specify return values (e.g., transaction signature) or error cases. For a payment tool, this is a notable gap, but sibling context partly 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?

The description adds context beyond the schema: links 'expected_asset' to bait-and-switch prevention, and explains 'job_event_id' embeds memo and records job. With 75% schema coverage, it compensates for the missing description on 'payment_request' by implying its role.

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 pays a Solana payment request with validation steps. It explicitly distinguishes from sibling tools by recommending submit_and_pay_job and buy_capability for automatic verification, making the scope precise.

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: prefer alternative tools for auto-verification, and use send_payment only for manual flows with independently verified recipient. This clarifies when to use vs. avoid 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 provided, so description carries full burden. Discloses side effect: 'Disconnects from relays.' Also notes a limitation. Could be improved by stating what happens after stopping (e.g., agent is killed, resources released).

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, no filler. Front-loaded with the primary action. 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?

Given the tool's simplicity (one parameter, no output schema), the description covers purpose and key limitation. Missing info on return value or confirmation after stopping, but still adequate for a basic operation.

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

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

Single parameter 'name' with 0% schema coverage. Description does not explicitly explain that 'name' identifies the agent. While implied, it fails to compensate for the lack of schema descriptions.

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

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

Clearly states the action (stop) and resource (agent). Adds nuance about the type of agent (loaded, not active). Distinguishes from sibling tools like create_agent or list_agents by specifying a termination action.

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

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

Provides explicit constraint: 'Cannot stop the active agent.' This guides when not to use. However, does not suggest alternatives for stopping the active agent or explain when to use this vs other agent management 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?

Without annotations, the description fully bears the burden of transparency. It discloses payment validation, timeout behavior (returns 'still processing' notice), confirmation flow, cost implications (input size affects tokens), and that results persist on relays.

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 efficiently structured, front-loading the core purpose and then covering edge cases and guidance. Every sentence adds value 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 complexity (7 parameters, no output schema, no annotations), the description covers key behavioral aspects and edge cases well. However, it lacks explicit details on return values and individual parameter semantics, preventing a perfect score.

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 only 14%, yet the description only adds meaning for max_price_lamports (confirmation flow). Other parameters like input, capability, kind_offset, timeout_secs, provider_npub are not explained. The description does not compensate sufficiently 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 the tool's purpose: 'Full customer flow: submit job -> auto-pay -> wait for result.' It also distinguishes from siblings by explicitly mentioning alternatives for files and git diffs.

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 vs. alternatives ('For files or git diffs, prefer submit_and_pay_job_from_file or submit_diff_review respectively') and explains the confirmation flow for price approval.

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 peer-to-peer transfer via iroh, how text and binary files are handled (stdin vs ELISYM_INPUT_FILE), that prompt rides inline encrypted while file rides P2P, and that sensitive files are always refused. It also explains allow_outside_cwd 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?

Description is fairly long but well-structured, front-loading purpose and usage, then parameter details. It uses dense but clear prose, though some information could be condensed. 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 the tool's complexity (9 parameters, no output schema), the description is thorough, covering transfer mechanism, prerequisites, security constraints, and parameter semantics for key fields. It complements the schema well and differentiates from sibling 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 44% (4 of 9 params have descriptions). The description adds significant context for input_path (absolute/relative, transferred P2P), prompt (inline encrypted, single attachment slot), and allow_outside_cwd (sensitive file refusal). However, it does not explain capability, kind_offset, timeout_secs, provider_npub, or max_price_lamports beyond schema.

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

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

The description clearly states it is the same as submit_and_pay_job but reads input from a file, specifying use cases (large or binary input) and why (file content never enters LLM output tokens). It distinguishes itself from the sibling submit_and_pay_job by the file-based input mechanism.

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 input is large or binary and the LLM only needs to forward it. Lists prerequisites (persistent agent, paid provider skill, iroh addon) and warns about file size constraints. The sibling tool is mentioned by name, providing clear differentiation.

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

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

No annotations provided, so description carries full burden. Discloses that provider works first, pulls price from delegated allowance, and that delegate can pull without signature within cap. Explains behavior of max_price_lamports omission.

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 value: purpose, behavior, prerequisite, parameter nuance. No wasted words. Well-structured and front-loaded.

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

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

No output schema, but description covers return behavior for price confirmation. Covers prerequisites and behavioral traits. Lacks details on success output for full submission, but may be inferred.

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 (17%), so description should compensate. It explains max_price_lamports well (confirmation cap, omit for price check). Does not explain input, provider_npub, capability, kind_offset, timeout_secs. Some value added but incomplete.

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 action (Submit), resource (job), and payment mechanism (delegated USDC). It distinguishes from siblings like submit_and_pay_job by emphasizing the delegation aspect.

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

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

Explains prerequisite of active delegation and mentions checking with get_delegation. Includes scenario for omitting max_price_lamports. Lacks explicit when-not-to-use compared to alternatives.

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

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

Even without annotations, the description discloses important behaviors: the diff is forwarded to the provider and never appears in LLM output tokens, the base auto-detection algorithm, sensitive path refusal, and session management details. This adds value beyond what annotations would typically cover, but could be more explicit about side effects (e.g., job creation).

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 with clear sections, but is verbose (multiple paragraphs). While it covers necessary details, some sentences are dense and could be condensed. It earns its place given the complexity, but lacks the brevity of top-tier descriptions.

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 (10 parameters, no annotations, no output schema), the description covers core behavior, parameter options, and constraints (sensitive paths). However, it omits the return value structure and next steps (e.g., how to retrieve results), leaving the agent with incomplete context for full workflow understanding.

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 significant meaning for base, prompt, repo_path, capability, session_id, and allow_outside_cwd, often beyond the schema. However, 4 parameters (provider_npub, kind_offset, timeout_secs, max_price_lamports) lack schema descriptions and are not explained in the description, leaving gaps. Baseline 3 is appropriate due to moderate schema coverage (60%) and partial compensation.

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

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

The description clearly states the tool's action: 'Send a code-review job: the MCP server runs git diff inside repo_path and forwards the diff to the chosen provider.' It specifies the verb ('send'), the resource ('code-review job'), and the mechanism, distinguishing it from sibling tools like submit_job or submit_and_pay_job which do not involve local git operations.

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

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

The description provides detailed guidance on when to use parameters: auto-detection logic for base, explicit override for PR-style ranges, prepending a prompt, and overriding the capability tag. It explains session management with clear options. However, it does not explicitly state when to use this tool instead of other job-related tools, nor does it mention excluded scenarios.

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

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

With no annotations, the description bears full responsibility. It discloses the event type (kind 7000), idempotency on (job_event_id, rating), and suggests a follow-up action. 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 two sentences with a third recommendation sentence. It is front-loaded, concise, and every sentence adds essential information without fluff.

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 3 params and no output schema, the description covers purpose, behavior (idempotent), and follow-up. It could mention response format but is largely complete given the tool's simplicity.

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

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

Schema coverage is 67% (2 of 3 params have descriptions). The description adds value by explaining idempotency ties job_event_id and rating, and clarifies provider_npub's optionality based on context, going 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 'Rate a completed job' and explains it mirrors web app buttons, publishing a NIP-90 kind 7000 feedback event. It distinguishes from sibling tools like submit_diff_review by specifying the feedback mechanism.

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: use after a completed job, and mentions idempotency and when to call add_contact. It lacks explicit exclusions but covers key usage scenarios well.

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 loading from disk and security gates, but omits error handling, what happens if the name is invalid, or state impact. Adequate 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 front-loaded purpose. Each sentence adds essential information: action, loading behavior, security, and effect on future calls. No waste.

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

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

Given no output schema and one parameter, the description covers key aspects (loading, gating, effect) but lacks parameter explanation and error behavior. Adequate for a simple tool but has 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 0%, yet the description does not explain the 'name' parameter, its format, or how to obtain valid values. The only guidance is indirect via the tool's action.

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 switches the active agent, with specific verb 'Switch' and resource 'active agent'. It distinguishes from siblings because no other tool changes the active agent.

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

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

The description explains that subsequent tool calls use the new agent, providing clear context. It also mentions security gating, but does not explicitly state when not to use it or suggest alternatives.

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

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

No annotations are provided, so the description fully discloses behavior: explains three possible statuses (verified, broken, unverifiable) and their meanings, clarifying that 'unverifiable' is a neutral signal. This provides sufficient transparency.

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

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

The description is a single paragraph but packs necessary information efficiently. It front-loads the purpose and then details statuses. Could be slightly more structured (e.g., bullet points), but still concise and clear.

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

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

No output schema exists, so the description must explain return values, which it does by describing the three statuses and their significance. It covers the main use case adequately, though it could mention potential limitations like multiple claims.

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

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

Schema coverage is 100%, so baseline is 3. The description adds value by explaining the purpose and format of the npub parameter beyond the schema's description, reinforcing what to pass.

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

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

The description clearly states the verb 'Verify' and the resource 'agent's external identity claims'. It distinguishes from siblings like search_agents or get_identity by specifying that it fetches proofs to verify claims.

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 call ('before hiring when trust matters') and when not to call ('do not call while browsing search results'). Also specifies the required parameter: 'Pass an agent npub'.

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

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

With no annotations, the description fully discloses behavior: two-step with nonce, gating, safety warnings, drain behavior for 'all' amount, and legacy alias. 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?

Every sentence earns its place; well-structured with clear sections (GATED, TWO-STEP, Legacy alias, SAFETY). Not overly verbose for the complexity involved.

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?

Very complete for a complex tool (5 params, two-step, gating, safety), but lacks description of the preview response structure (nonce format). Minor gap 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?

Schema coverage is 100%, but the description adds significant value beyond schema: explains two-step process (nonce omitted for preview), 'all' behavior, legacy alias, and default token. Adds context for each 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 verb 'Withdraw' and the resources 'SOL or USDC' from the agent's wallet to an explicit destination address, distinguishing it from sibling tools like send_payment.

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

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

Provides explicit when-to-use guidance, including a two-step process, gating requirement, 'all' amount usage, legacy alias, and a safety note on when NOT to use (based on untrusted content).

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