Seneschal

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

No annotations provided, so the description carries the burden. It discloses read-only discovery behavior, free usage, and the drill-down pattern. Could be more explicit about being side-effect-free, but overall 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?

Well-structured with front-loaded purpose and clear sections, but slightly verbose. Every sentence adds value, though 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?

No output schema, but description explains both gopher and JSON formats. Covers all parameters, usage patterns, and edge cases like drilling and pagination. Complete for a directory 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%. Description adds significant value by explaining each parameter's semantics: section values with drilling examples, format options with output structure, and cursor usage for 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 it is a 'terse, drill-down discovery index' and explains the hierarchical structure with specific sections. It distinguishes itself from sibling tools by positioning as a directory to find tools rather than a tool itself.

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

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

Provides explicit instructions: start with section='root', drill into projects with '<site>/...', use 'registry' for third-party servers, paginate with 'cursor'. Also clarifies it is a discovery layer, not an MCP replacement.

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 that it modifies state (ranks a notice), returns an endpoint for external settlement, accepts any user, and has a monetary range. It could mention if the operation is reversible or idempotent, but covers the main 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?

Two sentences that front-load the purpose and mechanism, then clarify the payment workflow. Every sentence is necessary; no redundant information.

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

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

Given 3 parameters, no output schema, and no annotations, the description adequately covers input semantics, action, output format (endpoint+body), and workflow. It doesn't detail post-settlement confirmation but that's reasonable for an external process.

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. The description adds value by specifying amountAtomic in USDC with min/max, board enum list, and id source ('from board_read'). This goes beyond the schema to clarify usage 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 the verb 'boost' or 'rank' and the resource 'notice' with the mechanism 'attaching USDC'. It distinguishes well from siblings like 'seneschal_board_post' and 'seneschal_board_read'.

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 when to use (to boost a notice) and clarifies that payment is not settled directly, indicating the external x402 process. It doesn't explicitly mention alternatives but the context of sibling tool names implies differentiation.

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?

Labels the tool as public and explicitly states 'Reads are free,' implying read-only and no cost. However, no annotations exist, and the description does not mention rate limits or authentication requirements.

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

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

Four sentences cover purpose, available boards, and usage context. The mention of posting and USDC is somewhat tangential but does not severely impact conciseness.

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

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

For a simple list tool with no parameters and no output schema, the description fully explains what it does, what data it returns, and that it is public and free.

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 zero parameters, the description adds significant value by listing the exact board names, providing context not available in 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 lists public notice boards and their notice counts, naming the specific boards (seneschal-features, data-requests, etc.). This differentiates it from siblings like seneschal_board_post or seneschal_board_read.

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 getting an overview of boards but does not explicitly state when to use this vs alternatives. Mentions posting and USDC ranking, which are irrelevant for this tool, causing mild confusion.

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 rate limiting per IP, return of ownerToken and boostEndpoint, and that new notices start at bottom. However, it does not clarify that the tool does not actually post the notice but returns instructions for the agent to perform a separate POST request.

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

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

The description is four sentences, all relevant and front-loaded with the primary action. No unnecessary words or repetition.

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

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

Given the tool complexity (7 parameters, no output schema), the description explains return values and key behaviors but lacks clarity on the tool's actual action (preparation vs. execution) and how it integrates with siblings like board_boost for boosting.

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 each parameter already described in the schema. The description adds no additional meaning to the parameters, so baseline score of 3 is appropriate.

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

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

The title 'post a notice' and description 'Prepare a free notice' clearly indicate the tool's purpose. It is distinguished from sibling tools like board_boost, board_list, and board_read. However, the nuance that it prepares a REST call rather than actually posting could cause slight ambiguity.

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 provided on when to use this tool versus alternatives. The description mentions free tier and rate limiting, but does not compare to board_boost or board_read, nor does it state that this tool is for creating a new notice.

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 present, so the description must cover behavioral traits. It discloses the ranking algorithm and that it's free to call, but does not mention rate limits, authentication needs, or other side effects. The ranking detail adds value, but missing details on limit defaults and output structure reduce 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 conveying purpose, ranking order, and cost. No fluff; every word earns its place. Ideal conciseness.

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

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

