Seneschal Data

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

No annotations are provided, so the description carries full burden. It discloses the read-only discovery nature, format behavior (gopher vs json), pagination via cursor, and the live mirror aspect. It does not explicitly state 'no side effects', but the tool's purpose as a directory makes this clear. Adding an explicit read-only note would improve transparency.

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

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

The description is long but front-loaded with the core purpose and structured with lists and code-like examples. Some redundancy exists (e.g., section values repeated in schema), but the breadth of the tool justifies the length. Every sentence earns its place, though it could be trimmed slightly.

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

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

For a three-parameter tool with 100% schema coverage and no output schema, the description is exhaustive: all section options, formatting options, pagination semantics, and explicit examples. It even covers the JSON return shape. No gaps remain.

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 substantial value beyond it. It provides concrete example sections ('winbit32/actions'), lists all available section values, explains cursor usage for registry pagination, and clarifies the difference between gopher and json outputs. This far exceeds 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 explicitly identifies the tool as a 'discovery index' and 'LIVE mirror of the official MCP registry', with a clear verb ('browse', 'drill-down') and resource. It distinguishes itself from sibling tools (board, checkout, etc.) by positioning itself as a directory to find tools rather than a transactional service.

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 explicit usage instructions: 'Start with section="root"', then drill down with specific section patterns, and warns 'not a replacement for MCP — use it to FIND tools, then connect.' This gives clear when-to-use and an exclusion, differentiating it from direct tool invocations.

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 the burden of behavioral disclosure. It transparently notes the 60-second cache and explains data comes from Seneschal's shadow recorder, which conveys read-only observational behavior. It could further clarify output ordering or exact share format, but the provided traits are valuable.

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 tight sentences that front-load the core purpose and add a critical behavioral note about caching. Every word contributes value, with no filler or repetition of schema 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?

Despite having no output schema, the description conveys the key result fields (share and MEV per builder) and the window context. It could explicitly state that results are sorted/ranked by share or limit behavior, but given the parameter schema already covers defaults and enums, the description is sufficiently complete for a read-only leaderboard 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%, with both limit and window parameters already described in the schema. The tool description adds minimal context (the word 'window' aligns with the parameter) but does not supplement parameter semantics beyond what the schema provides, so the baseline of 3 applies.

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

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

The description clearly specifies a resource (Ethereum mainnet block builders) and the exact metrics provided (slot-by-slot ground-truth share and total MEV captured). It distinguishes this tool from siblings by highlighting Seneschal's shadow recorder and the window scope, making it unique among builder-related tools.

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

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

The description implies when to use the tool (to get authoritative builder share data over a window) but does not explicitly state alternatives or exclusions. The caching note suggests data is not real-time, but no sibling tools are mentioned for comparison.

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?

With no annotations provided, the description carries the full burden and does well: it discloses that the tool flags specific risk types, returns counts/teaser in summary, full feed in detail, supports address lookup, mentions the premium payment route, and advises 'Verify on-chain before acting.' This gives a clear behavioral picture beyond the schema.

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 information-dense and well-structured, starting with purpose, then enumerating risk categories, then view semantics. The colorful examples (JaredFromSubway, Salmonella-style) add flavor but are not essential, making it slightly longer than pure functionality would require. Every other sentence serves a purpose.

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

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

Given the tool's complexity (5 parameters, no output schema), the description covers the main return values (summary counts/score distribution/teaser, detail feed, address lookup) and mentions the 'uncapped' feed and 'auditable flag factors.' The slight mismatch between 'full uncapped feed' and the schema's limit cap (1..500) creates minor ambiguity, 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 100%, so baseline is 3; the description adds value by explaining the semantic difference between 'summary' and 'detail' views and that passing an 'address' returns a single-address lookup. It does not elaborate on 'limit', 'category', or 'min_score', but schema already describes those adequately.

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

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

