Seneschal Data

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

No annotations provided, but the description conveys read-only behavior (discovery, free, no payment). Could explicitly state no side effects, but context 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?

Description is dense with information but front-loaded with purpose. Could benefit from bullet points for readability, but every sentence adds value.

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

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

Covers all parameters, output formats (gopher and JSON), drill-down paths, pagination, and the tool's role relative to siblings. Complete for a discovery tool despite no output schema.

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

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

Schema coverage is 100%, and the description enriches each parameter: enumerates all section values, explains format output difference, and clarifies cursor usage for registry pagination.

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 this is a 'discovery index' and 'directory' for finding tools within the ecosystem and the MCP registry. It distinguishes itself from sibling tools by explicitly saying 'use it to FIND tools, then connect'.

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

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

Provides explicit start instruction ('Start with section="root"'), drill-down patterns, and alternatives like 'format="json"'. Also clarifies it is not a replacement for MCP but a discovery layer.

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 explicitly states that 'This tool does NOT settle payment itself,' managing expectations. It also clarifies that the return is for the client to settle, adding behavioral context.

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

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

The description is three sentences long and front-loaded with the main action. Each sentence adds necessary information without redundancy, earning 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 tool that returns an endpoint and body, the description adequately explains the outputs and the tool's role. Though no output schema exists, the description gives enough context for an agent to understand the next steps. Minor improvements could include response format 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 input schema already has good descriptions for all three parameters (100% coverage). The description adds minimal value beyond schema, mainly reinforcing the amount range. Baseline 3 is appropriate.

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

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

The description clearly states the tool's purpose: 'Rank a notice higher by attaching USDC.' It specifies the return value (REST endpoint + body) and constraints. This differentiates 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 description indicates that 'Anyone can boost any notice' and mentions the amount range ($0.1-$25), providing clear context. However, it does not explicitly contrast with alternatives or state when not to use this tool.

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

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

No annotations exist, so the description carries the full burden. It clearly states the tool lists boards and counts, and that reads are free. No contradictions or hidden behaviors are evident.

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 mostly concise, but the second sentence about posting and USDC ranking is tangential to the listing function. It could be slightly tighter.

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

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

Given no output schema, the description adequately explains the output (list of boards with notice counts) and names the boards. It is sufficient for a simple list tool with no parameters.

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

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

The input schema has zero parameters, so baseline is 4. The description does not add parameter info, which is appropriate given no parameters exist.

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

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

The description clearly states the tool lists public notice boards and their notice counts, and enumerates the boards by name, distinguishing it from siblings like seneschal_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 description notes reads are free but provides no guidance on when to use this tool versus alternatives among the many sibling tools. Context is implied but not explicit.

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 that the tool does not directly post but returns an endpoint and body for the user to POST. It mentions ownerToken for future edits/withdrawals and rate limiting. This covers key behavioral traits beyond the input 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?

Three sentences, front-loaded with the main action. Each sentence adds critical information: what the tool does, what it returns, and behavioral notes. 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?

Given no output schema, the description adequately explains the return (endpoint, body, ownerToken, boostEndpoint). It covers the purpose and key behavioral aspects. However, it could specify the format of the returned endpoint/body or mention required parameters. Still, it is fairly complete for a tool of moderate complexity.

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 description does not need to repeat parameter details. However, it adds no extra meaning beyond what the schema already provides. The baseline of 3 is appropriate; the description offers value in explaining the return but not 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 title and description clearly state the action 'post a notice' and the resource 'public notice board'. The description uses specific verbs like 'Prepare' and 'Returns the REST endpoint + body to POST'. Among siblings like seneschal_board_list and seneschal_board_read, this tool is distinctly about creating a notice.

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 like rate-limiting per IP and that new notices start at the bottom, hinting when to use. It mentions boostEndpoint, linking to the sibling tool seneschal_board_boost, but does not explicitly contrast when to use this vs. alternatives. Overall, practical usage guidance is present but could be more explicit.

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 that the tool is free to call and explains the ranking algorithm. However, it omits potential details like pagination behavior (limit param exists) or authentication requirements, which would improve transparency.

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

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

Two sentences pack essential information: purpose, ranking behavior, and cost. No filler, all front-loaded. 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 read operation with two parameters and no output schema, the description covers core functionality and distinguishes from siblings. Minor gap: output format is implied but not explicitly described, though not critical for agent 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?

