Seneschal

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 tool's discovery-layer nature (non-mutating), describes the two output formats (gopher/json), explains pagination via cursor, and notes it's free. It stops short of covering error handling, rate limits, or invalid-section behavior, but for a read-only directory the essential behavioral traits are all addressed.

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

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

The description is long but well-structured: it opens with the core purpose, then gives drill-down instructions, format options, and finally the ecosystem role. It is dense with examples and every sentence contributes value, though it could be slightly tightened without losing clarity. A 4 reflects that it's well-organized but on the verbose side.

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 directory tool with 3 optional parameters and no output schema, the description is remarkably complete. It explains the menu hierarchy, specifics of each project, how to navigate sections, the meaning of gopher vs json output, pagination, and the free/non-replacement caveat. An agent has everything needed to invoke the tool correctly and interpret the response.

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 all three parameters with 100% coverage, so baseline is 3. The description adds substantial extra meaning by showing the hierarchy ('<site>/actions', 'seneschal/<service>'), explicitly listing valid section values, and explaining how cursor relates to the 'More servers' entry. This goes beyond the schema's simple property 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 is a 'Terse, drill-down discovery index' of the ecosystem plus a live mirror of the MCP registry, with a specific verb (discover/check) and resource (directory). It distinguishes itself from sibling tools like seneschal_board_post or seneschal_private_watch_create, which are operational actions, making 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?

Extensive usage guidance is provided: start with section='root', drill into projects with section='seneschal' etc., use the '<site>/actions' pattern, use cursor for registry paging, and choose format. It also explicitly frames when to use it: 'A discovery layer, not a replacement for MCP — use it to FIND tools, then connect,' giving clear context and 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, the description carries the full disclosure burden. It explicitly states that the tool returns 'the REST endpoint + body for your x402 client to settle,' reveals it 'does NOT settle payment itself,' and confirms universal access. These are critical non-obvious behaviors that prevent misuse.

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 a distinct purpose: outcome, return value, and payment caveat. It is front-loaded and free of redundant information.

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

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

There is no output schema, so the description must explain the return value, which it does by stating it returns an endpoint + body for settlement. The payment flow, amount range, and access control are all covered, making the tool fully understandable for a three-parameter operation.

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

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

All three parameters have schema descriptions (100% coverage), so the baseline is 3. The description repeats the amount range already in the schema but adds no new parameter-specific meaning, meriting no extra credit.

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

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

The description opens with a specific verb and resource: 'Rank a notice higher by attaching USDC,' which clearly identifies the tool's function. It further clarifies that it returns a REST endpoint and body for x402 settlement, distinguishing it from sibling tools like board_read, board_post, and board_reply.

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 context by stating 'Anyone can boost any notice' and 'This tool does NOT settle payment itself,' giving a clear workflow boundary. However, it does not explicitly name alternative tools or when-not-to-use scenarios, missing the highest level of guidance.

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

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

With no annotations, the description carries the burden of disclosure. It states that reads are free, which is a useful cost-related behavior. It also clarifies that these are public boards. However, it doesn't describe the return format or potential errors, but for a straightforward list operation, this is adequate. The extra posting/boost info is tangential but not contradictory.

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 first sentence is concise and informative, and the board list is useful. However, the sentence about posting and attaching USDC is irrelevant to the listing tool and could have been omitted. The description could be tighter without losing meaning.

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

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

For a zero-parameter list tool, the description covers what it lists, the exact boards, and that reads are free. Without an output schema, this is sufficient. Some details on ordering or pagination would be nice but are not critical. The posting context adds some overlap with sibling tools but doesn't create 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 tool has zero parameters, so schema coverage is complete. The description adds value by explaining what the output contains (board names and notice counts), which helps the agent interpret the result. The baseline for no parameters is 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?

The description clearly identifies the action 'List' and the resource 'public notice boards', and specifies the output (how many notices each holds). It also enumerates the specific boards, distinguishing it from sibling tools like board_read or board_post.

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 title and description make it obvious that this is for listing an overview of boards. It mentions 'Reads are free', which encourages use, but it doesn't explicitly provide alternatives or exclusions. Still, for a simple list tool, the use case is clear.

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

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

With no annotations, the description carries the full burden and does well by disclosing rate limiting per IP, the return of an ownerToken for later edits/withdrawals, a boostEndpoint, and ranking behavior. It could add more about response structure or authentication requirements, but the key behavioral traits are covered.

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

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

The description is three sentences, front-loaded with the primary purpose, and every sentence adds value: what it does, rate limit, response tokens, and ranking behavior. No wasted words.

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

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

