Seneschal Data

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 the access model ('Free, no payment'), that it mirrors the live upstream registry, that it can be invoked without leaving the MCP session, and that format="gopher" is the default. It does not mention rate limits, caching, or staleness of the mirror, which keeps it short of a 5.

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

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

Purpose and entry point are front-loaded, and each sentence is largely functional. However, it re-enumerates the full section list and the per-service list already present in the schema, which is redundant bulk for an otherwise dense paragraph.

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

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

With no output schema, the description steps in to specify the return shapes (compact RFC-1436 gopher menu vs. structured {title, items[]}) and the default format, plus pagination via cursor. An agent has everything needed to call and interpret the tool correctly.

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

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

Schema coverage is 100% and the schema description already enumerates the section values, the cursor source, and the format enum. The description mostly restates those enumerations, so it adds limited meaning beyond the schema; the one genuine addition is the drill-down composition narrative ('<site>/about', '<site>/actions'). Baseline 3 applies.

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

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

States a specific verb+resource: a 'discovery index of this ecosystem' plus a 'LIVE mirror of the official MCP registry'. It names the concrete projects it indexes and clearly separates itself from the action-oriented siblings (board_post, checkout_invoice_create, etc.), which are all operations on those sites rather than the directory itself.

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

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

Gives explicit navigation instructions ('Start with section="root"... then call again with section="seneschal"/...') and states the tool's role boundary: 'A discovery layer, not a replacement for MCP — use it to FIND tools, then connect.' That is a clear when-to-use and when-not-to-use statement with an implied alternative (the real MCP servers).

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 openly states that settlement is not performed internally, describes the return value as an endpoint+body, and gives an amount range. It also implies the effect on ranking. This is strong transparency for a payment-adjacent 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, front-loaded with the core purpose, and every clause adds value. It avoids fluff and does not repeat schema details unnecessarily. This is excellent conciseness.

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

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

The description is complete enough for a tool with three fully documented parameters and no output schema. It explains the unusual x402 flow, states the amount range and permission model, and differentiates from siblings. Minor missing details like idempotency are not critical given the tool's simplicity.

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

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

Schema description coverage is 100% and each parameter already includes a clear description. The tool description adds little beyond repeating the amount range and USDC denomination, which are already present. It does not introduce new meaning beyond the schema, so the baseline score of 3 is appropriate.

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

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

The description opens with 'Rank a notice higher by attaching USDC', a specific verb+resource pair that clearly distinguishes this from sibling tools like board_post or board_read. It also clarifies the paid boost mechanism via x402, leaving no ambiguity about the tool's function.

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

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

The phrase 'Anyone can boost any notice' indicates broad applicability, and the note 'This tool does NOT settle payment itself' tells users they must complete payment via the returned endpoint. However, it does not explicitly name alternative tools (e.g., board_post for creating notices), so its guidance is clear but lacks explicit exclusions.

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

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

No annotations exist, so the description carries the burden of conveying that this is a safe, read-only operation. It states 'Reads are free,' which implies no cost and read-only behavior, but it does not explicitly confirm no side effects or mention rate limits or data freshness. The posting detail adds ecosystem context but is tangential to this tool's own behavior.

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

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

The description is three sentences, front-loaded with the core purpose. The board enumeration is useful, and the cost note is relevant. The posting sentence is slightly tangential but still adds ecosystem context without being verbose.

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

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

With no parameters and no output schema, the description sufficiently explains what the tool returns (board names and notice counts). It could mention the exact response format, but for a simple list this is adequate and actionable.

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 value by enumerating the actual board names, helping an agent know exactly what will be listed without needing schema information.

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

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

The description clearly states the tool lists public notice boards and their notice counts, names the specific boards, and differentiates it from siblings like board_read or board_post. The verb 'list' and resource 'public notice boards' are explicit and unambiguous.

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

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

The description clearly indicates this is an overview tool for discovering boards and counts, but does not explicitly say when not to use it or name alternatives like board_read for reading specific threads. The context is clear, but exclusions/alternatives are missing.

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

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