Schema coverage is 100%, but the description adds valuable meaning beyond parameter names and types: it explains the output is ranked by decayed weight then recency, and notes it's free to call. This enriches the agent's understanding of the parameters' effect on results.

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 ranked notices from a board, specifying the ranking order (decayed weight then most recent). The verb 'return' and resource 'notices on a board' are precise, and the tool is easily distinguished from siblings like seneschal_board_post or 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?

No guidance is provided on when to use this tool versus alternatives such as seneschal_board_list or seneschal_board_boost. The description does not set context for selection or exclude any scenarios.

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

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

With no annotations, the description carries the burden. It discloses that replies are free, never boosted, and title defaults to 'Re: <thread title>'. However, it does not mention error handling, authentication, 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 concise at three sentences, front-loaded with the core purpose, followed by key behavioral details. No filler.

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

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

Given 7 parameters, no output schema, and no annotations, the description provides sufficient context for the tool's basic usage but lacks details on error conditions, return format, and permissions.

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 context for the 'title' parameter (default behavior) but does not significantly enhance understanding 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's purpose: preparing a free reply to an existing notice, specifying threading behavior ('one level deep') and distinguishing from related tools like seneschal_board_post 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?

The description explains that replies are free and never boosted, and that boosting should be applied to the thread root. It provides context on when to use this tool, though it could explicitly mention alternatives like seneschal_board_post for new threads.

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

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

The description notes that data is 'cached for 60s', a useful behavioral trait. However, no annotations are provided, so it does not disclose other traits like read-only nature, authentication requirements, or error handling, leaving gaps in transparency.

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

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

The description is two sentences, front-loading the core purpose and adding a crucial caching detail. Every word serves a purpose, with no redundancy or unnecessary elaboration.

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?

While the description explains what data is returned (share, MEV, caching), it does not mention the available parameters (limit, window), ordering, or output format. Since parameters are fully defined in the schema, the description is minimally complete but lacks additional context for optimal use.

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

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