The description clearly states the tool provides defensive intel for MEV searchers and bot operators, and enumerates three specific risk categories it flags (malicious spenders, honeypot tokens, dangling approvals). It distinguishes itself from sibling tools through its unique MEV/approval-risk focus and explicit verbiage like 'Flags' and 'risk-scored with auditable flag factors.'

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 on target users (MEV searchers and bot operators) and explains the different views (summary vs detail) and address lookup, but does not explicitly mention when not to use the tool or alternatives. It does note the paid x402 endpoint and advises verifying on-chain, which helps set 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?

No annotations are provided, so the description must carry the burden. It does add context that the catalogue is 'curated' and 'editorially open', implying a maintained, possibly incomplete list. However, it doesn't mention data freshness, pagination, or that it's a read-only operation, leaving some gaps in behavioral disclosure.

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

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

The description is dense but efficient, with two sentences covering purpose, contents, use case, and filtering. The first sentence is long but every clause adds detail. The second and third sentences are purposeful, though the filtering sentence partially repeats schema info. No fluff, but not as crisp as a two-sentence minimalist example.

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

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

For a simple catalogue query with no output schema, the description adequately explains what results will contain (fee, addresses, liquidity notes, caveats) and the intended use case. It doesn't mention return format or error conditions, but that's likely unnecessary for a read-only filterable catalogue. Complete enough for an agent to select and invoke correctly.

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

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

Schema coverage is 100%, so baseline is 3. The description reinforces filtering by chain, max fee, or multi-asset support, but it doesn't add meaning beyond what the schema already explains (e.g., max_fee_bps drops providers exceeding the threshold). Description adds no new semantic detail.

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

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

The description clearly states the tool provides a curated catalogue of specific flash-loan providers (Aave V3, Balancer V2, etc.) with detailed attributes like fees and addresses. It identifies the resource and scope (Ethereum mainnet), distinguishing it from sibling tools that handle agents, borrowers, or health data.

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

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

It gives explicit context: 'Helpful for searcher agents picking the cheapest viable provider for a liquidation or arbitrage strategy.' This tells the agent when to use it, though it does not mention exclusions or alternative tools. Lacks explicit 'when-not-to-use' guidance, so not 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 carries the full burden of behavioral disclosure. It states that the tool returns the 'latest known state,' implying a read-only snapshot, but does not elaborate on data freshness, error handling, or potential rate limits. The 'Returns' wording suggests a safe read operation, but additional context would improve transparency.

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

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

The description is composed of two sentences, both front-loaded with critical information: what the tool returns and how to format the input. There is no redundant wording, and every sentence contributes 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 single-parameter read tool with no output schema, the description is sufficiently complete: it specifies the protocols covered, the exact input format, and the nature of the return (latest known state). It does not describe response structure, but the tool's simplicity makes this acceptable.

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

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

The schema provides only a pattern for the 'address' parameter with 0% description coverage, so the description must compensate. It explicitly explains that the value should be an EOA or contract address formatted as a 0x-prefixed 20-byte hex string, adding meaning beyond the schema's technical pattern.

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 the specific verb 'Returns' and identifies the resource: the latest known state of a given address across all supported protocols (Aave, Morpho, Spark). It clearly differentiates from siblings such as seneschal_get_borrower_history (historical data) and seneschal_list_borrowers (multiple borrowers) by focusing on a single address's current snapshot.

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

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

The description clearly implies when to use this tool: to get a current snapshot for a specific address across all protocols. It does not explicitly mention alternatives or exclusions (e.g., 'for history, use get_borrower_history'), but the context is unambiguous and sufficient for an agent to select it appropriately.

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

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

Description adds key behavioral info: output is a time series tuple, granularity defaults to raw, and hour/day are chart-friendly. However, with no annotations, it does not disclose limit/pagination behavior, ordering, or handling of missing data, leaving some burden unmet.

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

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

Two sentences, front-loaded with the core output contract, no filler. The granularity guidance earns its place by adding actionable usage detail.

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

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

No output schema exists, but the description explicitly defines the return tuple and granularity behavior, covering main usage. Schema covers time range and limit defaults; residual gaps like ordering or error behavior are minor for this read-only history tool.

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

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