No output schema, so the description should explain return values. It only says 'ranked notices' without specifying fields or structure. Missing details on what information each notice contains, pagination, or cutoffs. Incomplete for an agent to fully understand 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 the baseline is 3. The description adds no additional meaning beyond the schema; the schema already describes required board enum and limit with min/max.

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 (boosted by decayed weight then most recent). This distinguishes it from sibling tools like seneschal_board_post (posting) and seneschal_board_list (listing boards).

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

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

The description implies usage for reading ranked notices and notes it's free, but does not explicitly say when to use this over alternatives or provide exclusions. Context suggests this is the primary read tool, but no guidance on when not to use it.

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

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

With no annotations, the description carries full burden. It discloses that replies are free, never boosted, and that the tool returns an endpoint+body to POST (not actually posting). It also mentions thread depth and default title. It does not cover authentication or rate limits, but the free nature reduces need.

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 with three sentences, front-loading the verb 'Prepare' and key details. Every sentence adds value without repetition.

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

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

The description explains the return value (REST endpoint + body), free nature, and thread depth. It covers all parameters via schema. It lacks error handling or prerequisites, but the tool is simple and the description is adequate for an AI to use correctly.

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

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

Schema coverage is 100%, setting baseline at 3. The description adds minimal new parameter info beyond the schema (e.g., title default is already in schema). It does provide behavioral context for the returned endpoint, but not parameter-specific value.

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

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

The description clearly states the tool prepares a free reply to an existing notice, starting or continuing a thread one level deep. It distinguishes from siblings like seneschal_board_post (new root post) by specifying 'reply' and mentioning that replies are never boosted.

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 the tool (to reply to an existing notice) and contrasts with boosting ('boost the thread root to rank the conversation'). It does not explicitly list alternatives but the sibling tool names and context make the usage clear.

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

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 caching for 60s but does not mention read-only nature, rate limits, or any side effects. Adequate but could be improved.

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 effectively convey purpose, data content, and caching behavior without waste. 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?

Given two parameters and no output schema, the description covers the key aspects: data source (Seneschal shadow recorder), content (builder share and MEV), and caching. It could detail the return shape slightly more, but is largely complete.

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

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

Schema coverage is 100%, with both parameters described (limit and window). The description adds minimal extra meaning beyond 'Top-N builders' and does not elaborate on parameter behavior.

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

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

The description clearly states that the tool returns slot-by-slot ground-truth share of Ethereum block builders and total MEV captured per builder, distinguishing it from sibling tools that deal with flashloans, borrowers, and liquidations.

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

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

The description does not explicitly state when to use this tool versus alternatives, though the sibling tools cover different topics, so confusion is unlikely. Guidance on usage context is implicit.

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 bears full responsibility for behavioral disclosure. It describes the tool as a defensive intel feed, mentions that detail view is paid via x402, and warns to verify on-chain. It does not contradict any annotations (none present). It could explicitly state read-only nature but is still transparent enough.

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 packs in all necessary information. It front-loads the main threats and then details parameters. While comprehensive, it could be slightly more structured (e.g., bullet points for parameter details) to improve scanability for an agent.

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 annotations, the description covers the key aspects: three risk categories, view modes, address lookup, and filters. It explains return types for each view (counts, score distribution, teaser vs. full feed). However, more detail on output structure or error cases would improve completeness.

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 significant value: it explains the behavior of each view (counts+teaser vs. full feed), the default for limit and category, the purpose of address for single lookup, and the risk score threshold. It also mentions the payment mechanism for detail, which is not in 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: flagging three specific types of MEV risks (malicious spenders, honeypot tokens, dangling approvals) with risk scoring. It provides concrete examples (JaredFromSubway $7.5M pattern, Salmonella-style traps), distinguishing it from sibling tools that focus on other areas like liquidations or borrower risk.

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 when to use different views (summary vs. detail), the address parameter for single check, and the optional filters (limit, category, min_score). It advises 'Verify on-chain before acting.' However, it does not explicitly state when not to use this tool or mention alternative tools for related tasks.

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 implies a read-only query operation ('curated catalogue'), but does not explicitly state whether modifications occur or if there are side effects. The qualitative liquidity notes suggest safe data retrieval.

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

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

The description is two sentences long with no redundancy. Every part adds value: purpose, contents, use case, and filter options. 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?