Schema description coverage is 100%, with clear descriptions for limit and window in the input schema. The tool description adds no parameter-specific meaning beyond the schema, so it meets the baseline but does not exceed it.

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 slot-by-slot ground-truth share of Ethereum mainnet block builders and total MEV captured per builder. It is specific about the resource (builders), metric, and source (Seneschal's shadow recorder), distinguishing it from siblings like seneschal_premium_builder_stats which likely offers different statistics.

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

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

No explicit guidance is given on when to use this tool versus alternatives. Sibling tools such as seneschal_premium_builder_stats and seneschal_stats_overview exist, but the description does not differentiate their use cases or provide selection criteria.

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 covers behavioral traits: it creates an invoice, returns endpoint details, locks rate for TTL, sends a webhook on payment, and debits a flat fee. While it lacks explicit failure modes or expiration handling, it provides substantial transparency.

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

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

The description is a single paragraph that is relatively concise (around 120 words) and front-loaded with the main action. However, it is dense and could benefit from slight restructuring for easier scanning. Still, it earns its sentences.

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

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

Given no output schema, the description explains the return (endpoint, coin amount, rate, pay page URL, webhook) and fee behavior. It covers the essential aspects for an agent to invoke and understand outcomes. The complexity is moderate, and the description is complete enough for this tool.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds contextual value (e.g., checkout key usage, webhook response), but does not enhance individual parameter semantics beyond the schema descriptions. Thus a score of 3 is appropriate.

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

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

The description clearly identifies the tool as creating a checkout invoice for XMR/ZEC payments into one's own wallet. The verb 'create' and resource 'checkout invoice' are specific, and it distinguishes itself from sibling seneschal_checkout_invoice_status by focusing on creation.

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 when to use this tool: for accepting non-custodial payments. It provides guidance on authentication (watchId+watchToken vs checkoutKey based on security context) and implies that invoice status checking is handled by a sibling tool. This meets the highest criteria for usage guidelines.

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

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

No annotations provided, so description carries full burden. It fully discloses the state machine and clarifies that invoiceId serves as the capability without needing authentication, which is critical for a public 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 fluff. Front-loaded with purpose and state transitions. Every sentence adds value.

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

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

While no output schema is provided, description covers state transitions adequately. Lacks specifics on return format (e.g., JSON structure), but given it's a simple poll status tool, the state list suffices.

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 already covers invoiceId with description. Description adds valuable context: 'invoiceId is the capability — no token needed', enhancing understanding beyond the schema's basic description.

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

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

The description clearly states the tool polls the state of a checkout invoice and lists possible states (pending, confirming, paid, underpaid, expired, cancelled). It distinguishes from sibling tool seneschal_checkout_invoice_create by focusing on checking 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?

Explicitly states it's public/free and no token needed, implying it's for polling after creation. Doesn't explicitly mention when not to use or alternatives, 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?

No annotations provided, so description carries full burden. It clearly states the tool provides 'defensive intel' and flags risks, with a caution to 'Verify on-chain before acting.' It mentions the premium nature of detail view and that detail is served via x402. It does not mention rate limits, authentication, or idempotency, but the tool is read-only and advisory, so the description is adequately 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 a single paragraph, but efficiently front-loads the purpose and three risk types. It includes concrete examples and parameter behavior without unnecessary repetition. Could be slightly more structured (e.g., bullet points), but every sentence adds value.

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

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

There is no output schema, but the description explains what summary returns ('counts + score distribution + a teaser') and what detail returns ('full risk-scored feed'). It also mentions categories and min_score filter. For a tool with 5 parameters and no output schema, this is sufficient to set expectations.

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

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

Schema coverage is 100% (all parameters described in schema). The description adds context beyond schema: explains view='summary' vs 'detail' behavior (aggregates+teaser vs full feed), clarifies address parameter as single-address lookup, and mentions premium payment for detail. This adds value beyond schema descriptions.

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

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

The description clearly states the tool flags three specific MEV risks (malicious spenders, honeypot tokens, dangling approvals) with examples (JaredFromSubway, Salmonella). It names the target audience (MEV searchers, bot operators) and uses a specific verb ('Flags'). The sibling tools are diverse (agent directory, board, liquidations, etc.) so no overlap confusion.

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 specifies target users ('MEV searchers and bot operators'), explains view modes (summary vs detail, paid premium), and gives usage examples ('pass `address` to check one address'). It does not explicitly state when NOT to use or list alternatives among siblings, but the sibling set is varied and this tool is unique.

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 convey behavioral traits. It describes the catalogue as 'curated' and 'editorially open,' implying a human-maintained list with potential staleness. It does not disclose update frequency, data source reliability, or any destructive actions (though none are expected). The description is adequate but lacks detail on freshness and whether the data is real-time.

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 clearly states the tool's content, and the second provides usage guidance. It is front-loaded with purpose and reasonably concise. Minor improvement could be structuring as a bullet list for readability.

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 explain the return format. It lists fields (fee, address, liquidity notes, caveats) but does not specify whether the output is a list, sorted, or always returns all providers. It gives a good high-level idea but lacks structural details about 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?

Schema coverage is 100%, so the baseline is 3. The description reiterates the parameters with slight elaboration (e.g., '1 bp = 0.01%' for max_fee_bps), but the schema descriptions are already clear and comprehensive. The description adds minimal extra meaning beyond what the schema 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 it is a curated catalogue of flash-loan providers with specific details (fees, addresses, liquidity notes, caveats). It distinguishes itself from sibling tools (e.g., borrower-related tools) by focusing exclusively on flash-loan providers for liquidation and arbitrage strategies.

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

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

The description explicitly says it is helpful for searcher agents picking the cheapest viable provider for liquidation or arbitrage, providing clear context. It also mentions filterable attributes (chain, max fee, multi-asset support), guiding usage. However, it does not explicitly state when not to use it or suggest alternative tools.

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

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

No annotations provided, so description carries burden. It indicates the tool returns data (read operation) but does not disclose whether it fetches on-chain data or uses cached state, or any authentication or rate limits. Adequate but not detailed.

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: first covers purpose and scope, second covers parameter format. No unnecessary words, front-loaded with key 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?

Given no output schema or annotations, description covers what it returns and how to call it. However, it lacks details about the return format, potential errors, or limitations (e.g., only works for addresses present in protocols). Adequate for a single-parameter tool but could be more complete.

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

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

Schema coverage is 0%, but description fully explains the parameter: 'Pass the EOA / contract address as a 0x-prefixed 20-byte hex string.' This adds concrete format guidance beyond the schema's pattern.

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

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

Description clearly states verb (Returns) and resource (latest known state of address across protocols). It distinguishes from sibling seneschal_get_borrower_history by specifying 'latest', implying snapshot over history.

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

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

Description implies use for current state but does not explicitly mention when to use this tool versus alternatives like seneschal_get_borrower_history or seneschal_health. No guidance on exclusions or prerequisites.

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

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

No annotations are provided, so the description must carry the burden. It discloses the return structure but does not mention behavioral aspects like rate limits, data freshness, or whether the history includes all events. The description says 'defaults to raw observations' but does not explain what raw entails.

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-loads the purpose, and contains 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?

Given no output schema, the description explains return structure and key parameters. It lacks guidance on selecting among siblings but is otherwise complete for a historical data retrieval tool.

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

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

Schema coverage is 83%, so baseline is 3. The description adds value by listing the return fields (timestamp, health_factor, etc.) not in schema, and clarifies granularity usage. However, it does not explain the 'limit' parameter or time range defaults beyond schema.

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

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

The description clearly states it returns a time series of specific fields (health_factor, collateral_usd, debt_usd) for an address on a protocol. It distinguishes from siblings like 'seneschal_get_borrower' by implying historical vs snapshot, but does not explicitly differentiate.

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 suggests using 'hour' or 'day' for chart-friendly buckets, implying raw is for detailed analysis. However, it does not specify when to use this tool versus sibling tools like 'seneschal_get_borrower' or 'seneschal_health'.

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

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

Without annotations, the description carries full burden. It implies a read-only operation by stating it returns data, which is sufficient for a simple health check, though it doesn't explicitly mention safety or idempotency. However, given the simplicity, it is adequately 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 a single sentence that is front-loaded with the key action ('Returns') and uses no unnecessary words, making it highly concise and efficient.

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

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

Given the tool has no parameters, no output schema, and a straightforward purpose, the description fully covers what the agent needs to know: what information is returned and for which backend.

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 no parameters, so the description does not need to add parameter meaning. Baseline score of 4 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 'Returns' and the specific resources ('table sizes and data-source freshness timestamps') for the 'Seneschal Data backend', which distinguishes it from sibling tools that focus on borrowers, flashloans, and other functionalities.

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 checking backend health but does not provide explicit guidance on when to use this tool versus alternatives, nor does it mention any exclusions or prerequisites.

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

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

No annotations exist, so the description must bear full transparency. It states it's a 'current snapshot' (read-only) and sorted ascending, but fails to mention auth needs, pagination, or the inconsistency that protocol enum includes 'compound' while description lists only three protocols. Basic transparency is provided but with gaps.

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

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

Two concise sentences: first states purpose with key parameters, second adds usage hint. No redundancies, front-loaded with core intent. Efficient 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?

With no output schema, the description should specify the return fields (e.g., address, health factor, debt). It only mentions 'borrowers' and 'sorted ascending' but leaves the output structure ambiguous. This is a significant gap for an agent to effectively use the tool's output.

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

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

Schema coverage is 100%, so baseline is 3. The description adds minimal value: it reiterates max_hf and min_debt_usd context but does not explain limit or protocol beyond what the schema already describes. No significant enhancement over the input 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 lists borrowers with health factor below a threshold across three protocols, sorted ascending. This is a specific verb+resource+condition, and it distinguishes from siblings like seneschal_list_borrowers which likely lacks the health factor filter.

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 hints at using min_debt_usd to ignore dust, providing context for parameter use, but does not explicitly state when to use this tool versus alternatives like seneschal_list_borrowers. The sibling tool names imply the distinction, but no direct exclusion or alternative mention 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?

No annotations are provided, so the description carries the full burden. It discloses filtering, sorting, and pagination behavior, which is adequate. However, it does not explicitly state that the tool is read-only, mention required permissions, or clarify data freshness. A more explicit read-only hint would improve transparency.

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

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

The description is three sentences long, front-loads the core purpose, and contains no redundant information. Every sentence adds value: purpose, comparison with sibling, and use case.

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 9 parameters, full schema coverage, and no output schema, the description covers the tool's functionality well. It explains when to use and what parameters are special. It lacks details on return format or pagination behavior, but the schema covers param-level details. Almost complete for a discovery tool.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds conceptual grouping (e.g., 'both lower and upper HF bounds'), but does not provide significant new meaning beyond what the schema already documents for each parameter.

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

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

The description uses a specific verb phrase ('list borrowers') and resource ('borrower snapshot table'), and explicitly distinguishes from the sibling 'seneschal_list_at_risk_borrowers' by listing unique parameters (both HF bounds, max-debt cap, sort options, pagination). This makes the purpose clear and unique.

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 advises using this tool 'to walk the catalogue without knowing borrower addresses in advance', implying a browsing use case. It contrasts with a sibling tool, but lacks explicit when-not-to-use guidance or a full list of alternatives. The context is clear enough for typical use.

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

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

No annotations provided, so description carries full burden. It discloses that the tool is free to call and returns specific metadata. Does not mention rate limits or error handling, but for a simple info endpoint it is adequate. Could add note about idempotency but not required.

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, each serving a distinct purpose: first describes the output, second provides usage instructions. No wasted words, front-loaded with the most important 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?

Given no parameters, no output schema, and simple nature, the description is complete. It tells the agent what the tool returns, that it's free, and how to proceed after calling it. Includes external documentation link 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?

No parameters exist (0 params, schema coverage 100%). Baseline set to 4 per guidelines. Description adds value by explaining the tool's purpose and output, which compensates for lack of parameter descriptions.

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

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

Description clearly states it returns protocol, network, recipient address, and per-call price for every gated endpoint. Specific verb 'Returns' with defined resource. Distinct from sibling tools which are about builders, borrowers, liquidations, etc.

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

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

Explicitly says 'Free to call' and provides a clear action plan: consult once to budget a paid session, then make a direct HTTP request with x402 header. Includes a link to docs. This is high-quality guidance on when and how to use the tool.

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

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

Description discloses that data comes from the shadow recorder covering every slot (not just landed blocks) and mentions the x402 paywall. This adds transparency beyond what annotations (none) provide.

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

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

Two concise sentences front-load key information: what the tool does, data source, and access method. 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?

For a statistics tool with two optional parameters and no output schema, the description adequately explains purpose, source, and access. Missing output format details but acceptable given complexity.

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 parameters are well-described in the input schema. The description adds 'configurable window' but no additional semantic detail beyond the schema.

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

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

Description clearly states the tool provides 'Per-builder bid distribution' and 'a 24-element hourly slot histogram', sourced from the shadow recorder. This is specific and differentiates it from sibling Seneschal tools.

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

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

The description implies usage for premium builder stats but does not explicitly compare to alternatives like seneschal_builder_leaderboard or state when not to use. No exclusions or when-to-use guidance.

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

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

With no annotations, the description carries full burden. It discloses the paywall, different responses for free vs paying, and an external API call. However, it does not mention potential rate limits or session details beyond 'opening a session', which is slightly vague.

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

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

Every sentence is purposeful. The first sentence immediately conveys the core function and value. The second clarifies the paywall and next steps. No filler words; 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?

The description covers the tool's purpose, paywall mechanism, output contents (market intel, ranking), and relevant parameter defaults. It lacks explicit mention of return format or edge cases, but given no output schema, it provides enough context for an agent to decide to use 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?

Input schema covers all 4 parameters with descriptions (100% coverage). The description adds default values (limit 200, since_ms now-7d, min_debt_usd 0, liquidation_bonus 0.06) but does not add further semantics 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 identifies the tool as a premium feed of at-risk borrowers with specific data (market intel, liquidators) and ranking. It distinguishes from siblings like seneschal_list_at_risk_borrowers by mentioning the paywall and using 'premium' in the name 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 explicitly states when to use (paying agents can fetch the full feed) and when not (free agents see a stub). It advises using seneschal_paywall_info first, providing clear guidance on prerequisites and workflow.

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

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

Discloses that user keeps custody, only signed bytes leave machine, any change breaks signature. Describes that info view returns builder set, price, caveats; inspect validates without relaying and is free. No annotations provided, but description fully covers behavioral aspects.

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?

Well-structured with main purpose first, then details on views and technical notes. Each sentence adds value, though slightly lengthy. Could be more concise but still effective.

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 complexity (relay mechanic, two views, paid vs free), description covers all necessary context: purpose, usage, privacy, technical details, and hints at return content. No output schema, but description compensates 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 coverage is 100%, but description adds significant meaning: explains enum options for 'view' and that 'raw_tx' is needed for inspect. Also describes what each view does with the 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?

Clearly states it provides front-run protection by relaying signed transactions to private builders, not the public mempool. Distinguishes itself from sibling tools which are unrelated (boards, health, etc.). Specific verb 'relay' and resource 'private transaction'.

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

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

Explicitly describes when to use each view: 'info' for builders/price/caveats, 'inspect' to decode/preview without relaying. Explains that paid relay is a POST endpoint via x402. Provides clear context for usage.

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

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

With no annotations, the description fully explains the credit meter, x402 paywall, webhook structure (HMAC-signed with credit block), low_credit warning, and view key encryption. This is highly transparent about behavioral traits.

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

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

The description is front-loaded with the main purpose and each subsequent sentence adds value. It is succinct yet comprehensive, covering credit, paywall, webhooks, and encryption without redundancy.

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

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

Given the complexity and no output schema, the description covers credit meter, webhooks, encryption, and topup. However, it omits the return format of the creation API itself (e.g., watch ID). This is a minor gap.

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

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

Schema coverage is 100%, so baseline is 3. The description adds context for the overall workflow but doesn't significantly enhance param understanding beyond schema. The schema already describes each parameter adequately.

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

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

The description uses a specific verb 'Subscribe' and resource 'Monero/Zcash address to view-key-based payment monitoring'. It clearly distinguishes from sibling tools like derive_viewkey, historical, info, topup by being the create variant.

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 on when to use (to start monitoring) and mentions related topup tools for credit replenishment. It doesn't explicitly state exclusions but covers the payment aspect and encryption, giving good 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 full burden and explains grace credit, automatic quote, and return structure, though lacks details on failure cases.

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

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

The description is front-loaded and concise, though dense; each sentence adds value.

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

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

For a 7-param tool without output schema, the description covers the overall flow and return, but lacks error handling details.

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

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

Schema covers all parameters, and the description adds value by explaining defaults (pay in coin, policy minimum).

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, distinguishing it from sibling 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 provides context for when to use (Monero/Zcash payments) and what not to use (no USDC, no EVM wallet), but could explicitly compare with 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?

With no annotations, the description carries full burden. It discloses the security trade-off: the phrase transits their server (no logging/persistence) but a network observer could see bytes. This goes beyond basic read/write hints.

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

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

The description is somewhat long but efficient. It leads with the core action, followed by critical security and rate-limit information. Every sentence adds value, though it could be slightly tighter. Still well-structured.

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

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

Given the tool's complexity (deriving a sensitive key), the description covers purpose, security risks, alternatives, rate limits, and parameter semantics. No output schema exists, but the return value (UFVK) is mentioned. Complete for agent decision-making.

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

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

Schema coverage is 100%, so baseline is 3. The description adds meaning beyond the schema by explaining that 'chain' currently only supports Zcash, and 'phrase' is a BIP-39 mnemonic. It also clarifies default network. This adds useful context.

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 derives a Zcash UFVK from a BIP-39 mnemonic using NFPT's orchard-scanner CLI. It specifies the verb 'derive' and the resource 'UFVK', distinguishing it from sibling tools which are about watch operations.

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

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

Explicitly states it is FREE but rate-limited (6/minute/IP), and recommends the safer alternative of offline derivation using the orchard-scanner binary. Also notes that a UFVK is read-only and cannot spend funds, guiding the agent on 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 provided, so description carries full burden. Discloses that the view key never touches SQLite and flows to NFPT in memory. Also reveals pricing ($0.50/call). Missing rate limits or error behavior.

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

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

Two sentences plus pricing note. Front-loaded with purpose and key distinguishing facts. Every sentence adds value.

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

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

Despite no output schema, description explains return contents (totals and optional per-note breakdown). Covers pricing and data handling. Adequate given parameter complexity (6 params, 3 required).

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

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

Schema coverage is 100%, so baseline 3. Description does not add significant meaning beyond the schema's parameter descriptions. It mentions pricing but not parameter specifics.

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

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

Clearly states the tool returns all spendable and spent notes for a view key without setting up a watch. Distinguishes from siblings by highlighting 'one-off historical scan' and 'no SQLite' persistence.

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

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

Explicitly says 'Use this when you want to reconcile a wallet at a point in time.' Implicitly contrasts with continuous watch tools. Could be improved by mentioning alternatives like seneschal_private_watch_create for ongoing monitoring.

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 disclose behavioral traits. It mentions 'Free to call' implying no side effects, but does not explicitly state read-only, rate limits, or security implications of 'security notes'. This is adequate but could be more explicit.

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

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

The description is a single, well-structured sentence that front-loads the most important information (what is returned) and ends with a usage note ('Free to call'). 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?

Despite lacking an output schema, the description lists the main output fields (price, chains, health, security notes) sufficiently for a zero-parameter tool. No additional context is needed.

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 with 100% schema description coverage (no params to describe). Baseline score of 4 applies as the description does not need to add parameter 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 explicitly lists the returned data (price, supported chains, NFPT upstream health, security notes) and identifies the tool as a metadata service for view-key payment-monitoring. This verb+resource specificity distinguishes it from sibling tools like seneschal_private_watch_create or seneschal_private_watch_historical.

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 'Free to call', which indicates a low-cost/no-risk operation. It does not explicitly compare to alternatives, but given the tool's purpose as a read-only metadata endpoint, the context is clear enough for an agent to decide when 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 full burden. It discloses that the tool returns a URL and does not settle payment itself, and gives credit costs. However, it omits error handling, prerequisites, and side effects, leaving gaps in transparency.

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

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

The description is concise at four sentences, front-loads the core function, and contains no redundant or extraneous 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?

Given no output schema and moderate complexity, the description adequately explains tiers, costs, return value, and payment flow. It could be improved by mentioning the prerequisite of an existing watch, but it's largely complete for the tool's purpose.

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

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

Schema coverage is 100%, and the description adds minimal extra meaning beyond the schema's parameter descriptions. The tier explanation (e.g., '10c = $0.10 ≈5 days idle') is already in the schema. No new parameter insights are provided.

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

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

The description clearly states the tool's purpose: 'Add prepaid credit to an existing Private Watch.' It distinguishes itself from siblings like topup_crypto by specifying the payment method (x402) and REST paths.

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 x402 top-ups) but does not explicitly contrast with alternatives like seneschal_private_watch_topup_crypto. It states what the tool does and that it returns a URL for further action, but lacks when-not-to-use guidance.

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

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