Schema covers 5 of 6 parameters with descriptions/defaults, so baseline is 3. The description adds meaning beyond schema by clarifying the semantic purpose of granularity ('chart-friendly buckets') and confirming address/protocol scoping, justifying a 4.

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

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

Description opens with 'Returns a time series of (timestamp, health_factor, collateral_usd, debt_usd) observations for `address` on `protocol`', providing a specific verb and resource. It clearly differentiates from sibling tools like `get_borrower` by emphasizing historical time-series data rather than current state.

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

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

The description provides clear context for use: it returns historical observations and explicitly advises using `hour` or `day` granularity for chart-friendly buckets. It does not name alternative tools or exclusions, but the context is sufficiently clear.

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

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

No annotations are provided, so the description bears the burden. It clearly states the tool is read-only by saying 'Returns' and details the data included, with no mutation side effects. It lacks caveats about performance or failure modes, but the simple 0-parameter interface minimizes risk.

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, 10 words, front-loads the verb and output. No redundant phrases 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?

For a 0-parameter health check, the description adequately covers purpose and output. However, it doesn't define the response format or units for table sizes, which could be relevant since no output schema exists. Still, the tool is simple enough for an agent to use with confidence.

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

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

The input schema has zero properties, so there is no parameter semantics to clarify. Baseline 4 applies; the description adds no parameter details because none are needed.

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

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

Description uses specific verb 'Returns' and identifies exact resource: table sizes and data-source freshness timestamps for the Seneschal Data backend. This clearly differentiates from sibling tools which target domains like borrowers, boards, or ZEC monitoring.

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

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

Context is clear: this tool is for inspecting backend health metrics. It does not explicitly state when to use it over alternatives, but no sibling tool serves a similar purpose, so the lack of exclusions is acceptable.

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 provides useful behavioral details: it is a 'current snapshot,' results are 'sorted ascending,' and filtering is by health factor below max_hf. However, it omits compound from the protocol list even though the schema includes it, and it does not address output shape or rate limits, which is a noticeable 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?

Two sentences, no filler, key information front-loaded. Every clause contributes: scope, filter criterion, sort order, and a practical parameter tip.

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 list tool with four optional parameters and no output schema, the description covers the essential semantics and sorting behavior. It is slightly incomplete because it fails to mention the 'compound' protocol option from the schema, but overall the 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?

Schema coverage is 100%, so the schema already documents all four parameters. The description adds semantic value by explaining max_hf as the health-factor ceiling and min_debt_usd as a way to 'ignore dust positions,' which is more than the schema alone 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 ('Current snapshot ... whose health factor sits below `max_hf`') and identifies the resource (borrowers across Aave, Morpho, and Spark). It clearly differentiates from sibling tools like seneschal_list_borrowers by focusing on at-risk status and health-factor 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?

The description implies when to use the tool (when an at-risk borrower snapshot is needed) and gives parameter advice about min_debt_usd, but it does not explicitly state when not to use it or mention alternatives such as seneschal_list_borrowers or seneschal_get_borrower.

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 of disclosing behavioral traits. It mentions 'borrower snapshot table' and 'offset-based pagination,' but it does not explicitly state that the operation is read-only, what data is returned, whether it includes all protocols by default, or if there are any rate limits or side effects. This is a significant gap for a tool with no annotation safety hints.

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 long, with the first sentence front-loading the core purpose ('Generic discovery surface'). The second sentence efficiently lists differentiators from the sibling tool, and the third gives a concrete use case. There is no filler or redundant wording.

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 and no annotations, so the description must provide context about return values and behavior. It covers the tool's purpose and main features, but it does not mention what fields are returned, whether the snapshot is current or historical, or how protocols are handled by default. For a 9-parameter tool with no output schema, this is acceptable but leaves notable 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?

The input schema provides 100% coverage with descriptions for all 9 parameters, so the baseline is 3. The description summarizes key parameter groups (HF bounds, max-debt cap, sort field/direction, pagination) but does not add meaning beyond what is already in the schema. It is neither redundant nor compensatory; it simply restates the parameter categories.

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 identifies the tool as listing borrowers, calling it a 'generic discovery surface' over the borrower snapshot table. It explicitly distinguishes itself from the sibling tool `seneschal_list_at_risk_borrowers` by mentioning the additional filter bounds, sort options, and pagination, making its purpose unambiguous.

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

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