With no output schema, the description explains the key return values (REST endpoint, body to POST, ownerToken, boostEndpoint) and constraints (rate limiting, bottom placement). It is sufficient for basic usage, though it leaves some ambiguity about the exact execution flow (e.g., whether the tool itself makes the POST or the caller must do 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 covers all 7 parameters with descriptions, so the baseline is 3. The description does not add much parameter-specific meaning beyond schema, though it mentions the returned body/endpoint and ownerToken which indirectly relate to how parameters are used.

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 ('Prepare') and resource ('free notice') and explicitly states it returns the REST endpoint and body to POST. This distinguishes it from siblings like board_list, board_read, board_reply, and board_boost by clarifying that it is a preparation step rather than a direct posting or reading operation.

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: it prepares a free notice for posting, and notes that new notices start at the bottom and can be boosted to rank up. This implies when to use this tool versus board_boost, but it does not explicitly mention alternatives like board_list or board_read for viewing notices.

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

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

No annotations are provided, so the description carries the full burden. It discloses the ranking order ('boosted first by decayed weight, then most recent') and that it is free. However, it does not mention potential pagination, rate limits, or the exact structure of returned notices, which would be 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 sentences long, front-loaded with the primary action, and every clause adds value: what it returns, how results are ordered, and cost. No unnecessary 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?

With no output schema, the description should clarify what a 'notice' includes, but it only says 'ranked notices' without field details. It explains the ordering and free usage, but an agent might not know the shape of the response, making it less complete for a no-output-schema tool.

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

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

The input schema covers 100% of parameters with descriptions ('Which board to read', 'Max notices (default 50)'). The tool description does not add syntax details beyond the schema, so it stays at the baseline 3.

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: 'Return the ranked notices on a board'. It specifies the resource (notices on a board) and the action (return), and distinguishes it from siblings like board_post and board_boost by focusing on reading.

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

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

The description implies usage for reading a board's notices rather than posting or boosting, but it does not explicitly state when to use this over alternatives. The phrase 'Free to call' provides some cost context, but no direct comparison to sibling tools is given.

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

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

With no annotations, the description carries full burden. It discloses key behaviors: the tool 'prepares' rather than executes ('Returns the REST endpoint + body to POST'), enforces one-level-deep threading, defaults the title to 'Re: <thread title>', and clarifies that replies are free and never boosted. This is exceptionally 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?

Four short sentences, front-loaded with the main purpose. Each sentence adds value: core behavior (prepares endpoint), default behavior (title), and policy (free/never boosted). No filler or redundant content.

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

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

The description covers purpose, threading behavior, return value, title default, and cost/ranking policy. Given the rich schema descriptions and no output schema, this is sufficient, though it could more explicitly mention prerequisites like needing a valid board and id from board_read.

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% parameter descriptions, so the baseline is 3. The description adds minimal additional meaning beyond the schema, such as the title default and thread depth, but the schema already covers most parameter 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 clearly states the action and resource: 'Prepare a free reply to an existing notice' with the parenthetical clarifying thread behavior ('starts/continues a thread, one level deep'). This distinguishes it from sibling tools like seneschal_board_post (new notice), seneschal_board_read, and seneschal_board_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?

It implies when to use this tool (replying to an existing notice) and provides an explicit alternative for ranking: 'Replies are free and never boosted; boost the thread root to rank the conversation.' It does not explicitly mention board_post for new notices, but the context makes the reply-vs-post distinction clear.

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

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

With no annotations, the description carries the burden of behavioral disclosure. It adds a valuable caching detail ('Cached for 60s'), and specifies the data is 'ground-truth' from a shadow recorder, conveying accuracy and observational context. It doesn't mention rate limits or detailed response behavior, but the caching and data-source notes go 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 a single sentence with no superfluous words. It packs in the key aspects (share, MEV, window, source) efficiently, but misses an imperative verb which would make it more direct. Still, it's concise and well-structured.

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

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

Even with no output schema and no annotations, the description explains the core returned content (share and MEV captured), the source, and caching. It doesn't explicitly state ordering or pagination behavior, but 'leaderboard' and the top-N limit parameter imply ordering. This is sufficient for the tool's simplicity.

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

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

Schema coverage is 100%, so the baseline is 3. Both parameters (limit, window) already have descriptions and the window has an enum. The description doesn't add parameter-specific meaning beyond the schema, though 'in the window' loosely aligns with the window parameter.

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

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

The description clearly identifies a leaderboard of Ethereum mainnet block builders with specific metrics: slot-by-slot ground-truth share and total MEV captured per builder. It names the resource and source, but lacks an explicit verb like 'Get' or 'List' and does not explicitly distinguish from the sibling tool 'seneschal_premium_builder_stats'.

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

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

No guidance is provided about when to use this tool versus alternatives such as seneschal_premium_builder_stats or other MEV-related tools. The description only states what the tool returns, leaving use cases and exclusions unspecified.

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 excels: it discloses the non-custodial structure, a 'flat settlement fee (~$0.02)... never a percentage,' the locked rate for TTL, the invoice_paid webhook, and the hosted pay page. This goes far beyond a basic 'create' and sets clear expectations.

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 long single paragraph but front-loaded with the core purpose and every sentence adds meaningful detail (endpoint, QR codes, webhook, fees, auth). It could be split into bullets for readability, but the density is still efficient.

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

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

This is a complex payment-creation tool with 8 parameters and no output schema. The description fully compensates by explaining the response structure (endpoint, body, coin amount, rate, pay page URL), the webhook outcome, fee mechanics, and auth options—making it nearly self-sufficient for correct invocation.

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

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

The input schema covers all 8 parameters with rich descriptions (100% coverage), so the baseline is 3. The description adds value by explaining how amountUsdCents is converted, that TTL locks the rate, and that checkoutKey is a restricted alternative to watch credentials, which helps agents reason about parameter relationships.

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: 'Accept an XMR/ZEC payment INTO YOUR OWN WALLET: creates a checkout invoice against your Private Watch.' It clearly states the resource (invoice) and distinguishes it from the sibling seneschal_checkout_invoice_status by focusing on creation, and includes a precise payment flow.

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 for when to use the tool (accepting XMR/ZEC into your own wallet) and explains auth alternatives: 'Use your watchId+watchToken server-side, or a restricted checkoutKey... anywhere you cannot keep secrets.' It doesn't explicitly name alternatives, but the use case is 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 provided, the description carries the full burden. It discloses the state transition flow (pending -> confirming -> terminal states) and the authentication-free capability model. It doesn't cover error cases or rate limits, but the core behavior is well communicated.

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 action and state list, and contains no filler. Every clause adds meaningful information about the polling behavior and usage context.

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 poll tool, the description is complete: it explains the purpose, the possible return states, and the auth model. No output schema exists, but the description's explicit state enumeration suffices as the expected output contract.

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

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

Schema coverage is 100% and the invoiceId param is documented as 'returned from create'. The description adds important extra meaning by explaining that the invoiceId itself acts as the capability and requires no token, going beyond the schema.

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

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

The description uses a specific verb ('Poll') and resource ('checkout invoice'), and enumerates the exact state machine, clearly distinguishing this from the sibling create tool. It is immediately obvious what the tool does.

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

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

The description states this is public and free, that the invoiceId is the capability (no token needed), and that it's meant for a buyer agent to watch its own payment land. This conveys when to use the tool, though it doesn't explicitly list exclusions or alternative tools.

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

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

With no annotations provided, the description carries the full transparency burden. It discloses not only the purpose but also behavioral details: summary returns counts/teaser, detail returns a paid full feed via x402, address override allows single-address lookup, and there is an explicit warning to verify on-chain. While it omits operational details like rate limits or data freshness, it covers the most critical behaviors for an agent.

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 yet information-dense, using a numbered list for risk categories and clear statements for view modes and address lookup. Every sentence serves a purpose, and the structure makes it easy to scan. It is slightly long but not verbose, earning a 4.

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, no annotations), the description provides a thorough overview: what it flags, how views differ, payment requirement, address lookup, and a verification warning. It lacks explicit return-format details, but in the absence of an output schema, the description still gives enough context for an agent to select and invoke the tool correctly.

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

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