The description explains the return values (fee, addresses, liquidity notes, caveats) despite no output schema. Parameter semantics are covered by schema. The tool is a simple query with no nested objects, so the provided context is sufficient for an agent to decide to invoke it.

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

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

With 100% schema description coverage, the schema already documents all three parameters (chain, max_fee_bps, multi_asset). The description reiterates filtering but adds no new meaning beyond what the schema provides, warranting a baseline score of 3.

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

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

The description clearly identifies the tool as a curated catalogue of Ethereum mainnet flash-loan providers, listing specific providers and details. It distinguishes from sibling tools (e.g., borrower lists, liquidations) by focusing exclusively on provider information.

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 it is 'helpful for searcher agents picking the cheapest viable provider' and mentions filter options, establishing clear usage context. It could be improved by explicitly stating when not to use it, but the purpose is well understood from the sibling set.

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 behavior. It explains the data scope and input format but lacks details on data freshness, error handling, or authentication requirements.

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

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

Two concise sentences, no fluff, and the most important information (purpose and parameter format) is front-loaded.

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

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

Given no output schema, the description does not explain the return structure (e.g., fields in the snapshot). For a retrieval tool, this is a gap, though the core concept is clear.

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 0% schema coverage, the description adds meaning by specifying the address format (0x-prefixed 20-byte hex) and clarifying it returns state across protocols. This goes beyond the schema pattern.

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

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

The description clearly states the tool returns the latest known state of an address across multiple protocols (Aave, Morpho, Spark), distinguishing it from siblings like seneschal_get_borrower_history and seneschal_list_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?

Usage context is implied but not explicit. It does not specify when to use this tool versus alternatives (e.g., for history use the sibling tool) or any exclusions.

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

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

No annotations are provided, so the description carries the full burden. It explains the return shape and granularity but does not disclose behavioral traits like data ordering, pagination, or potential side effects. It implies read-only behavior but could be more 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?

Two sentences convey the core purpose and an important usage tip with no redundancy. The key action ('Returns a time series...') is front-loaded, making it easy for an agent to quickly grasp.

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 6 parameters (2 required) and no output schema, the description successfully covers the returned fields and the most important parameter (granularity). Defaults and other parameters are adequately handled by the schema. Minor omissions like ordering or data limits are acceptable given the tool's straightforward nature.

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

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

Schema description coverage is 83%, meeting the high-coverage baseline of 3. The description adds value by explaining granularity options and their intent ('chart-friendly buckets') and clarifies limit as 'Max rows fetched before bucketing'. This goes beyond the schema's basic 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?

Clearly states it returns a time series of specific fields (timestamp, health_factor, collateral_usd, debt_usd) for a given address and protocol. This distinguishes it from sibling tools like seneschal_get_borrower (likely current state) or seneschal_list_borrowers (list view).

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 guidance on granularity options ('use hour or day for chart-friendly buckets') but does not explicitly compare to sibling tools or state when not to use it. Implicitly suggests it's for historical data but lacks explicit alternatives or exclusions.

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

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

No annotations provided; description indicates a read operation returning data but does not mention side effects, caching, or authentication requirements. Adequate but minimal disclosure.

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

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

Single sentence, 13 words, front-loaded with verb and resource. No unnecessary information; 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?

Given no parameters and no output schema, the description adequately informs what data is returned. Could mention output format but not critical for a simple health 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?

No parameters in schema (100% coverage). Description adds meaning by specifying what the tool returns (table sizes and freshness timestamps), which is sufficient for a parameterless tool.

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

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

Description clearly states verb 'Returns' and specific resources 'table sizes and data-source freshness timestamps' for the Seneschal Data backend, effectively distinguishing it from sibling tools that focus on 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?

The description implies usage for monitoring backend health but provides no explicit when-to-use or alternatives. Lacks guidance on when not to use this tool.

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

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

With no annotations, the description must cover behavioral traits. It states it's a 'current snapshot' (point-in-time) and 'sorted ascending', but does not disclose pagination, authentication requirements, or response structure. Adequate but not comprehensive.

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

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