The description explicitly says 'Use this to walk the catalogue without knowing borrower addresses in advance,' which provides a clear use case. It also contrasts with the at-risk variant by noting the extra capabilities, implying when the generic version is appropriate. It does not explicitly mention when NOT to use it or name other alternatives like `seneschal_get_borrower`, but the intended context is evident.

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 of disclosure. It states 'Free to call' and details the output fields, implying a read-only informational tool. However, it doesn't explicitly mention side-effect-free or authentication requirements, though the free-to-call note covers the main cost concern.

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 return data, followed by actionable usage instructions and a docs link. Every sentence adds value, with no redundancy or wasted words.

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

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

Given the absence of an output schema, the description compensates by listing the returned fields (protocol, network, recipient, price) and providing practical next steps for making paid requests. It also links to external documentation, making it complete for the tool's simple purpose.

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

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

The tool has zero parameters, and the schema is an empty object. Per the baseline for 0 params, this is a 4. The description appropriately adds no parameter details since none exist.

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

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

The description clearly states it returns protocol, network, recipient address, and per-call price for every gated endpoint. This is a specific verb+resource and distinguishes it from sibling tools that provide actual data or other 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?

It explicitly says Agents should consult this once to budget a paid session, then make the paid HTTP request directly. This provides clear when-to-use guidance and directs the agent to an alternative action, making the usage workflow unambiguous.

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

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

With no annotations, the description carries the full burden and does well: it discloses the data provenance, full-slot coverage, and the x402 paywall/auth requirement. It stops short of mentioning response size, ordering, or failure behavior, but the main safety and access 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 two well-structured sentences: the first front-loads the output, the second adds provenance and access context. There is no filler or redundant restatement of the title.

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 absence of an output schema, the description does a good job describing the returned statistics and histogram. It is slightly incomplete in not specifying the response shape/ordering or whether the histogram is per-builder or aggregate, but for a read-only analytics tool with two simple parameters, it is largely 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 input schema already describes both parameters (limit and window_ms) with defaults and clamping, so the description adds little parameter-specific value beyond mentioning a 'configurable window.' With 100% schema coverage, baseline 3 is appropriate.

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

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

The description clearly identifies the resource: per-builder bid distribution with specific percentiles and a 24-element hourly slot histogram over a configurable window. It also differentiates from siblings by noting the shadow-recorder source and full slot coverage, though it does not explicitly name an alternative 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: this is a premium/paid tool requiring authentication, and the shadow-recorder source implies use cases needing complete slot coverage rather than just landed blocks. However, it does not explicitly state when to prefer this over sibling tools like builder_leaderboard or when not to use it.

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

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

With no annotations, the description carries the full burden. It discloses the key behavioral trait: the x402 paywall gating — free agents see a stub, paying agents fetch the full feed from the given URL. It also mentions the included data fields. There is no contradiction with annotations (none exist). It could add failure modes or rate limits but the essential gating behavior is well covered.

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

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