The schema covers all 5 parameters with descriptions, so the baseline is 3. The description adds some extra context (e.g., summary returns a teaser, detail is 'uncapped', address overrides the feed), but these are largely restatements of the schema's parameter descriptions. The description does not add significant new meaning 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 clearly states the tool provides defensive intel for MEV searchers and bot operators, enumerating three specific risk categories (malicious spenders, honeypot tokens, dangling approvals) and mentioning the risk-scoring feature. This specific verb+resource phrasing distinguishes it from sibling tools, none of which overlap with counter-MEV intelligence.

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 when to use the tool (defensive intel for MEV/bot operators) and explains the available views (summary vs. detail), address lookup, and a caution to verify on-chain. It does not explicitly mention when not to use it or compare to alternatives, but the tool's uniqueness and the provided usage scenarios make the guidance 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 must carry the full burden. It discloses the type of data (fees in bps, contract addresses, liquidity notes, caveats) and mentions filtering. However, it does not explicitly state that this is a read-only operation or whether data is live versus cached. The phrase 'editorially open' is ambiguous and could be misread as suggesting the tool allows modifying the catalogue, so the transparency is only moderate.

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 and information-dense: it leads with the core identity, lists contents, gives a use case, and ends with filters. It is not bloated, though the phrase 'editorially open' is slightly confusing and could be removed or clarified without losing meaning.

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 explicitly listing the returned data fields (fees, contract addresses, liquidity notes, caveats). It also covers the tool's purpose, use case, and available filters, making it sufficiently complete for a simple catalogue query tool. It lacks mention of pagination or exact response format, but the field list mitigates that.

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 provides 100% coverage for all three parameters with detailed descriptions. The tool description adds marginal value by mapping the filters to the parameters ('filter by chain, max fee, or multi-asset support'), but it does not explain parameter types or syntax beyond the schema. Baseline 3 is appropriate because 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 precisely identifies the tool as a curated catalogue of specific Ethereum mainnet flash-loan providers, enumerating exact providers (Aave V3, Balancer V2, etc.) and the data fields included. This distinguishes it clearly from all sibling tools, which focus on borrowers, invoices, watchlists, and other domains. It is specific and not a tautology.

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 states the intended use case: 'Helpful for searcher agents picking the cheapest viable provider for a liquidation or arbitrage strategy.' It also indicates the available filters. However, it does not explicitly mention when to avoid using this tool or name alternative tools, though no direct competitor exists among siblings.

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

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

No annotations are provided, so the description carries the full burden. It clearly says 'Returns', indicating a read-only operation, and adds context about which protocols are covered. However, it does not explicitly state that no modifications are made or describe any edge cases like unknown addresses, but the read-only implication is strong.

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

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

The description is two sentences, front-loaded with the primary function, and every sentence carries useful information. No wasted words or redundancy with the schema.

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

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

Given the tool's simplicity (one parameter, no output schema), the description is nearly complete. It states what is returned, the scope of protocols, and the input format. A minor gap is not specifying the response structure, but this is not critical for a simple getter with clear semantics.

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 only a pattern, but the description adds meaningful semantics by explaining that the parameter is an EOA/contract address and must be a 0x-prefixed 20-byte hex string. With 0% schema description coverage, this compensation is valuable and clarifies both type and format 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 uses a specific verb ('Returns') and clearly defines the resource (latest known state of an address) and scope (across Aave, Morpho, Spark). It naturally distinguishes this tool from siblings like seneschal_get_borrower_history (which implies historical data) and seneschal_list_borrowers (which lists multiple borrowers).

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 retrieving a current snapshot of a borrower's positions, but it does not explicitly state when to choose this tool over alternatives or mention any alternative tool. There is no exclusionary guidance, only the phrase 'latest known state' hints at a current-snapshot 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?

With no annotations, the description carries the full burden. It discloses the output format and the default granularity (raw observations), which is useful. However, it does not explicitly state that this is a read-only operation (though 'Returns' implies it), nor does it mention potential behaviors like result ordering, empty results, or how 'limit' interacts with the data. These gaps are notable but not critical for a simple read 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?

Two sentences, no wasted words. The first sentence front-loads the core function, and the second provides a practical hint about granularity. The structure is clean and efficient.

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

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

The tool has 6 parameters, no output schema, and no annotations. The description explains the return values and one default, but it lacks guidance on how this tool fits with siblings and omits clarifications like parameter relationships (e.g., how 'limit' affects bucketing). Given the absence of an output schema, more detail on the return structure or usage context would improve completeness, but the description covers the essential function adequately.

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 83%, so the baseline is 3. The description adds value by clarifying that 'address' and 'protocol' are the borrower address and protocol, and it explains the 'granularity' parameter in terms of chart-friendly buckets (hour/day), which goes beyond the schema's 'Bucket size; default raw'. This additional context justifies 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?