Two concise sentences front-loading the main purpose. No extraneous words. Exemplary succinctness.

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 clear purpose, the description lacks details about the output format (e.g., what fields are returned). Without an output schema, the agent has to guess the response structure, which is a significant 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 parameters are already documented. The description adds context for max_hf and min_debt_usd but not for limit or protocol. Baseline 3 is appropriate as the description adds minimal value 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 lists at-risk borrowers with health factor below max_hf, sorted ascending, and mentions three protocols. However, it omits 'compound' from the enumeration even though the schema includes it, causing a minor inconsistency.

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 on when to use this tool versus siblings like 'seneschal_list_borrowers'. The description does not mention alternatives or when not to use it, leaving the agent to infer from the name alone.

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 fully disclose behavioral traits. It mentions the tool operates on a 'snapshot table' and supports pagination, but does not specify whether it is read-only, idempotent, or if it has side effects. The description partially fulfills the transparency burden by explaining the filtering and sorting behavior, but lacks explicit safety characteristics.

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 consists of two dense sentences. The first sentence establishes the purpose and the second adds critical details and usage guidance. Every word serves a purpose; there is no repetition or filler. It is front-loaded and highly efficient.

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

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

Given the complexity (9 parameters, no output schema), the description adequately explains the tool's scope, filtering capabilities, and pagination. It does not describe the response format, but the tool is a list operation and the schema fully documents parameters. The description could be more complete by noting the default limit and max, but those are in the schema. Overall, it provides sufficient context for an agent to use the tool correctly.

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

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

Schema coverage is 100%, giving a baseline of 3. The description adds value beyond the schema by explaining the purpose of the extra parameters relative to the sibling (lower/upper HF bounds, max-debt cap, sort field/direction, offset pagination). This contextualizes the parameters and clarifies their role in the tool's functionality.

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 'generic discovery surface' over the borrower snapshot table, distinguishes it from the sibling `seneschal_list_at_risk_borrowers` by listing additional capabilities (lower/upper HF bounds, max-debt cap, configurable sort, offset pagination), and uses specific verbs like 'walk the catalogue'. The purpose is immediately clear and distinct.

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

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

The description says 'Use this to walk the catalogue without knowing borrower addresses in advance.', providing a clear use case. It contrasts with the sibling tool by noting differences in HF bounds and pagination, but does not explicitly state when not to use it or when to prefer alternatives. However, the guidance is sufficient for typical selection decisions.

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?

Since no annotations are provided, the description carries the full burden. It states 'Free to call,' implying no destructive side effects. It does not mention idempotency or caching, but for a metadata endpoint this is sufficient.

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

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

The description is two sentences: the first states what it returns, the second provides usage guidance. No wasted words, front-loaded with essential 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, the description fully explains what the tool returns (list of paywall metadata fields). It also tells the agent what to do next, making it complete for its simple purpose.

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

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

The input schema has 0 parameters, so schema coverage is 100%. The description adds context about what is returned but no parameter information is needed. Score reflects the baseline for 0-param tools.

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

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

The description clearly states it returns protocol, network, recipient address, and per-call price for every gated endpoint. This distinguishes it from sibling tools that provide specific data like borrower lists or leaderboards.

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 it is free to call, agents should consult once to budget a paid session, then make the direct HTTP request with a payment signature. This provides clear when-to-use and what to do after.

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, but description adds key behavioral context: data comes from shadow recorder covering all observed slots (not just landed blocks) and requires authentication via MCP. Would benefit from stating read-only nature or any 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?

Three sentences, each adding distinct value: output specification, data provenance, and access method. No redundancy or fluff. Front-loaded with essential 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?

Covers core output shape, source, and access. Lacks explicit mention of return format or units (though ETH is inferable from 'ETH'). With no output schema, slightly more detail on response structure would improve completeness.

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 descriptions already cover both parameters (limit and window_ms) with defaults and constraints. Description adds no extra parameter details beyond 'configurable window', so baseline 3 is appropriate.

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

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

Description clearly states it returns per-builder bid distribution (percentiles) and hourly slot histogram. Distinguishes from siblings by specifying 'premium' and mentioning the shadow recorder source, which is unique among the listed sibling tools.

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

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

Description implies use for premium bid data from shadow recorder, but does not explicitly compare with siblings or state when not to use it. Agents must infer from context; no direct guidance on alternatives.

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

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

With no annotations, the description carries full burden. It discloses the paywall and differences between free and paying access, but does not detail the output format, rate limits, or specific authentication steps beyond the paywall.

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 tool's purpose, then explains the paywall mechanism, and ends with a usage tip. No redundant information, highly efficient.

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

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