The description is two sentences and packs in the purpose, data content, paywall behavior, URL, and a usage pointer. It is efficient and front-loaded, though slightly dense with URLs and enumerated lists. Every sentence serves a purpose, meriting a 4 rather than a 5 due to mild complexity.

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 paywalled read-only feed with 4 parameters and no output schema, the description provides substantial context: what the feed contains, how the paywall works, and where to get payment details. It lacks explicit return-shape or error handling details, but given no output schema, the description does enough to set agent expectations.

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%, with all 4 parameters (limit, since_ms, min_debt_usd, liquidation_bonus) already described in the schema. The description adds minimal extra meaning beyond a subtle reference to the 7d lookback (matching since_ms default). Per the baseline rule, a 3 is appropriate 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 clearly identifies this as a premium feed of top at-risk borrowers from Aave, Morpho, and Spark, annotated with 7d market intel (liquidators, win rate, attempt outcomes) and ranked by expected liquidation value. It distinguishes itself from siblings like seneschal_list_at_risk_borrowers and seneschal_recent_liquidations by emphasizing the premium/paywalled nature and the ranking/intel content.

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 explicit guidance to use seneschal_paywall_info before opening a session, which is a clear pre-requisite. It also explains the paywall flow (free vs paying agents), implying this tool is for premium needs, though it does not explicitly compare against alternative free feeds.

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 excels. It discloses custody (only signed bytes leave the machine), the irreversibility of any change breaking the signature, the private builder set (Flashbots, Titan, rbuilder), the explicit 'NEVER the public mempool' behavior, and the free inspect vs paid relay distinction. 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 a single dense paragraph but every sentence contributes information. It front-loads the main purpose and then elaborates on views, custody, and payment. While not overly verbose, the structure could benefit from brief separation of concepts; still, it is appropriately detailed for the tool's complexity.

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

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

The tool has no output schema and no annotations, so the description must cover inputs, behaviors, and return semantics. It explains the view outputs (builder set, price, caveats; decoded tx preview), the custody model, the builders used, and even the payment endpoint. The only minor gap is a precise description of the paid relay's response payload, but overall the provided context is sufficient for an agent to use the tool correctly.

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

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

Schema coverage is 100%, but the description adds meaningful context for both parameters. It explains that view='info' is the default and what it returns, and that view='inspect' requires raw_tx to decode/validate and preview builders without relaying. This goes beyond the schema's terse property descriptions, clarifying usage semantics.

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 'Front-run protection for any sensitive tx' and enumerates specific use cases (puzzle/CTF/bounty claim, large approval revoke, first-touch interaction, NFT mint). It clearly states the resource (private transaction relay) and the verb (submit a signed raw transaction), distinguishing it from sibling tools dealing with boards, checkouts, and watchers.

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?

Explicit when-to-use guidance is provided via the enumerated sensitive transaction types and the instruction to submit a locally-signed raw transaction. It also explains the two views (info vs inspect) and when each is appropriate (free inspection before paying). However, it does not explicitly mention alternatives for non-sensitive transactions or directly contrast with any sibling tool, so it stops short of a 5.

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

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

With no annotations, the description carries 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?

The description discloses the analysis methodology (verified-source payout-path analysis + bytecode value-exit scan), the paid nature of the detail view (via x402), and a heuristic caveat ('verify on-chain before acting'). Since no annotations are provided, the description fully compensates with rich behavioral context.

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

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

The description is dense but well-structured: it front-loads the main purpose, then covers categories, methodology, views, pricing, and caveat. Every sentence adds value, though it is longer than the minimal needed. No wasted words 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?

Despite having no output schema and no annotations, the description provides sufficient context for invocation: it describes what summary and detail views return (counts + rollups + teaser vs full watchlist), mentions payment requirements for detail, and includes a caveat. It could be more explicit about the exact return structure, but it is adequate for typical 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 coverage is 100%, so the baseline is 3. The description adds meaning beyond the schema by explaining the classification semantics (e.g., what frontrun_bait means), clarifying the view parameter's behavior, and detailing the address override for single-contract verdicts. This goes beyond mere schema repetition.

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 specifically identifies the tool's purpose: classifying puzzle/CTF/bounty contracts into distinct risk categories (locked_no_payout, frontrun_bait, etc.) with concrete definitions. It clearly differentiates itself from sibling tools by focusing on this niche domain and mentions a single-contract verdict mode.

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

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