The description clearly states the tool returns a time series of specific fields (timestamp, health_factor, collateral_usd, debt_usd) for a given address and protocol, which is a specific verb and resource. While it is clear, it does not explicitly contrast with siblings like seneschal_get_borrower, which likely returns current state, so it does not fully distinguish among alternatives.

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 tool's name and description imply it is for historical data, but there is no explicit guidance on when to use this tool versus alternatives such as seneschal_get_borrower or seneschal_health. The description does mention using 'hour' or 'day' granularity for chart-friendly buckets, which provides some parameter-level usage context, but no when-to-use or alternative guidance is given.

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

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

With no annotations provided, the description carries the full burden. It discloses the specific return values (table sizes and timestamps) which implies a read-only operation, but it does not explicitly state there are no side effects, auth requirements, or potential failure modes. The behavioral transparency is adequate but not rich.

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

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

The description is a single sentence, front-loaded with the action verb 'Returns', and contains no redundant information. Every word earns its place.

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

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

For a simple zero-parameter health tool, the description adequately explains the return values and scope (table sizes and freshness timestamps for the Seneschal Data backend). It does not mention caveats like availability or permissions, but given its simplicity, it is reasonably 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 has zero parameters, so the baseline is 4. The description adds no parameter details because none exist, which is appropriate and consistent with the empty schema.

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

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

The description clearly states the tool returns table sizes and data-source freshness timestamps for the Seneschal Data backend, using a specific verb ('Returns') and resource. It does not explicitly distinguish from sibling tools, but the tool name and title ('Service health') make the purpose evident.

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

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

The description provides no guidance on when to use this tool versus alternatives. It only states what the tool returns, leaving the agent to infer usage context solely from the name and title.

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 is the sole source of behavioral disclosure. It adds useful context: it's a current snapshot, sorted ascending, and filters by health factor. But it omits mention of the protocol parameter's full enum (including compound), and doesn't describe the output structure or any pagination/rate-limit behaviors. This is adequate but not comprehensive.

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

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

The description is two sentences: the first front-loads the core purpose and sorting order, the second gives a targeted usage tip. Every word earns its place, and the format is easy to scan.

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 strong schema coverage, the description covers the essential behavior and adds a practical tip. Minor gaps remain: it doesn't mention the compound option in the protocol enum or explicitly state the return format, but an agent can infer the output from the tool's purpose and the schema.

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

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

Schema description coverage is 100%, so a baseline of 3 is appropriate. The description adds semantic flavor by explaining max_hf as a strict threshold and min_debt_usd as a dust filter, but it doesn't provide additional meaning for limit or protocol. This is marginal value over the schema.

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

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

The description clearly states it lists at-risk borrowers across Aave, Morpho, and Spark with a health factor below max_hf. This distinguishes it from sibling tools like seneschal_list_borrowers, which likely lists all borrowers, and seneschal_get_borrower, which focuses on a single borrower.

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 (listing current at-risk borrowers) and offers a concrete parameter tip (use min_debt_usd to ignore dust). However, it does not explicitly name alternative tools or state when not to use this 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?

No annotations are provided, so the description carries the full disclosure burden. It adds useful context by calling out 'borrower snapshot table' (implying data may not be live) and positions the operation as a discovery/read surface. Missing are explicit read-only confirmation, rate limits, and any response-format caveats, which are important for an unannotated 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?

Two sentences pack the essential information: what it is, how it differs from a sibling, and when to use it. There is no filler or redundancy, making it easy to parse quickly.

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

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

Given the tool has 9 parameters, no output schema, and no annotations, the description is reasonably complete: it clarifies the data source, the relationship to a sibling, and the browsing use case. The lack of return-value discussion is a minor gap, but the tool's purpose as a generic list makes the output format less critical.

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 complete per-parameter descriptions (defaults, bounds, enum values), so the description doesn't need to restate them. It adds a high-level summary of the filter dimensions (HF bounds, max-debt cap, sort, pagination) which helps the agent map the description to parameters without duplicating schema 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 title and description clearly establish a list/read function over the borrower snapshot table. The phrase 'Like seneschal_list_at_risk_borrowers but with...' explicitly distinguishes this tool from its closest sibling by enumerating additional capabilities, giving the agent a precise scope.

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 a concrete use case: 'walk the catalogue without knowing borrower addresses in advance.' It also names the sibling `seneschal_list_at_risk_borrowers` as a comparison point, implying when this tool is a better fit (broader filtering). However, it does not explicitly state when NOT to use it (e.g., when an address is already known).

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 transparency burden. It adds valuable behavioral context: the call is free, it covers every gated endpoint, and it leads to a paid follow-up. It could mention response formatting or rate limits, but for a simple metadata endpoint this is sufficient.

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 return value. Every sentence earns its place, providing both the 'what' and the 'how to use' 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?

The description is fully self-contained: it explains the return content, the cost behavior, and the next step (paid HTTP request with x402 header). For a zero-parameter tool with no output schema, this is complete. It also links to documentation for further details.

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

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

The tool has zero parameters, so the description has no parameter semantics to add. The baseline of 4 applies because the empty schema needs no elaboration. The description correctly focuses on output and usage rather than 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 returns specific metadata (protocol, network, recipient address, per-call price) for all gated endpoints. This is a specific verb+resource combination that distinguishes it from sibling tools like seneschal_premium_opportunities, which is the actual paid data endpoint.

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 guidance is provided: consult this once to budget a paid session, then make the paid HTTP request directly. The description even supplies the exact URL and header format, making the when-to-use and alternative crystal clear.

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

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