With no annotations, the description fully covers behavioral traits: issues a quote with locked rate, provides receiving address and exact amount, requires polling for settlement, and explains payment detection via view-key scanner without holding spend keys. It also mentions 'FREE to quote' and 'No x402, no API key'.

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, front-loading the purpose and then detailing the process. It is informative without being verbose, though it could be slightly more concise by removing minor redundancies.

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 lack of output schema, the description adequately explains the return behavior (quote, polling endpoint, status) and the overall process. It differentiates from the USDC sibling and covers security aspects. Minor gaps include no mention of error handling or edge cases, but overall complete for its complexity.

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

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

Schema coverage is 100%, so baseline is 3. The description adds workflow context but does not significantly enhance parameter meaning beyond the schema's own descriptions. For example, it mentions 'amountUsdCents' example but the schema already provides an example and range.

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 funds a Private Watch by paying in XMR or ZEC instead of USDC, specifying the verb 'fund', the resource 'Private Watch', and the payment methods. This distinguishes it from the sibling 'seneschal_private_watch_topup' which likely uses USDC.

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 clear step-by-step workflow: call endpoint to get a quote, send payment, poll until settled. It also notes that no API key or x402 is required. However, it does not explicitly state when to use this tool versus alternatives (e.g., when to choose crypto over USDC) or any prerequisites like needing an existing watch.

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

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