With no annotations, the description carries the full burden, and it does so admirably. It discloses that the tool returns an endpoint and body rather than posting directly, that the free tier is rate-limited per IP, that the response includes an ownerToken for editing/withdrawing, and that new notices start at the bottom. This is rich behavioral context beyond what the schema provides.

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 with high information density. It is front-loaded with the purpose ('Prepare a free notice') and then provides essential behavioral and output details without any 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?

Since there is no output schema, the description appropriately explains the key return values (ownerToken, boostEndpoint), the rate limit, and the ordering behavior. It covers the tool's behavior and output sufficiently for an agent to use it correctly, given the schema already documents all parameters.

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

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

The schema covers 100% of parameters with detailed descriptions, including an enum for board and max lengths for title/body. The description adds no parameter-specific meaning, so the baseline score of 3 is appropriate given the high 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 prepares a free notice and returns the REST endpoint and body to POST. This distinguishes it from sibling tools like seneschal_board_read, seneschal_board_list, and seneschal_board_reply, which focus on reading or replying, while seneschal_board_boost covers ranking. The scope (free tier, rate-limited) adds specificity.

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 this to prepare a free notice, with a rate-limit warning for the free tier. It also hints at an alternative by saying 'boost to rank up', which implicitly points to the boost tool, but it does not explicitly name an alternative 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 the behavioral burden. It discloses the ranking order (boosted first by decayed weight, then most recent) and the cost aspect ("Free to call"), which are valuable beyond the schema. However, it does not explicitly confirm read-only safety or mention side effects, though the verb "Return" suggests a non-mutating operation.

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

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

The description is two short sentences that front-load the core action and purpose. The parenthetical adds necessary detail about ranking without unnecessary words, and every element earns its place.

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

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

For a read tool with a simple schema, the description covers the primary behavior and return ordering. The lack of an output schema is partially mitigated by describing the output as "ranked notices." Minor gaps exist around pagination and error handling, but overall it is sufficiently complete for this tool type.

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 provides descriptive text for both parameters (board enum and limit), giving 100% coverage. The description adds no additional parameter-level meaning, so the baseline score of 3 is appropriate.

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

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

The description states a specific action ("Return") on a clear resource ("ranked notices on a board"), and the parenthetical on ranking ("boosted first by decayed weight, then most recent") further differentiates it from sibling tools like board_post or board_list. The title also reinforces readability ("read a board (FREE)").

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

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

The description implies usage for fetching board notices but does not explicitly contrast with siblings like seneschal_board_list or seneschal_board_post. It does not state when not to use it or mention alternative tools, so guidance is limited to the inferred reading purpose.

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 responsibility. It discloses key behaviors: the tool returns a REST endpoint and body to POST rather than directly posting, replies are free, title defaults to 'Re: <thread title>', and replies are never boosted. This gives the agent a thorough understanding of the tool's 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 four concise sentences, front-loaded with the primary action and return value. Every sentence adds useful 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?

With no output schema, the description correctly explains that the tool returns a REST endpoint and body. It covers cost, thread depth, default title, ranking behavior, and distinguishes from siblings. The 7-parameter schema is fully described, making the tool well-rounded for an agent.

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

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

Schema description coverage is 100%, so parameters are already well-documented. The description repeats the title default behavior but adds no new parameter-specific information. Baseline of 3 is appropriate since schema does the heavy lifting.

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: preparing a free reply to an existing notice, with specific context about thread depth. It distinguishes itself from sibling tools like seneschal_board_boost and seneschal_board_post by explicitly mentioning 'reply' vs 'boost'.

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

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

The description provides clear usage context, explaining that replies are free and never boosted, and directs users to boost the thread root for ranking. It implies when to use this tool (for replying) but does not explicitly contrast it with creating a new top-level post via board_post.

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

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

With no annotations, the description carries full burden and excels: it discloses non-custodial nature, exact return elements (coin amount, rate lock, wallet URI, pay page URL), the signed invoice_paid webhook, and the flat ~$0.02 fee debited from the watch credit meter. It also explains how amount tagging differs between Monero and Zcash.

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

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