With no annotations, the description carries the transparency burden and adds meaningful context: data source (shadow recorder), full-slot coverage, and the x402 paywall/authentication model. It does not explicitly state read-only behavior or rate limits, but the nature of serving data is clear.

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

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

Three tightly written sentences: output specification, data source/coverage rationale, and access model. Each sentence contributes unique information with no filler or redundancy.

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

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

The description sufficiently outlines the returned data (percentiles and histogram) and clarifies the source and access constraints, which is adequate given the simple two-parameter schema. It stops short of describing the exact response envelope, but the key contents are explicit.

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%; the description adds only the phrase 'configurable window' and 'per-builder,' which slightly reinforces the window_ms and limit parameters but does not provide details beyond the schema. Baseline 3 applies.

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

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

The description clearly identifies a specific resource (per-builder bid distribution) with exact outputs (p25/median/p75/p90/p99/max ETH and a 24-element hourly histogram). It distinguishes itself from siblings by emphasizing coverage of every observed slot via the shadow recorder, not just landed blocks.

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

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

The description implies use cases by highlighting comprehensive slot coverage and the paid/premium access model, but it does not explicitly name alternatives or state when not to use this tool. Sibling names like builder_leaderboard suggest comparable tools, yet no direct comparison is made.

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 discloses key behavioral traits: the x402 paywall, the distinction between free agents seeing a stub and paying agents fetching the full feed, and the API endpoint. It does not elaborate on error handling or rate limits, but the access behavior is clearly explained.

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 value proposition, followed by the paywall behavior and a directive to consult paywall_info. The first sentence is dense but information-packed; the rest is concise and purposeful. No fluff, though the second sentence is slightly 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 the tool has 4 optional parameters, no required params, and no output schema, the description adequately covers the purpose, the paywall gating, and the URL for paying agents. It does not detail output shape, but the description of 'annotated opportunities' is enough for an agent to understand the content. The absence of output schema is compensated by the description's mention of ranking and annotations.

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 provides 100% coverage with descriptions for all four parameters (limit, since_ms, min_debt_usd, liquidation_bonus), including defaults and examples. The tool description does not add meaning beyond the schema, so the baseline 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 clearly identifies the tool as providing a premium feed of top at-risk borrowers across Aave, Morpho, and Spark, annotated with market intelligence and ranked by expected liquidation value. This is a specific verb+resource+scope that distinguishes it from sibling tools like seneschal_list_at_risk_borrowers, particularly by emphasizing the premium/paywall aspect.

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

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

The description explains the paywall context and explicitly instructs to use seneschal_paywall_info before opening a session, which is a clear usage prerequisite. It does not explicitly compare with alternative tools like seneschal_list_at_risk_borrowers, but the 'premium' positioning and paywall note imply when this tool is appropriate.

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

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

No annotations are provided, so the description carries the full burden. It discloses key behavioral traits: forwarding only to private builders, never the public mempool, retaining custody, signed bytes breaking if changed, and a free inspect view. It does not cover failure modes or exact payment handling, but covers significant 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 dense but each sentence adds value: it front-loads the core purpose, gives use-case examples, then details the view modes. It is slightly long but well-organized and not wasteful.

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

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

Despite having no output schema, the description specifies what 'info' returns (builder set, price, caveats) and what 'inspect' returns (decoded tx, target builders). For a 2-parameter tool, it provides enough context to select and invoke correctly, including the paid relay endpoint and free preview.

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 some nuance by explaining the default 'info' view and that 'inspect' requires raw_tx and is free, but it largely restates what the schema already provides. It adds some value but does not significantly compensate for missing details.

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: 'Front-run protection for any sensitive tx' and provides specific use cases (puzzle/CTF, approval revoke, first-touch, NFT mint). It distinguishes the tool from siblings by emphasizing private builders and never public mempool, which is a unique capability.

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 concrete examples of when to use the tool and explains the two view modes ('info' to check, 'inspect' to preview). It implies when not to use it (non-sensitive transactions), but does not explicitly mention alternatives or exclusions, so it scores a 4.

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

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

With no annotations provided, the description fully discloses behavioral traits: the prepaid credit meter costs (20000 atomic USDC/day idle + 5000 per webhook), creation paywall at $0.10 via x402 with $0.10 seed credit, HMAC-signed webhooks with credit block, low_credit warning, top-up endpoints, and AES-256-GCM encryption of view keys. This is rich, specific behavioral context far beyond minimal requirements.

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

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

The description is well-structured and front-loaded with the primary purpose. Every sentence adds unique value: credit costs, paywall, webhook signing, low-credit warning, top-up paths, and encryption. It is appropriately sized for a complex tool with many behaviors, and no sentences are redundant or wasted.

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 params, no annotations, no output schema), the description is thorough: it covers creation cost, ongoing credit meter, webhook behavior, top-up options, and encryption. The only gap is the absence of what the API returns upon success (e.g., watch ID or status), but this is not strictly necessary given the lack of an output schema. Overall, it is quite complete 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?

The input schema has 100% description coverage for all 5 parameters, so the baseline is 3. The description does not add per-parameter semantics beyond the schema, but it enhances overall understanding by explaining the credit meter and webhook behavior that relate to webhookUrl and the tool's purpose. No extra param details are provided, so the score remains at baseline.

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: 'Subscribe a Monero or Zcash address to view-key-based payment monitoring.' It specifies the resource (Monero/Zcash payment watch) and the action (create/subscribe), and distinguishes itself from siblings like seneschal_private_watch_create_crypto by explicitly noting the REST surface and x402 payment method in the title and description.

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 on when to use the tool (REST creation with x402 payment) and mentions related endpoints for top-up, but it does not explicitly state alternatives or exclusions for sibling tools such as seneschal_private_watch_create_crypto. The payment mechanism and 'Creation at the REST surface' imply the appropriate use case without direct contrast.

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 combines watch creation and quote generation, activates watch on a grace credit, auto-lands credit after payment confirmation, and returns the FREE endpoint + body. It does not cover error cases or idempotency, but the core 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 main purpose and key contrast. Every sentence carries meaningful information: the one-call behavior, the grace credit, the automatic credit post-payment, and the default values. No fluff or 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 tool's complexity (7 params, no output schema), the description covers purpose, behavior, return value (FREE endpoint + body), and defaults. It omits error handling and edge cases, but the provided context is sufficient for an agent to select and invoke the tool correctly.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds value by explaining defaults for payWith (defaults to chain) and amountUsdCents (defaults to server minimum), and by cross-referencing *_private_watch_info -> crypto_topup for bounds, which goes beyond the schema.

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

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