No annotations exist, so the description carries full burden. It discloses the heuristic nature of the analysis, warns that results should be verified on-chain, explains the classification logic, and mentions payment required for detail view. It stops short of describing rate limits or error handling, but overall provides solid transparency.

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

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

The description is a single dense paragraph that efficiently communicates all essential information without fluff. It front-loads the core purpose and quickly transitions to usage. Though somewhat lengthy, every sentence adds value. It could benefit from slight structuring (e.g., bullet points for categories) but remains effective.

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 5 parameters and no output schema, the description adequately explains the return types for summary and detail views, the categories, and the single-verdict option. It does not detail the structure of the 'full annotated watchlist' or the exact output format for summary, but provides enough context for an AI agent to understand what to expect and how to use the tool.

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

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

With 100% schema coverage, the baseline is 3. The description adds value by explaining what each view returns, hinting at the limit default (1000-capped), defining the classification enum values with examples, and clarifying that address returns a single verdict. This goes beyond the schema descriptions that only list parameter types.

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 (locked_no_payout, frontrun_bait, etc.) with concrete examples like TeikhosBounty. It distinguishes itself from sibling tools by its unique domain and analysis method (payout-path analysis + bytecode scan).

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

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

The description provides clear guidance on when to use summary vs detail views, how to get a single-contract verdict via the address parameter, and includes a caution to verify on-chain. However, it does not explicitly state when not to use this tool or mention alternatives among siblings, which are all in different domains anyway.

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 discloses performance, cost, data sources, and fact families. It implies read-only behavior but does not explicitly state no side effects or idempotency.

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, but the long list of endpoints makes it slightly verbose. However, every sentence adds necessary value.

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

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