Provides clear context for when to use the tool (for puzzle/bounty contracts needing risk classification) and explains the available views (summary/detail) and single-contract override. However, it doesn't explicitly name alternative tools or state when not to use this tool, leaving the guidance slightly incomplete.

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 transparency burden. It discloses behavioral traits such as sub-50ms latency, flat pricing per call, data sources (SQLite + shadow-blocks recorder, Seneschal-operated full nodes), and the fact that each call returns exactly one fact. It also directs to /v1/q for live availability, though it does not mention side effects, rate limits, or error 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 front-loaded with a compact purpose statement, then efficiently lays out the two families and enumerates all 21 question names in a structured way. It is somewhat long, but every sentence contributes value, and the use of parentheses and semicolons keeps it scannable. The pointer to /v1/q avoids further bloat.

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 enum param and an open params object) and no output schema, the description provides a solid mental model: returns one yes/no or number, has two families with listed questions, and defers to /v1/q for exact inputs and availability. It stops short of detailing per-question outputs or error conditions, but that is reasonable for a lightweight fact lookup tool.

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

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

Schema coverage is 100% with descriptions for both params, so baseline is 3. The description adds meaningful layers: it categorizes the `question` enum into DeFi vs privacy chains, notes that privacy-chain questions take no params, and explains the provenance of the facts. It also points to /v1/q for per-question input lists, which is helpful given the `params` object is loosely typed.

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 'Atomic single-fact endpoints designed for tight agent loops' and explicitly states each returns one yes/no or one number. It also enumerates the two families (DeFi and privacy-chain) with a complete list of question names, making the tool's purpose and scope unmistakable and clearly distinguishing it from broader sibling tools like seneschal_stats_overview.

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

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

The description gives strong contextual guidance: 'designed for tight agent loops' and mentions sub-50ms latency and flat $0.001/call, indicating when this tool is appropriate. It does not explicitly name alternative tools or state when not to use it, but the 'atomic single-fact' framing implies that for richer or multi-fact data, one would use the more specialized sibling 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 full burden. It discloses useful behavioral details (both outcome categories, sorting by timestamp descending), but omits read-only status, default time window (since_ms defaults to now−24h), limit default, or pagination 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?

One focused sentence front-loads the subject ('Liquidations observed in the recent past') and packs key details without filler. 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?

For a simple list tool with fully documented parameters, the description plus schema is adequate. However, without an output schema or annotations, it would benefit from stating the response shape, default time range, and read-only nature to make it fully self-contained.

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 covers all three parameters with descriptions (limit, protocol, since_ms), so baseline is 3. The description adds context about result outcome categories but does not elaborate on parameter format or constraints 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 identifies the resource (recent liquidations) and distinguishes two included outcome categories, though it lacks an explicit verb like 'list' or 'returns.' It is specific enough to separate from sibling tools, none of which cover liquidations directly.

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

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

Usage is implied: if you need to see recently observed liquidations, this is the tool. However, it provides no explicit guidance on when to prefer it over alternatives like seneschal_list_at_risk_borrowers or seneschal_list_borrowers, nor any 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 are provided, so the description carries the burden. It discloses that this is an 'Aggregate snapshot' and that a single call returns all dashboard data, which implies a read-only, comprehensive behavior. It does not detail potential caveats like data freshness, but the description still communicates the essential behavioral trait of being a one-call bulk retrieval.

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, information-dense sentence that front-loads the core purpose ('Aggregate snapshot powering the public stats dashboard') and then enumerates the specific data points without unnecessary fluff. Every phrase adds value and it is not overly long.

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

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

Given no output schema, the description fully explains what is returned, listing all seven categories of data. It also states the single-call behavior. For a zero-parameter tool with no annotations, this is sufficient contextual completeness for an agent to select and invoke 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 has zero parameters, and the baseline for a 0-param tool is 4. The description adds no parameter information (none needed), but it does clarify the scope of the data returned, which is the only relevant semantic for this stateless snapshot tool.

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

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

The description clearly identifies a concrete aggregate snapshot tool with a specific name and scope, listing the exact contents (e.g., 'total positions tracked', 'top-10 at-risk borrowers'). It differentiates from siblings by presenting itself as the all-in-one dashboard data source, unlike granular tools like seneschal_recent_liquidations.

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 context ('powering the public stats dashboard', 'One call returns everything needed to render the dashboard') but does not explicitly name alternatives or state when NOT to use it compared to granular sibling tools. Thus it provides implied usage guidance rather than 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 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.