The description clearly states the tool creates a Monero/Zcash payment watch and returns a coin payment quote in one call, using the specific verb 'creates' and resource. It distinguishes from siblings by explicitly marking this as the 'all-coin onboarding path' with 'no x402, no USDC, no EVM wallet anywhere in the flow'.

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 when to use this tool: when paying in Monero/Zcash and avoiding USDC/EVM. It implies the alternative (seneschal_private_watch_create) by contrast, but does not explicitly name a specific sibling tool or state 'use this instead of X'. The default behavior and reference to *_private_watch_info for bounds add practical usage guidance.

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

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

With no annotations, the description carries the full burden and delivers a strong security disclosure: the phrase transits the server, no logging or persistence occurs, but network observers could see the bytes. It also clarifies that a UFVK is read-only and cannot spend funds, which is essential 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?

Four sentences, front-loaded with the core action, then rate limit, security warning, alternative, and read-only caveat. Every sentence earns its place with no filler or redundancy.

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

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

For a 3-param derivation tool with no annotations and no output schema, the description sufficiently covers purpose, constraints, security trade-offs, an alternative, and the nature of the output. It is complete enough 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?

Schema coverage is 100% and each property has a description, so the baseline is 3. The description adds no additional parameter semantics beyond reiterating the 12- or 24-word BIP-39 phrase; it does not compensate for or enhance the schema details.

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 names the action ('derive') and target ('UFVK from a BIP-39 mnemonic'), and states that it returns the matching UFVK. It distinguishes itself from sibling private_watch tools by focusing on key derivation rather than watch creation or 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?

It explicitly frames when to use this tool (need a UFVK from a mnemonic) and contrasts it with a safer offline alternative using the orchard-scanner binary, including a link. It also adds concrete usage constraints: FREE, rate-limited to 6/minute/IP.

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 behavioral burden. It discloses a key privacy behavior: 'The view key never touches our SQLite — it flows through to NFPT in memory only,' and adds pricing context ('$0.50 / call at the REST surface'). These go beyond what the schema conveys, though it does not mention failure modes or rate limits.

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, each earning its place: primary function, privacy behavior, usage context, and pricing. It is front-loaded with the main purpose and contains no fluff or repetition.

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

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

For a tool with no output schema and six parameters, the description provides essential context: purpose, usage, privacy, and pricing. It does not specify the response format in detail, but the schema's parameter descriptions (e.g., includeNotes) cover some of that. Overall, it is sufficiently complete for an agent to decide when and how to invoke 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?

Schema description coverage is 100%, so the baseline is 3. The description does not elaborate on any parameter semantics; it focuses on overall behavior and pricing. The schema already provides descriptions for all six parameters, so the description adds no extra parameter-level meaning.

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 verb and resource: 'Return all spendable + spent notes for a view key without setting up a watch.' The title 'One-off historical scan' and the phrase 'without setting up a watch' clearly differentiate it from sibling watch-related tools like seneschal_private_watch_create.

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 usage context: 'Use this when you want to reconcile a wallet at a point in time.' It implicitly contrasts with ongoing watch setup by saying 'without setting up a watch,' but it does not explicitly name alternative tools or state 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?

No annotations are provided, so the description carries the burden. It discloses 'free to call' and lists return data, but does not explicitly state the operation is read-only or mention rate limits, authentication, or side effects.

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

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

Single sentence with the action front-loaded and a clear enumeration of return types. No unnecessary 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?

For a simple no-parameter metadata tool, the description covers the main return categories (price, chains, health, security). However, since no output schema exists, it carries the burden; it omits details like price currency or update frequency, but is otherwise complete enough.

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?

Zero parameters exist in the schema, so baseline 4 applies. The description focuses on the output, which is appropriate since there are no parameters to document.

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

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

Clearly states it returns current price, supported chains, NFPT upstream health, and security notes for the view-key payment-monitoring service. Specific verb and resource, distinct from sibling tools.

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

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

No explicit when-to-use or alternatives are mentioned. The usage is implied by 'metadata' and the return list, but there is no guidance on when to choose this over other info tools like seneschal_health or seneschal_zecmon_info.

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 burden of behavioral disclosure. It explains the non-settlement behavior, the exact REST paths, tier pricing, and atomic USDC rates — all critical contextual information 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, front-loaded with the core purpose, and then packed with precise details (tiers, paths, rates, return behavior). Every sentence earns its place with no redundancy or 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?

The description explains the tool's return value (URL to POST) and the required follow-up action, which is essential given the absence of an output schema. It also provides cost details and tier mappings. It could be slightly more complete by distinguishing from the crypto alternative or noting failure modes, but 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?

Schema coverage is 100%, and the schema's parameter descriptions already explain tier sizes, approximate idle days, and token semantics. The description adds no significant parameter-specific meaning beyond the schema, so the baseline 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 clearly states the verb+resource ('Add prepaid credit to an existing Private Watch'), specifies three tiers with REST paths, and differentiates from the crypto sibling via the title's 'paid via x402 at REST'. It is specific 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 conveys that the tool returns a URL for the agent to POST to with its x402 client and explicitly notes it does NOT settle payment. However, it does not explicitly mention alternatives like seneschal_private_watch_topup_crypto 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 full burden. It discloses that the tool issues only a quote with a locked rate and payment address, requires polling until status=settled, uses a view-key scanner, never holds spend keys, and needs no API key. Slightly vague on failure/refund behavior, but strong overall.

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

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