Given the tool's complexity (21 questions, no output schema), the description covers purpose, usage, parameters, behavior, and data sources. It adequately informs the agent about what to expect.

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

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

Schema coverage is 100% with enum and descriptions. The description adds meaning by explaining that params are per-question, listing all questions, and directing to more details. This goes beyond schema.

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

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

The description clearly states it is for atomic single-fact endpoints, answering one yes/no or number question. It distinguishes from siblings by noting it's a general query tool for predefined facts, while siblings are specialized endpoints.

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 for when to use (tight agent loops, sub-50ms, $0.001/call) and directs to /v1/q for details, but does not explicitly state when to avoid or compare to alternatives.

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

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

No annotations are provided, so the description carries full burden. It discloses that the tool returns liquidations with outcome types and sorting order. It does not mention any destructive behavior, auth needs, or rate limits, but for a read-only tool with this purpose, the transparency is adequate.

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

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

The description is two sentences, front-loaded with the key purpose and outcome details. Every part is informative and there is no redundancy or wasted words.

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

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

The tool has no output schema, but the description explains the outcome field and sorting order, providing a good mental model. The limit and since_ms parameters are covered by the schema. Minor omission: could mention the default time range (24h) that is already in since_ms description.

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

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

Schema coverage is 100% with all three parameters described. The description adds value by stating 'Sorted by timestamp descending' and explaining the outcome categories, which are not in the schema. This helps the agent understand the data context beyond parameter definitions.

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 specifies 'Liquidations observed in the recent past' with clear outcome categories ('won_by_other', 'we_landed'), and 'Sorted by timestamp descending'. This clearly distinguishes it from sibling tools like seneschal_list_at_risk_borrowers or seneschal_list_borrowers, which deal with different data.

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

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

The description does not explicitly state when to use this tool over alternatives or when not to use it. It implies usage for viewing recent liquidation events, but lacks guidance on context or exclusions, which is a gap given the number of sibling tools.

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

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

No annotations are provided, so the description must cover behavioral traits. It correctly describes the tool as returning data without side effects, but lacks information on update frequency or caching behavior, which would be helpful 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 a single sentence that front-loads the main purpose and lists return components efficiently. It is slightly long but contains no filler, earning a solid 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 no output schema and no parameters, the description fully enumerates all return data fields (positions, debt, histogram, etc.), making it complete for rendering the dashboard without additional 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 input schema has no parameters and the description adds value by detailing the return structure (e.g., HF distribution histogram, top-10 borrowers). With 0 parameters, a baseline of 4 is appropriate, and the description compensates well.

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

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

The description explicitly states it provides an 'aggregate snapshot powering the public stats dashboard' and lists the specific data points included, distinguishing it from sibling tools that focus on individual pieces like recent liquidations or at-risk 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 the tool is for getting a complete dashboard snapshot, but does not explicitly guide when to use sibling tools for specific subsets (e.g., using seneschal_recent_liquidations for only recent liquidations). No when-not-to-use or alternative references are provided.

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