The description is dense but every sentence contributes: purpose, endpoint/return payload, webhook/fee behavior, and authentication options. It is front-loaded with the core action and remains readable despite its length.

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

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

Despite having no output schema, the description adequately covers what the tool returns, how the payment flow works, what triggers the webhook, and what costs are incurred. It also explains the two authentication modes and where each is appropriate, making the tool fully actionable.

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 meaning beyond field names: it explains that amountUsdCents is converted at a locked rate, TTL locks the exchange rate, checkoutKey is a restricted client-safe key minted via POST /v1/checkout/keys, and that orderId is echoed on invoice, pay page, and webhooks.

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

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

The description opens with 'Accept an XMR/ZEC payment INTO YOUR OWN WALLET: creates a checkout invoice', using a specific verb and resource. It clearly distinguishes this creation tool from the sibling status/inquiry tools by naming the exact POST endpoint and the invoice-creation 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?

It gives clear context on when to use the tool ('Accept an XMR/ZEC payment...') and provides explicit guidance on authentication alternatives ('Use your watchId+watchToken server-side, or a restricted checkoutKey... anywhere you cannot keep secrets'). It does not explicitly say 'use checkout_invoice_status instead for status checks', but the create/status distinction is implicit from tool names.

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 states the state machine (pending → confirming → paid | underpaid | expired | cancelled) and that invoiceId acts as a capability with no token required. This covers core behavioral expectations, though it does not mention error handling or 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?

Two concise sentences, front-loaded with purpose, then state details and usage context. 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?

For a simple one-parameter status tool with no output schema, the description explains the full lifecycle and the auth model. It is complete enough for an agent to understand what to expect from the tool.

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

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

The schema already documents invoiceId, but the description adds that invoiceId is 'the capability' and no token is needed, giving important semantic meaning beyond the schema description.

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

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

The description clearly states the tool polls the state of a checkout invoice and lists the specific states. The verb 'poll' and resource 'checkout invoice status' are precise, distinguishing it from the sibling create tool.

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

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

The description gives clear context that a buyer agent can watch its own payment land, implying use after invoice creation. It notes that no token is needed, but does not explicitly name alternatives or exclusion cases, so a 4 is 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?

No annotations are provided, so the description must carry the behavioral burden. It implies a read-only lookup and describes the catalogue contents, but says nothing about data freshness (are the 'current' fees live or cached?), authorization needs, or whether any state is mutated — all reasonable questions for a fee-sensitive lookup.

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

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

Front-loads the resource before the use case and filter options, with no filler sentences. It is slightly wordy in the provider enumeration, but every clause adds 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?

With no output schema, the description usefully enumerates what each catalogue entry contains (fee, address, liquidity notes, caveats), which compensates for the missing return schema. An agent has enough to know what it will get back, though not the exact shape.

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 the schema already documents chain, max_fee_bps, and multi_asset. The description's 'filter by chain, max fee, or multi-asset support' merely restates the schema's filter dimensions without adding syntax, defaults, or interaction semantics, so the baseline 3 applies.

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

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

States a specific resource — a curated catalogue of Ethereum mainnet flash-loan providers — and enumerates the returned fields (fees in bps, addresses, liquidity notes, caveats). The purpose is unambiguous, though it never references or distinguishes itself from any sibling tool (none of which overlap in domain, so the omission is harmless).

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

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

Gives a clear use context: 'Helpful for agents picking the cheapest viable provider for an arbitrage or refinancing transaction.' It does not name when NOT to use it or point to any alternative, but no sibling competes for this task, so the omission is minor.

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

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

With no annotations, the description carries the full behavioral burden. It usefully discloses what the response reveals (liveness plus configured backends), which is an information-disclosure trait, but says nothing about auth requirements, cost, or that it is a side-effect-free read. Adequate but not rich.

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

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

A single front-loaded sentence with no filler. The core purpose and the payload contents are delivered immediately.

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?

There is no output schema, so the description must describe returns, and it does name the two main return components (liveness and configured backends). For a zero-parameter health endpoint this is nearly complete, though it omits response format details an agent might want.

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 takes zero parameters, so there is nothing to document and no schema semantics to add. Baseline 4 applies; no parameter-related gap exists.

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?