Front-loaded with purpose, then details the flow in dense but organized sentences. Every sentence contributes meaningful information, though the endpoint explanation is a bit 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?

For a complex crypto-payment flow with no output schema, the description explains the quote fields, payment step, polling, and security posture. It doesn't detail the settled-state response shape, but covers the essential workflow well.

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 100% of parameters with descriptions. The description adds process context (invoice tag, memo token, quote nature) but doesn't add per-parameter details beyond what the schema already provides, so baseline 3 is appropriate.

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

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

Description clearly states it funds a Private Watch by paying in XMR or ZEC, using a specific verb and resource. The phrase 'instead of USDC' distinguishes it from the sibling private_watch_topup 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?

Explicitly frames the tool as an alternative to USDC payment and explains the quote, send, and poll workflow. It doesn't name the sibling tool directly but 'instead of USDC' gives clear selection context.

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

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

With no annotations provided, the description carries the full burden and does so richly. It discloses the heuristic nature, warns to verify on-chain, explains the classification logic, notes the paywall for detail view, and describes the single-address path, providing substantial behavioral context 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 dense but every clause earns its place: purpose, categories, examples, methodology, view behaviors, payment, and caveat are all included without fluff. It is front-loaded with the core function and structured logically.

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 (multiple classifications, views, payment), the description covers output categories, view modes, evidence sources, and verification warning. No output schema exists, so it partially describes return values (counts, rollups, watchlist), but could be more explicit about exact response structure.

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?

All five parameters already have schema descriptions, so the baseline is 3. The description adds extra behavioral meaning for view (summary vs detail outputs), address override, and clarifies that detail view is paid and served for agents, hence 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?

The description clearly states the tool classifies puzzle/CTF/bounty contracts into specific risk categories (e.g., locked_no_payout, frontrun_bait) using a defined methodology. It distinguishes itself from sibling tools by focusing on this unique domain and giving concrete examples like TeikhosBounty.

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 for when to use this tool (for puzzle/CTF/bounty contracts) and explains the different views (summary/detail) and address override. However, it does not explicitly name alternative tools or provide when-not-to-use guidance, though no direct sibling seems comparable.

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 adds valuable context: sub-50ms response time, flat $0.001/call cost, data sourcing details (SQLite + shadow-blocks recorder, full nodes), and that each question returns exactly one fact. It does not describe error behavior or exact output formatting, but the core operational traits are 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 well-structured and front-loaded with the core purpose, then logically organizes the two question families. It is dense but every sentence adds useful information: performance, cost, data sources, and the question lists. No fluff or repetition.

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

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

The tool has no output schema, so the description must explain return values. It states each question returns 'ONE yes/no or one number,' but does not specify which questions return which type, nor the exact output structure. It does point to /v1/q for input lists and availability, but not for output formats, leaving a notable gap 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%, and the description largely mirrors the schema's parameter descriptions (e.g., 'DeFi questions take addr/protocol/window/builder/pct/etc.'). It adds the extra hint to consult /v1/q for exact per-question inputs, but does not specify which parameters apply to which questions beyond the generic grouping.

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 atomic single-fact endpoints answering a yes/no or a number, and enumerates the two families (DeFi and privacy chains) with specific question names. It is specific and informative, but does not explicitly compare against sibling tools like seneschal_recent_liquidations, so it lacks full sibling differentiation.

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

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

The description indicates the tool is designed for tight agent loops and directs users to consult /v1/q for per-question input lists, which is helpful. However, it does not provide explicit guidance on when to use this tool versus the specialized sibling tools, nor does it state 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 provided, the description carries the transparency burden. It discloses that results include both outcome types and are sorted by timestamp descending, which adds behavioral context. However, it does not explicitly state that this is a read-only operation, nor does it describe pagination or result shape, leaving some gaps.

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

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

The description is a single sentence that front-loads the core purpose and includes relevant details (outcome types, sort order) without unnecessary filler. It is appropriately sized for the tool's simplicity.

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, so the description should compensate by explaining what the returned liquidation objects contain. It mentions outcome and sorting but omits other likely fields (e.g., amounts, user, protocol) and pagination behavior. While the schema's parameter descriptions fill some gaps, the description is not fully self-contained for an agent to understand the response structure.

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 complete descriptions for all three parameters (limit, protocol, since_ms) with coverage at 100%. The description itself adds no parameter-specific meaning, so it does not elevate beyond the baseline. It does mention outcome values that are not parameters, but these do not clarify parameter 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 that the tool returns liquidations observed in the recent past and distinguishes between outcomes (won_by_other vs we_landed). It is specific to a resource type and includes sort order. However, it lacks an explicit verb like 'list' or 'retrieve', making it slightly less direct.

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 by the description (view recent liquidation events), but there is no explicit guidance on when to use this tool versus alternatives, nor any exclusions. Since no sibling liquidation tools exist, the absence of explicit alternatives is not penalized heavily, but clearer contextual guidance would improve the score.

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

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

With no annotations, the description carries the full burden. It discloses the exact contents of the snapshot, implying a read-only public operation (via 'public stats dashboard' and 'snapshot'). It doesn't mention rate limits or auth, but those are likely irrelevant for a public stats endpoint.

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: the first is a dense but efficient list of all return components, and the second reinforces the one-call value. Every word earns its place, with no fluff or 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?

