Seneschal Data

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

With no annotations, the description fully carries the burden. It discloses that the tool is non-destructive (discovery only), free, and provides a live mirror of an external registry. It explains the behavior of sections and pagination, and notes that it is callable within the MCP session. No contradictions.

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

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

The description is somewhat lengthy but every sentence adds value. It is front-loaded with the core purpose and then provides structured details on sections, formats, and pagination. It could be slightly more concise but overall well-organized 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 complexity (multiple sections, pagination, format options, and no output schema), the description is remarkably complete. It explains each section's purpose, default behavior, pagination mechanism, and even mentions the HTTPS mirror. It also clarifies it is free. All necessary information for correct invocation is present.

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

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

Schema description coverage is 100%, so baseline is 3. The description adds significant context beyond the schema: it explains the purpose of each section enumeration (e.g., 'root' shows top-level menu, 'registry' for browsing third-party servers), how pagination works, and the difference between formats. This enriches understanding, warranting 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 it is a 'terse, drill-down discovery index' for specific ecosystems and a live mirror of the MCP registry, with specific verbs like 'start with section="root"' and 'drill into a project'. It distinguishes itself from sibling tools by being a discovery layer, not a replacement for MCP, and explicitly says '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?

The description provides explicit guidance on when to use each section (root, projects, registry, about, agents), how to paginate with cursor, and the two available formats. It also states what the tool is not: 'A discovery layer, not a replacement for MCP — use it to FIND tools, then connect', effectively setting boundaries with 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?

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?

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?

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. 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?

The description discloses sub-50ms latency, flat $0.001/call, and data sources (SQLite, full nodes). However, it does not specify error handling, idempotency, or whether the tool is read-only, which are important for an agent without annotations.

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

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

The description is well-structured with a clear opening, performance details, and a list of questions. However, the question list partially duplicates the schema enum, making it slightly longer than necessary.

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, families, and data sources, but relies on an external reference for per-question parameter details. With no output schema, it implies return types but lacks explicit schema, leaving some gaps for complex usage.

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 value by grouping questions into families, explaining parameter differences between DeFi and privacy chains, and providing examples. This context helps the agent understand parameter usage 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 that the tool provides atomic single-fact endpoints answering yes/no or number questions, and lists specific questions for DeFi and privacy chains. However, it does not explicitly distinguish itself from sibling tools that serve similar specific functions.

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 mentions 'tight agent loops' and lists question families, but does not provide explicit guidance on when to use this tool versus sibling tools like seneschal_recent_liquidations. It refers to an external endpoint for per-question input details, which adds ambiguity.

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.