The description covers purpose and paywall, but does not specify the output structure or fields. With no output schema, more detail on the returned data would improve completeness. The context is adequate but not thorough.

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 parameters described in the input schema. The description adds no extra parameter-level context beyond what's already in the schema, so the baseline score of 3 applies.

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

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

The description clearly states it returns top at-risk borrowers across Aave, Morpho, and Spark, annotated with market intel and ranked by expected liquidation value. This specific verb and resource, combined with the paywall distinction, differentiates it from siblings like seneschal_list_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 explicitly advises using seneschal_paywall_info to inspect pricing before use, providing clear prerequisite guidance. It also explains the paywall behavior for free vs paying agents, though it lacks explicit 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?

No annotations provided, so description fully discloses behaviors: never submits to public mempool, user keeps custody (only signed bytes sent), relay is POST via x402, inspect is free and validates without relaying. Also notes info view returns builder set, price, caveats.

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 detailed yet concise, front-loaded with key use case and modes. Each sentence adds value. Slightly long but no 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 2 parameters, no output schema, and no annotations, the description is complete. Explains all three views, their purposes, and the relay mechanism. No gaps.

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

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

Schema description coverage is 100%, so baseline 3. Description adds context by explaining what each view does, but schema already describes parameters well. No additional semantics 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?

Description clearly states the tool provides front-run protection for sensitive transactions by relaying to private builders, never public mempool. It distinguishes three modes (info, inspect, relay) and differentiates from sibling tools which are unrelated.

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 lists use cases (puzzle/CTF/bounty claim, large approval revoke, first-touch interaction, NFT mint) and recommends inspect view to preview before paying. Could mention when not to use (e.g., non-sensitive txs) but overall 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 the description carries the full burden. It discloses important behavioral traits: prepaid credit meter, HMAC-signed webhooks, low_credit warning, and encryption of view keys. It does not mention rate limits or auth requirements beyond the paywall, but overall is fairly 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 that packs substantial information without being overly verbose. It could be structured into bullet points for clarity, but it is efficient and front-loaded with the key purpose.

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

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

The tool is complex (paywall, credit meter, encryption), and the description covers many aspects. However, it lacks explicit detail on the return value of the create call (e.g., what the immediate response is, whether it returns a watch ID). The webhook behavior is described, but the synchronous response is not clarified.

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%, but the description adds significant value beyond the schema: address formats for Monero and Zcash, view key formats, webhook URL restrictions, and birthday height defaults. This goes beyond the schema's minimal 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 verb ('subscribe') and resource ('Monero or Zcash address to view-key-based payment monitoring'), distinguishing the tool's core function. However, it does not explicitly differentiate from sibling tools like seneschal_private_watch_info or seneschal_private_watch_topup, so a slight deduction.

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 about payment (x402 paywall, credit meter) and topup alternatives, but lacks explicit guidance on when to use this tool vs. alternatives (e.g., when not to use it). The information is present but not structured as 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 present, so description carries full burden. Discloses that the phrase transits server with no logging/persistence, mentions network observer risk, and states UFVK is non-spending. Lacks explicit details on server handling during transit, but sufficiently transparent for an AI 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?

Concise paragraph with front-loaded purpose, followed by rate limit, security warning, alternative, and UFVK clarification. Every sentence adds value; no 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?

Covers core action, security, alternatives, output nature, and rate limits. Lacks error handling details, but sufficient given schema richness and lack of output schema. Minor gap in completeness.

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. Description only minimally adds beyond schema: restates phrase length and mentions rate limit (not parameter-specific). No additional semantic depth for 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?

Description clearly states the tool derives a UFVK from a BIP-39 mnemonic using NFPT's orchard-scanner CLI, distinguishing it from sibling tools that manage private watches. The verb 'derive' and resource 'UFVK' are specific.

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 usage context: free but rate-limited, security trade-off, and offline alternative. Warns about data exposure and clarifies UFVK is read-only. No guidance needed for sibling differentiation as purpose is distinct.

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 discloses that the view key never touches SQLite and is processed in memory only, plus pricing information.

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, each valuable: purpose, privacy guarantee, usage and pricing. No redundancy, front-loaded with core information.

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

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