Since there is no output schema, the description serves as the return contract by explicitly listing all eight data components (e.g., total positions, HF distribution, liquidations series). It also provides the dashboard URL and the purpose, making the tool's behavior fully understandable in context.

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 accepts zero parameters, so schema coverage is trivially 100%. The baseline for 0 params is 4; the description correctly doesn't need to explain parameters, and it doesn't.

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 provides an 'Aggregate snapshot' for the public stats dashboard and enumerates all included metrics, which is specific and distinct from sibling tools like seneschal_list_at_risk_borrowers or 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 says 'One call returns everything needed to render the dashboard,' clearly indicating when to use this tool (when you need the full overview). However, it doesn't explicitly mention when not to use it or name alternative tools as substitutions for individual data points.

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 transparency burden. It discloses that the tool is 'Free to call' and warns about a shared rate limit ('20 scan starts / 15 min, shared across all agents'). It also implies read-only behavior by describing it as an info endpoint, though it does not explicitly state 'read-only' or clarify whether the rate limit applies to this call or to scanning itself.

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

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

The description is two sentences, with the first sentence front-loading the core function and the second providing usage context and alternatives. Every word earns its place, balancing density with clarity.

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

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

Given the tool's simplicity (zero parameters, no output schema), the description fully covers purpose, usage, cost, rate limits, and alternative routes. It is complete for the tool's complexity and leaves no critical gaps for an agent deciding whether to invoke 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 tool has zero parameters, so schema coverage is trivially 100%. Per the rubric, a zero-parameter tool gets a baseline of 4. The description adds no parameter-level detail because none exist, which is acceptable.

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: returns 'Live chain tip, scanner reachability and the current free-tier limits for Zcash UFVK scanning.' It uses specific nouns and distinguishes from sibling tools by positioning itself as a pre-scan status check ('Start here before scanning').

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 advises when to use this tool ('Start here before scanning') and provides clear alternatives for different use cases: 'For anything scheduled, bulk or latency-sensitive use ... private/historical' or 'better ... private/info to get a webhook.' This is direct when-to-use guidance with named alternatives.

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

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

With no annotations provided, the description fully discloses key behaviors: the scan runs asynchronously (returns jobId/jobToken, poll status), omitting birthdayHeight triggers a backward walk, and the tool is free but rate-limited (20 starts / 15 min, shared across agents). This goes well beyond minimal disclosure.

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

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

The description is tightly packed with essential information and every sentence earns its place. It front-loads the core action, then explains async behavior, rate limits, and alternative endpoints without unnecessary 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?

Despite having no output schema, the description explains the return payload, polling workflow, rate limiting, and when to prefer paid alternatives. This makes the tool's usage model fully understandable for an AI 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 coverage is 100%, so the baseline is 3. The description adds meaningful context beyond the schema, especially for birthdayHeight (omission causes backward walk) and hints about deepScan not being speculative. It does not duplicate the rich schema descriptions but complements them.

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

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

The description opens with a specific verb and resource: "Open a scan of a Zcash UFVK." It clearly distinguishes the tool from siblings by explaining that it returns a job ID and that polling happens via seneschal_zecmon_scan_status, and contrasts with paid alternatives.

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

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

Explicitly states when to use this free tool vs paid alternatives: "For anything scheduled, bulk or latency-sensitive use https://api.seneschal.space/v1/private/historical ... or ... /info to get a webhook." It also explains the behavior when birthdayHeight is omitted, giving clear usage 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?

No annotations are provided, so the description carries the burden. It discloses that cancellation releases a scanner slot and warns about finite concurrency and abandoned chain walks. This adds meaningful behavioral context beyond the schema, though it does not mention error states or irreversibility.

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

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

The description is short and front-loaded with the essential action. The final 'Free.' is ambiguous and adds little, slightly detracting from otherwise efficient structure.

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 two-parameter tool with no output schema, the description covers the core operation, when to use it, and system-level consequences. It is largely sufficient, though it would benefit from a note that jobId and jobToken typically come from a starting scan operation.

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

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

Schema description coverage is 0% and the description adds no meaning to the parameters jobId or jobToken. It does not explain how to obtain these values or why jobToken is required, leaving the agent without sufficient semantic guidance beyond the bare property names.

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

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

The description clearly states the tool's action: 'Stop a running scan and release the scanner slot.' It identifies both the verb and resource, effectively distinguishing this cancel operation from sibling tools like zecmon_scan and zecmon_scan_status.

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 usage guidance is provided: 'Do this as soon as you stop caring about a scan' with the rationale that concurrency is finite and abandoned scans block others. It does not mention explicit alternatives or when-not-to-use scenarios, 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?

With no annotations, the description fully carries the behavioral disclosure burden. It explains that notes accumulate and can be read before completion, specifies phase-specific payload content, imposes a rate limit, and notes that the tool is free. This is rich, non-obvious behavioral context beyond a simple 'returns status' statement.

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

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

The description is three sentences, all dense with useful information: purpose, return behavior, phase-specific details, rate limiting, and cost. No filler or repetition. Front-loading the core action makes it immediately scannable.

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 adequately explains the return values (phase, progress, notes, coverage windows). It covers rate limiting and the source of required parameters. It doesn't mention error conditions or when a scan is considered complete, but for a polling tool this is reasonably 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 already describes all 3 parameters at 100% coverage, so baseline is 3. The description adds semantic meaning by explaining that notes accumulate (relevant to includeNotes) and that jobId/jobToken come from zecmon_scan. It also mentions the phase-specific return data, which helps the agent understand what the polling job will yield.

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

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

The description opens with a specific verb+resource: 'Poll a scan opened by zecmon_scan.' This clearly distinguishes it from siblings like zecmon_scan (which starts a scan) and zecmon_scan_cancel (which cancels one). The purpose is 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?

It clearly indicates when to use this tool (after opening a scan via zecmon_scan) and provides a concrete usage constraint ('Poll no faster than every 1.5s'). It does not explicitly mention alternatives or when not to use it, but the context is strong enough for correct selection.

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