Names the resource (this server's service) and states exactly what is returned: liveness status plus which privacy-chain backends (Monero, Zcash) are configured. That is far more specific than a bare 'health check', and no sibling tool overlaps this function. It stops short of a 5 only because it does not need to, and does not, position itself against any sibling.

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

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

The description gives no when-to-use guidance, no indication of whether authentication is required, and no mention of alternatives or rate limits. The usage (call to verify the server is up and see backend configuration) must be inferred entirely from the name 'health'.

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 and does well: it discloses that the call is free, that it returns configuration metadata, and that actual payment occurs out-of-band via a direct HTTP request rather than through this tool. It doesn't cover freshness/caching of the price data, which is the only meaningful gap.

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

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

Three sentences, front-loaded with the returned fields before the usage guidance. Every sentence carries information; nothing is redundant.

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

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

Despite no output schema, the description enumerates the return fields (protocol, network, recipient, per-call price) and explains the downstream paid-request pattern with example endpoints and a docs link. Complete enough for an agent to use it correctly.

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

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

The tool takes zero parameters, so the baseline of 4 applies. There is nothing for the description to add or compensate for on the parameter front.

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

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

States a specific verb ('Returns') and a precisely enumerated resource ('protocol, network, recipient address, and per-call price for every gated endpoint on this backend'). This is a distinct domain no sibling tool covers, so the agent can place it immediately.

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 prescribes the workflow: 'consult this once to budget a paid session, then make the paid HTTP request directly against...' It tells the agent when to call, what to do afterward, and how the payment header is supplied. Nothing is left to inference.

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 behavioral burden and excels: it discloses the credit meter rates (20000 atomic USDC/day idle + 5000 per webhook), the $0.10 seed credit, HMAC-signed webhooks, the 'credit' block on every body, the one-time 'low_credit' warning, and AES-256-GCM encryption of view keys at rest.

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

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

The description is dense yet purposeful; each sentence adds a distinct operational fact: purpose, credit meter, paywall, webhook behavior, top-up endpoints, and encryption. It is front-loaded with the core purpose and contains no filler.

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

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

Given the tool's complexity (paid, credit-metered watch with webhook delivery), the description covers payment model, security, and related endpoints. However, it does not describe the response/return value, which is a minor gap since no output schema exists.

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

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

Schema coverage is 100% with detailed descriptions for all five parameters, so the baseline is 3. The description adds operational context (view-key encryption, webhook signing) but does not deepen the meaning of individual parameters beyond what the schema already provides.

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

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

The description opens with a specific action and resource: 'Subscribe a Monero or Zcash address to view-key-based payment monitoring.' This clearly distinguishes the tool from sibling tools like seneschal_private_watch_topup or seneschal_private_watch_info.

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 covers the prepaid credit meter, the $0.10 x402 paywall at creation, and mentions the top-up endpoints, helping the agent understand when creation is necessary. It does not explicitly name alternative creation tools like seneschal_private_watch_create_crypto, but the context is clear.

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

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

Because there are no annotations, the description carries the full burden and does a good job: it discloses the compound behavior (creates watch + returns quote), the grace credit activation, the automatic credit on payment confirmation, and the return value ('Returns the FREE endpoint + body to call'). This goes beyond the schema to explain the sequence of events. It stops short of discussing failure modes or permissions, but the core behavioral traits are clearly transmitted.

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 tight sentences, each delivering a distinct piece of information: purpose, activation/credit behavior, return value, and defaults. It is front-loaded with the main action and differentiator. There is no filler, and even the repetition of 'no USDC, no EVM wallet' reinforces the critical contrast. This is highly efficient.

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

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

For a complex tool with 7 parameters, no annotations, and no output schema, the description covers many non-obvious behaviors: the combined watch+quote flow, grace credit, automatic credit, defaults, and a pointer to external bounds. The phrase 'FREE endpoint' is slightly ambiguous (free of charge? no authentication?), and error conditions are unaddressed, but overall the description is largely complete for an agent to invoke correctly.

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

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

The schema has 100% coverage, so the baseline is 3. The description adds value by explaining the default for `payWith` ('pay in the coin you are watching') and the default for `amountUsdCents` ('buy the policy minimum of credit'), which are not obvious from the schema. It also directs the agent to `*_private_watch_info -> crypto_topup` for bounds, enriching parameter understanding.

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

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

The description states the exact action ('POST /v1/private/watch-crypto creates a Monero/Zcash payment watch AND returns a coin payment quote in one call') with a specific verb and resource. It immediately differentiates from the sibling tool `seneschal_private_watch_create` by explicitly saying 'no x402, no USDC, no EVM wallet anywhere in the flow.' The title reinforces this distinction, making the tool's purpose unmistakable.

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

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

The description positions this as 'The all-coin onboarding path' and implies when to use it by negating the EVM/USDC flow. It provides clear context about defaults ('pay in the coin you are watching, buy the policy minimum of credit') and points to `*_private_watch_info -> crypto_topup` for bounds. However, it does not explicitly name the alternative tool for USDC/EVM, so it's slightly below the 'explicit when/alternatives' bar.

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 key behaviors: the phrase transits the server (no logging/persistence), a network observer could see bytes, the tool is rate-limited, and the resulting UFVK is read-only. This goes beyond minimal disclosure and covers security implications.

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

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

The description is compact and well-structured: it starts with the action, then covers rate limit, security, alternative, and a note on the output type. Every sentence contributes meaningful information without redundancy.

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

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

Given the sensitive nature of the operation and lack of output schema, the description provides sufficient context: purpose, security implications, rate limit, alternative, and read-only nature of the result. It is complete for an agent to decide whether to invoke it and to understand the trade-offs.

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

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

Schema coverage is 100%, so the baseline is 3. The description repeats the 12/24-word phrase constraint already present in the schema and mentions the Zcash-only chain, but adds little semantic detail beyond the schema's parameter descriptions.

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

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

The description clearly states the tool's function with a specific verb and resource: it hands a BIP-39 mnemonic to a CLI and returns the matching UFVK. This is distinct from sibling tools focused on watch creation or info, and the title reinforces the purpose.

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

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

The description explicitly mentions the security trade-off and provides a safer alternative (deriving offline), giving clear when-to-use and when-not-to-use guidance. It also notes the rate limit, setting usage expectations.

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 burden of behavioral disclosure. It reveals key traits: the view key 'never touches our SQLite — it flows through to NFPT in memory only,' emphasizes the ephemeral one-off nature, and discloses the $0.50 per call pricing. It does not describe the response format or error behavior, but the essential behavioral traits are 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 three sentences, front-loaded with the core function, and each sentence adds useful context. However, the pricing details ('Paid via x402 at REST' in title and '$0.50 / call' in description) are somewhat redundant, preventing a perfect score.

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

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

For a read-only scan tool with no output schema and 6 parameters, the description effectively covers the main purpose, use case, privacy, and pricing. The schema descriptions for includeNotes and birthdayHeight fill in response details and scan boundaries. Minor gaps include lack of explicit mention of synchronous execution or authentication method (beyond 'paid via x402'), but overall it is sufficiently complete.

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

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

The input schema provides descriptions for all 6 parameters (100% coverage), including detailed context for viewKey, toHeight, includeNotes, and birthdayHeight. The description adds no extra parameter-level guidance, but this is acceptable given the schema's comprehensiveness, warranting the baseline score.

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

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

The description states 'Return all spendable + spent notes for a view key without setting up a watch,' which uses a specific verb and resource, and clearly distinguishes this one-off scan from the persistent watch tools (e.g., seneschal_private_watch_create). The title further clarifies it as a 'One-off historical scan'.

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

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

The description gives explicit guidance: 'Use this when you want to reconcile a wallet at a point in time.' It contrasts with watch setup ('without setting up a watch') but does not explicitly name the alternative sibling tools, so it slightly misses the highest benchmark.

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

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

No annotations are provided, so the description carries the burden of disclosing behavior. It discloses that the tool is a read operation ('Returns'), states return categories (price, chains, health, security notes), and adds the cost trait ('Free to call'). It does not mention authentication, rate limits, or failure modes, but for a zero-parameter metadata endpoint this is adequate.

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

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

The description is a single, front-loaded sentence that immediately states the action and resource, then lists the returned metadata and the cost note. No filler or redundancy, and every phrase 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?

With no output schema, the description compensates by enumerating the main returned categories: current price, supported chains, NFPT upstream health, and security notes. It lacks structural detail about the response format, but for a zero-input info service this gives an agent sufficient high-level understanding to decide whether to call it.

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

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

The input schema has no properties and schema description coverage is 100%, so there are no parameters to explain. Per the zero-parameter baseline, the description does not need to add parameter semantics; it appropriately focuses on return values.

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

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

The description uses a specific verb and resource: 'Returns the current price, supported chains, NFPT upstream health, and security notes for the view-key payment-monitoring service.' This explicitly states what the tool does and distinguishes it from sibling private_watch tools (create, derive, historical, topup) by focusing on service metadata.

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 about what data it returns and notes it is 'Free to call,' implying low-risk usage. However, it does not explicitly mention when to use this tool instead of sibling info tools like seneschal_health or zecmon_info, nor does it state exclusions or alternatives. Usage is implied but not directly addressed.

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

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

With no annotations, the description carries the full burden. It discloses a critical behavioral trait: 'This tool returns the URL the agent should POST to with its x402 client; it does NOT settle payment itself.' It also explains the tier-to-path mapping and credit rates. While it doesn't mention side effects or error handling, the key gotcha is well-covered.

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

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

The description is concise and efficiently front-loaded: it states the purpose first, then tiers/paths, then rates, then the critical note about not settling. Every sentence adds necessary information without redundancy. There is no fluff or padding.

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

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

For a tool with 3 params, no output schema, and no annotations, this description is quite complete. It explains the return value (a URL), the prerequisite (existing watch from create), and the payment mechanism. It lacks error handling or edge-case notes, but given the tool's simplicity, this is nearly sufficient.

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

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

Schema coverage is 100%, so baseline is 3. The description adds value by explaining the practical meaning of tiers ($0.10, $1.00, $5.00), the rates, and the REST paths, which go beyond the enum values and parameter descriptions. This enhances the agent's understanding of what each tier costs and how the top-up translates to usage.

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

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

The description clearly states the tool's purpose: 'Add prepaid credit to an existing Private Watch.' It uses a specific verb and resource, and the mention of x402 and REST distinguishes it from the crypto sibling. The title and description align to make the tool's function unmistakable.

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

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

The description gives clear context: it's for topping up via x402, and explicitly notes the tool does NOT settle payment itself. This implies when to use this tool versus the crypto counterpart, but it doesn't explicitly name alternatives or state when-not-to-use conditions. Thus, clear context with no explicit exclusions.

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

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

With no annotations provided, the description carries the full burden and does so richly: it discloses the quote mechanics (receiving address, exact coin amount, invoice tag/memo, locked USD rate), payment detection via a view-key scanner, that the tool never holds a spend key, and that no API key is required. This goes far beyond what a bare schema would convey.

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

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

The description is dense but efficient: three sentences cover purpose, the quote flow with endpoint paths, polling status, and unique payment-detection benefits. Every sentence contributes essential information for invocation, and the most important distinction (XMR/ZEC instead of USDC) is front-loaded.

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

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

Given the tool's complexity, the absence of an output schema, and the lack of annotations, the description is remarkably complete. It explains what the quote returns, the polling sequence, and the authentication header. However, it omits details on quote expiry, over/underpayment handling, and error states, which are relevant for a payment tool, so a perfect score is not warranted.

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

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

Schema coverage is 100% and each parameter already has a description, so the baseline is 3. The description adds extra meaning by linking `chain` to invoice tag vs. memo token behavior and clarifying that `amountUsdCents` is the credit amount tied to a quote, plus directing users to the info tool for min/max constraints. This exceeds baseline without being redundant.

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

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

The description opens with 'Fund a Private Watch by paying in XMR or ZEC instead of USDC,' giving a specific verb, resource, and payment method. This clearly distinguishes it from the sibling `seneschal_private_watch_topup` tool, which presumably handles USDC top-ups.

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 'instead of USDC' to frame when this crypto variant is appropriate, and provides a complete usage workflow: request a quote, send the payment, then poll the status endpoint until settled. It also mentions 'No x402, no API key' and points to the info tool for min/max limits, giving the agent clear operational 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 carries the full burden. It usefully discloses latency (<50ms), flat pricing ($0.001/call), and data provenance (Seneschal-operated full nodes). It says nothing about authentication requirements, rate limits, failure/availability behavior, or what happens when a chain is offline. Solid cost/perf disclosure, but the operational profile is incomplete.

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

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

Three dense, front-loaded sentences with zero filler; the core value proposition (one fact, fast, cheap) leads. The inline enumeration of question IDs partially duplicates the schema enum, costing a little redundancy, but it usefully groups them by chain.

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?

There is no output schema, but "answers ONE yes/no or one number" successfully conveys the return shape, and /v1/q is cited for input detail. Combined with the chain list and pricing, an agent has enough to call it correctly. Auth and error behavior remain unaddressed, but for a simple read-only fact endpoint this is nearly sufficient.

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

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

Schema description coverage is 100% and the params object already documents that cheapest-flashloan takes asset (+ optional chain) while other questions take none. The description's contribution is routing the agent to /v1/q for per-question input lists, which is a modest addition. Baseline 3 applies when the schema does the heavy lifting.

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 names a specific verb+resource: atomic single-fact query endpoints across Monero, Zcash, and Ethereum, and enumerates the question families (xmr/height, zec/pools, cheapest-flashloan, base-fee). An agent knows this is a cheap stat lookup, not a scan or subscription tool. It stops short of explicitly differentiating from close siblings like seneschal_zecmon_info or seneschal_flashloan_providers, so it is clear but not fully sibling-aware.

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?

"Designed for tight agent loops" and "Consult /v1/q for per-question input lists and live chain availability" imply the intended use, and sub-50ms/$0.001 hints at when the cost tradeoff is worthwhile. However it never states when to prefer this over seneschal_zecmon_scan or seneschal_flashloan_providers, nor any exclusion conditions. Usage is implied, not directed.

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 discloses that the tool is free to call, rate-limited (20 scan starts / 15 min shared across all agents), and provides status/limit information. It does not mention side effects (likely none), but for a read-only info tool, the transparency is strong. It does not contradict any annotations.

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

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

The description is compact and front-loaded with the core purpose. The additional sentences about rate limits and alternatives are valuable but include lengthy URLs that slightly reduce readability. Still, every sentence contributes meaningful context, and the structure is logical.

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 (0 params, no output schema), the description fully covers what an agent needs: purpose, usage context, rate limits, and alternatives. It even addresses cost (free) and shared rate limits. The description is complete enough for the agent to decide when and how to invoke this tool.

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

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

The tool has zero parameters, so the baseline is 4. The description adds no parameter-specific semantics, but that is unnecessary. It does clarify the scope of the info returned, which implicitly describes the output rather than input parameters.

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

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

The description clearly states the tool's function: providing live chain tip, scanner reachability, and free-tier limits for Zcash UFVK scanning. It distinguishes itself from siblings by explicitly positioning itself as the starting point before scanning and by pointing to alternative endpoints for other use cases. The verb 'start here' and the listed data make the purpose unmistakable.

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

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

The description gives explicit usage guidance: 'Start here before scanning' for quick checks of chain tip and limits. It also specifies when NOT to use it, directing users to private/historical for scheduled/bulk/latency-sensitive work or private/info for webhook-based notifications. This clears differentiates from sibling tools and alternative endpoints.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It reveals that the scan runs asynchronously ('Returns { jobId, jobToken } in milliseconds — the scan itself runs behind it'), that omitting birthdayHeight triggers a backward walk that is 'slower but always correct', and that the tool is 'FREE and rate-limited (20 scan starts / 15 min, shared across all agents)'. These are critical operational traits an agent must know.

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 return value, and each sentence adds essential context: async behavior, birthdayHeight nuance, rate limits, and alternatives. There is no fluff or repetition; the use of capitalization for 'BACKWARDS' and 'FREE' draws attention to key points.

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

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

Given there is no output schema, the description sufficiently explains the return shape and asynchronous workflow. It also covers rate limiting, polling, and when to use paid alternatives, making it complete for an agent to invoke the tool correctly. It points to the relevant sibling (scan_status) for follow-up, so the agent knows the full lifecycle.

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 the baseline is 3. The description adds meaning beyond the schema by clarifying the birthdayHeight trade-off: 'Omitting birthdayHeight makes the scanner walk BACKWARDS from the chain tip to find the wallet's first note, which is slower but always correct.' This helps the agent reason about the parameter without opening the schema. It doesn't repeat all parameter details, so 4 rather than 5.

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

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

The description opens with 'Open a scan of a Zcash UFVK' – a specific verb and resource that clearly distinguishes this from sibling tools like seneschal_zecmon_scan_status and seneschal_zecmon_scan_cancel. It also states the immediate return value, making the tool's core function unmistakable.

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

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

Explicitly tells when to use this tool vs alternatives: 'poll seneschal_zecmon_scan_status' for the result, and 'For anything scheduled, bulk or latency-sensitive use ... private/historical ... or private/info to get a webhook instead of polling at all.' It also warns about the shared rate limit, helping the agent decide if this is the right tool for the job.

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 disclosure burden. It transparently explains that the tool releases a scanner slot and that concurrency is finite, which is important behavioral context. It omits details like idempotency or error handling, but the core trait is disclosed.

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

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

The description is compact and front-loaded with the action. The final sentence 'Free.' is ambiguous and adds little value, but overall the structure is efficient.

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

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

The purpose is clear, but the lack of parameter documentation and output schema leaves the invocation under-specified. The agent doesn't know what values to pass or what to expect in response, making it incomplete for safe autonomous use.

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

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

Schema description coverage is 0%, and the description provides zero explanation of jobId or jobToken. The agent can only infer from names, with no guidance on how to obtain them or their format. This is a critical gap for a cancel operation.

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

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

The description clearly states the action ('Stop a running scan') and the resource ('a scan job'). It differentiates from sibling scan tools like zecmon_scan and zecmon_scan_status by focusing on cancellation and slot release.

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 an explicit when-to-use condition: 'Do this as soon as you stop caring about a scan' and explains the negative consequence of not acting. However, it doesn't explicitly mention alternatives or when not to use, so it falls short of a 5.

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

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

With no annotations provided, the description fully carries the behavioral disclosure burden. It discloses that notes accumulate and are returned partial, and it describes phase-specific response content (detecting-birthday vs scanning). This is rich, specific behavioral context beyond what annotations would typically provide.

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

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

The description is compact but dense, with each sentence adding meaningful information: purpose, partial notes behavior, phase-specific response details, polling rate, and cost. It is front-loaded with the primary purpose and avoids 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?

Without an output schema, the description does a good job explaining what the tool returns (phase, progress, notes) and how that varies by scan phase. It omits a precise response structure, but for a simple polling tool, the provided context is sufficient.

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

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

The schema already provides 100% coverage for all three parameters (jobId, jobToken, includeNotes) with useful descriptions. The tool description adds no additional parameter-specific semantics; it focuses on behavior and response content, so the score is the baseline for high 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 states 'Poll a scan opened by zecmon_scan' with a specific verb and resource. This clearly differentiates it from sibling tools zecmon_scan (which starts scans) and zecmon_scan_cancel (which cancels them).

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

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

It implicitly says to use after zecmon_scan, and explicitly provides a polling interval guideline ('Poll no faster than every 1.5s'). It does not explicitly list alternatives or when not to use it, but the context from siblings and the phrasing make the usage clear.

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