Despite no output schema or annotations, the description covers privacy, pricing, default behaviors, and key parameter nuances, making it largely complete for effective use.

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

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

Schema coverage is 100% (baseline 3). The description adds key details like view key format, default for includeNotes, and auto-detection for birthdayHeight, exceeding schema.

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

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

The description clearly states the tool returns spendable and spent notes for a view key without setting up a watch, distinguishing it from sibling watch-related tools.

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

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

Explicitly says 'use this when you want to reconcile a wallet at a point in time,' providing clear context, though it does not mention when not to use it or list 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 provided, so description must cover behavioral traits. It states 'Free to call' suggesting no cost, but does not disclose rate limits, authentication needs, or side effects. The read-only nature is implied but not 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?

Two concise sentences. First sentence clearly states purpose, second adds cost note. 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 parameter-less info tool with no output schema, the description fully covers what is returned (price, chains, health, security notes). No critical missing 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?

Input schema has zero parameters with 100% coverage. No parameter explanation needed; description adds nothing beyond schema but baseline is 4 due to no parameters.

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

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

The description clearly states returns specific metadata (price, chains, health, security notes) for the view-key payment-monitoring service. It distinguishes from sibling tools like seneschal_private_watch_create (creation) and seneschal_private_watch_historical (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?

The description mentions 'Free to call' but does not explicitly state when to use this tool versus alternatives. It implies use for retrieving service metadata but lacks explicit when-not or alternative 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 provided, the description fully discloses key behaviors: it returns a URL for x402 POST, does not settle payment itself, and details tier pricing and idle/call costs. This gives the agent a clear understanding of what the tool does and doesn't do.

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

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

The description is three sentences, front-loads the core action, and every sentence adds value (purpose, tiers, payment behavior). No redundancy or fluff.

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

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

Given the tool has 3 parameters and no output schema, the description covers purpose, operation mode, and interaction pattern. Missing details like error handling or prerequisites, but these are not critical for basic usage. The depth is sufficient for an AI agent to invoke correctly.

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

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

Schema description coverage is 100%, so baseline is 3. The description does not add significant parameter-level meaning beyond the schema; it mentions 'watchId' and 'watchToken' implicitly by referencing 'existing watch', but relies on the schema's rich descriptions (e.g., tier enum with days). Thus, it meets but does not exceed the baseline.

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

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

The description clearly states the verb 'Add prepaid credit' to the resource 'existing Private Watch', specifies three tiers with prices, and distinguishes itself from siblings like 'seneschal_private_watch_create' and 'seneschal_private_watch_topup_crypto' by mentioning 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 use when an existing watch needs credit, and contrasts with the crypto topup sibling by specifying x402. It also notes the tool returns a URL for the agent to post to, providing interaction guidance. However, it does not explicitly state when not to use this tool or list alternative tools for other 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?

No annotations provided, so description carries full burden. Discloses free quote, payment detection, no spend key, no x402/API key. Does not mention error handling 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?

Description is well-structured and front-loaded with purpose. Slightly verbose but each sentence adds value. Good balance of detail.

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

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

Given no output schema, description explains the full workflow and references the info tool for limits. Missing details on quote response structure, but adequate for 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%, baseline 3. Description adds context for amountUsdCents (credit amount) and refers to info tool for limits. Chain enum explained briefly. Adds minimal extra value.

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 'Fund a Private Watch by paying in XMR or ZEC instead of USDC.' Verb 'Top up' with resource 'Private Watch' and distinguishes from sibling tool 'seneschal_private_watch_topup' which 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?

Explicitly states when to use (XMR/ZEC payment) and describes the process (quote, payment, polling). Lacks explicit 'when not to use' but context is clear.

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

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

With no annotations provided, the description carries full burden. It discloses the heuristic nature (not guaranteed), the analysis methods (verified-source payout-path analysis + bytecode value-exit scan), and the categories. It also mentions detail view is paid via x402. It does not explicitly discuss side effects, auth, or rate limits, but these are minimal for a read-only tool. Score 4.

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 is front-loaded with the core purpose and categories. Each sentence adds value, though it could be more structured (e.g., bullet points) for readability. It is dense but efficient, warranting a 4.

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

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

Given no output schema, the description adequately explains return structure: 'per-class counts + ETH-at-stake rollups + a teaser' for summary, 'full annotated watchlist' for detail. It covers all 5 parameters including the paid nature of detail view and the heuristic note. For a tool with moderate complexity, this is highly complete, earning a 5.

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% for all 5 parameters. The description adds context: explains view options (summary vs detail), the paid aspect of detail, single-contract verdict via address, and filter parameters (funded_only, classification). This goes beyond the schema and provides clear semantic meaning, earning a 5.

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

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

The description clearly defines the tool as classifying puzzle/CTF/bounty contracts into specific categories (locked_no_payout, frontrun_bait, etc.) based on payout-path analysis and bytecode scan. It distinguishes between summary and detail views, and mentions a single-contract verdict with address. This specificity and differentiation from sibling tools (none similar) justify a 5.

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 when to use summary vs detail views and mentions the heuristic nature (verify on-chain). It also describes the paid detail view and single-address option. However, it does not explicitly state when not to use the tool or compare to alternatives, which would push it to 5. Still, clear guidance earns a 4.

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

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

With no annotations, the description discloses speed (sub-50ms), cost ($0.001/call), data sources (SQLite + shadow-blocks, full nodes), and the need to consult /v1/q. It does not explicitly state it's read-only, but the semantics imply no destructive actions.

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

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

The description is compact with no filler. Every sentence adds value: purpose, speed, cost, families, input reference. Front-loaded with 'atomic single-fact endpoints designed for tight agent loops'.

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 states each answer is a yes/no or number. It also directs to /v1/q for input details. It could be slightly more explicit about response format, but it's sufficient for the tool's simplicity.

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

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

Schema coverage is 100%, but the description adds significant meaning: lists all question enum values in text, explains naming for privacy-chain questions, and describes the params object for DeFi vs privacy-chain (currently no params for privacy). This goes well beyond the schema's vague 'object' 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 provides atomic single-fact endpoints answering yes/no or number, sub-50ms, $0.001/call. It lists two fact families (DeFi and privacy-chain) and distinguishes from sibling tools which handle more complex queries like boards, borrowers, and watches.

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 these are designed for tight agent loops for quick facts, implying when to use. It mentions consulting /v1/q for per-question inputs, but does not explicitly state when not to use or provide alternatives. Implicitly, for more complex data, sibling tools should be used.

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 explains data content, outcome categories, and sorting order, but lacks details on read-only nature, pagination, or performance. Adequate but not extensive.

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 key details. Every sentence 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?

Given three optional parameters, no output schema, and several siblings, the description covers data type, sorting, and outcome categories. Could mention default limit or protocol filtering but schema handles that. Adequately complete.

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

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

Schema coverage is 100%, so baseline is 3. Description adds value by explaining the outcome classification in the data, which is not in parameter descriptions. This enhances 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?

Description clearly states it lists recent liquidations, distinguishes between outcomes, and specifies sorting. It is specific and distinguishes from sibling tools like list_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?

No explicit when-to-use or alternatives, but the context of liquidations and outcomes implies usage for tracking liquidation outcomes. Sibling list is present but no comparative 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?

No annotations are provided, so the description carries the full burden. It lists return data but does not disclose behavioral traits like data freshness, caching, or whether it queries live data. Being a read-only snapshot is implied but not 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 sentence that efficiently conveys the tool's purpose and output. While it is a bit long due to listing many items, it remains clear and front-loaded with the key idea 'Aggregate snapshot.'

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 zero parameters and no output schema, the description is remarkably complete. It enumerates all the data components needed to render a dashboard, leaving no ambiguity about what the tool returns. The sibling tools cover specific sub-queries, making this complete for its intended 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?

The input schema has zero parameters, so the description doesn't need to explain parameters. It adds value by detailing the exact metrics returned (e.g., total positions, debt under watch, HF histogram), which compensates for the lack of output 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 provides an 'Aggregate snapshot' for the public stats dashboard, listing specific data points. It distinguishes itself from sibling tools like seneschal_list_borrowers or seneschal_get_borrower by being a one-call overview.

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

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

The description explicitly says 'One call returns everything needed to render the dashboard,' indicating when to use it. It implies that for specific details (e.g., individual borrower info) sibling tools are appropriate, though not stated explicitly.

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