Peer

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

Annotations already mark this tool as readOnly and non-destructive, so the description is not burdened with the full safety profile. It adds that the read targets a current USDC balance, but provides no additional behavioral detail such as default-token behavior, edge cases, or error handling.

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?

A single front-loaded sentence with no filler; it states the verb and object immediately. 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?

With no output schema, the description does not explain the return value, and it never states whether 'address' or 'token' are expected given that no parameters are required. An agent lacks enough detail to know defaults or output shape, so the description is not complete on its own.

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

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

All three schema properties have descriptions, so schema coverages is high and the description does not need to carry parameter details. The description adds little semantic value for the parameters and may create confusion by calling the balance 'USDC' when the schema accepts a generic ERC20 token address.

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 ('read') and a specific resource ('current USDC balance for an address'), making the core action clear. However, it does not distinguish this from sibling balance-related tools, and its 'USDC' claim sits awkwardly alongside the generic 'token' parameter in the schema.

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?

There is no mention of when to use this tool over alternatives or any exclusions, despite a large sibling set that includes peer_stake_balance and several balance-adjacent tools. An agent receives no routing 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 readOnlyHint and idempotentHint already supplied, the description adds the important behavioral detail that the tool returns protocol-level history rather than trusted display identity. It does not enumerate the contents of the history, but the safety profile is already covered by 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 a single front-loaded sentence: it begins with the operation, states the scope, and ends with the purpose. There is no repetition of schema fields or annotations and 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?

For a one-parameter, read-only, idempotent endpoint without an output schema, the description gives enough information to select and invoke it: what is returned, from whom, and why. It could be more specific about the shape of 'protocol history' or how to source the address, but those are minor for this simple interface.

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

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

Schema description coverage is 0%, but the only required parameter is a clearly named address with a strict regex. The description adds meaning by tying that address to the order-matched buyer, so an agent can infer what value to pass; still, it never explicitly states 'address is the buyer's address.'

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 names a specific action ('Return protocol history') and a specific resource ('the buyer that matched an order'), and it frames the endpoint as a verification mechanism rather than a display-name lookup. This is enough to distinguish it from sibling tools such as peer_cash_order or peer_cash_fill_stats.

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

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

It clearly states the intended context: use it after an order match when an automation needs to assess delivery context and cannot rely on display identity. It does not name sibling alternatives or say when not to use it, so it stops short of a 5.

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

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

Annotations already declare readOnlyHint and idempotentHint, covering the safety profile. The description adds value beyond annotations by noting the data is 'live' and providing sequencing guidance ('before naming a rail or currency'). This gives useful behavioral context about real-time data and expected call order.

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 with no filler. The first sentence front-loads the return categories, and the second provides a clear usage directive. 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?

The tool has only one optional parameter fully documented in the schema, and no output schema. The description enumerates the return categories and states when to call it. For a simple discovery tool with no required parameters, an agent has everything needed to invoke it correctly.

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

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

Schema description coverage is 100%, so the includeRelaySources parameter is already fully documented in the schema. The description does not add any additional parameter-level semantics. 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 uses a specific verb ('Return') and enumerates a precise set of resources: 'live Base USDC destinations, payout platforms, fiat currencies, payee hints, amount bounds, and pricing.' This clearly differentiates it from sibling tools like peer_cash_source_capabilities or peer_config_currencies by the specific data it returns. The purpose is immediately understandable.

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

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

The phrase 'Call this before naming a rail or currency' gives an explicit when-to-use directive. It conveys that this tool is a prerequisite for other operations that require selecting a rail or currency. It does not, however, name alternative tools or state when not to use it, so it stops short of a 5.

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

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

Annotations already declare readOnlyHint and idempotentHint, so the safety profile is covered. The description adds valuable behavioral context beyond annotations: the result is non-binding and the actual rate is determined at fill time, which is important for an agent deciding whether to treat the output as final.

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 with no filler. The core purpose is front-loaded, and the critical caveat about non-binding rates is placed in the second sentence where it naturally reinforces the estimate nature without burying the main point.

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

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

For a read-only estimate tool with fully documented parameters, the description is nearly complete. It explains the rate mechanism, the estimate's non-binding nature, and when the final rate resolves. It does not explicitly state the response shape, but no output schema exists and the title plus purpose make the expected result clear enough.

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

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

Schema description coverage is 100%, so the baseline is 3. The description confirms the domain (Base USDC and fiat) but adds no additional meaning about the amount format, currency semantics, or optional platform parameter 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?

States a specific verb ('Estimate'), resource ('fiat received for Base USDC'), and rate source ('live Chainlink oracle rate'). Explicitly contrasts itself with a locked quote, which distinguishes it from quote-like sibling tools without needing to open their schemas.

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

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

The description provides clear context on when to use the tool: to get an estimate at the live oracle rate. The explicit 'not a locked quote' exclusion and the note that the binding rate resolves when a buyer fills give useful guidance, though it does not name a specific alternative tool like peer_quote.

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?

Annotations already declare readOnlyHint and idempotentHint, and the description does not contradict them. It adds valuable behavioral context: the data is trailing 30-day, historical, and explicitly not a guarantee of future performance—useful caveats beyond the structured 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?

Two sentences with no filler. The first sentence states exactly what is returned and how it is grouped; the second captures the caveat. 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 zero-parameter read-only stats endpoint, the description covers the return content, time window, grouping, and a usage caveat. Combined with readOnly/idempotent annotations and no output-schema requirement, nothing essential is missing for an agent to call it and interpret results.

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 takes zero parameters and schema description coverage is 100%, so there are no parameter semantics to clarify. The description focuses on the output dimensions (counts, timing, platform, currency) rather than inputs, which is appropriate for a no-parameter tool.

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

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

The description uses a specific verb ('Return') and specifies the resource ('trailing 30-day fill counts and first-fill timing'), the grouping dimensions ('by payout platform and currency'), and the time window. This clearly distinguishes it from other peer_cash_* tools like peer_cash_estimate or peer_cash_quote_source.

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

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

It states the intended use case ('historical routing evidence') and adds a strong exclusion ('never as a guarantee'), which tells the agent this is diagnostic, not predictive. However, it does not explicitly name alternative tools such as peer_cash_estimate for forward-looking needs, so it falls just short of full routing 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?

The annotations already declare readOnlyHint and idempotentHint, so the description is not burdened with stating those. It adds useful behavioral context: the operation is a read/resolution step that depends on host confirmation of the createDeposit transaction.

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

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

Two sentences, no wasted words. The main action is front-loaded and the precondition is stated immediately afterward in a clear, direct way.

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 single-parameter read-oriented tool with annotations covering safety and idempotency, the description provides the key inputs and the timing constraint. It mentions the output concept ('resumable Peer deposit id') but does not specify the return shape or error behavior, which 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 description coverage is 0%, so the description must compensate for transactionHash semantics. It indirectly implies the hash is the confirmed Base createDeposit receipt, but it never explicitly names the parameter or states that transactionHash is the receipt hash. The one-parameter schema keeps this usable, but the mapping is left to inference.

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 names a specific action ('Read a confirmed Base createDeposit receipt') and a specific outcome ('resolve the resumable Peer deposit id'), clearly distinguishing this finalization tool from the many read/show/list siblings. The title reinforces the purpose without 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?

The description gives an explicit precondition: 'Call only after the host confirms the createDeposit transaction.' This tells the agent when it is appropriate to call the tool, though it does not name alternative tools or explicitly state when not to use it.

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

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

Annotations already establish readOnlyHint and idempotentHint, so the description adds real value by disclosing a potential indexer-lag behavior, the transient ORDER_NOT_FOUND response, and safe retry semantics. This goes beyond the structured annotations without contradicting them.

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 tight sentences: the first states the core behavior and return contents, the second gives a necessary operational warning. No filler, and the most important information 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?

For a one-parameter read-only tool with annotations, the description covers what is returned, the lookup key, and the notable error/retry case. No output schema exists, but the description lists the high-level fields returned, which is sufficient for an agent to decide whether to call this tool.

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

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

Schema description coverage is 0%, so the description must carry more weight. It clarifies that depositId is the lookup key, and the schema provides the precise regex pattern and required flag. It does not explain how to obtain a depositId, but the single unambiguous parameter keeps this adequate.

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 ('Return') and identifies the exact resource and scope: one order's state, amounts, fills, and next actions, keyed by deposit id. This clearly distinguishes it from plural/list siblings like peer_cash_orders.

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

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

The description gives concrete operational guidance: after finalization, a brief ORDER_NOT_FOUND may be indexer lag, so retry this read and never the deposit transaction. However, it does not explicitly state when to prefer this tool over sibling read tools, such as peer_cash_orders or peer_deposit_show.

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?

Annotations already declare readOnlyHint and idempotentHint, so the safety profile is covered. The description adds useful scoping context ('owned by a maker wallet', 'still need attention'), but it does not disclose behaviors like default limit behavior, sorting, or whether inFlight maps exactly to 'needs attention'.

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

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

The description is a single, front-loaded sentence with no filler. Every part adds information about scope or optional filtering.

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 three flat parameters and no output schema, the description plus schema are minimally adequate. However, the lack of output shape, limit semantics, and clearer inFlight meaning leaves some gaps for an agent deciding how to invoke and interpret the result.

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 description coverage, the description must compensate. It vaguely maps 'owner' to 'maker wallet' and 'inFlight' to 'orders that still need attention', but it does not explain the 'limit' parameter, and the inFlight mapping is ambiguous. This is only partial compensation for the schema's lack of 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 states a specific verb ('List'), resource ('Peer Cash orders'), and scope ('owned by a maker wallet'). It clearly conveys what the tool does, though it does not explicitly differentiate it from sibling list tools such as peer_cash_order or peer_pv_intent_list_owner.

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: call this to list orders for a given maker wallet, with an optional filter for orders needing attention. However, it provides no explicit guidance on when to prefer this over related list/fetch tools, nor any exclusions or 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?

Despite readOnlyHint=true already signaling non-mutation, the description adds valuable context: the response contains unsigned transaction data and the tool never signs or submits it. This clarifies the exact boundary of the tool's 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 concise sentences with no filler. The primary action is front-loaded, and the safety qualifier about not signing or submitting 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?

The combination of a fully documented schema, read-only annotation, and a description that clarifies the unsigned nature of the response is sufficient for an agent to invoke the tool correctly. It lacks explicit routing among sibling quote tools, but that is not a critical gap here.

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 schema already documents all parameters. The description adds domain framing ('EVM source asset', 'Base USDC') but no new parameter-level detail 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 uses a specific verb ('Quote') and identifies the resource: a live Relay route from an EVM source asset into Base USDC. It clearly states the tool's function, though it does not explicitly name a sibling tool to differentiate it from peer_cash_estimate or peer_quote.

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—call this when you need a quote for a Relay route—but does not state when to use it versus alternatives or when not to use it. No explicit exclusion or naming of sibling tools is provided.

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?

Annotations already provide readOnlyHint=true and idempotentHint=true, so the description does not need to restate those. It adds useful context: the tool is for previously submitted routes and should be retried rather than treated as a submission mechanism. The 'never resubmit' warning is a meaningful behavioral safeguard beyond the 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 two tight sentences with no filler. The first sentence front-loads the core purpose and resource, and the second adds essential operational guidance. 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 low-complexity, read-only, idempotent status lookup with one required parameter, the description covers the essential workflow: given a Relay request ID, track the previously submitted route, and retry rather than resubmit. There is no output schema, and the description does not detail return statuses or error behavior, but the core decision an agent needs to make is well supported.

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 description coverage, the description carries the burden of explaining the parameter. It clarifies that requestId is a 'Relay request ID' associated with a previously submitted cross-chain source route. It does not specify format or origin, but the single self-named parameter is simple enough that this level of context is sufficient for an agent to supply the correct 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 states a specific action ('Track') on a clear resource ('previously submitted cross-chain source route') identified by 'Relay request ID.' It accurately conveys this is a status/read tool and differentiates it from sibling submission tools like peer_cash_order and peer_cash_finalize, which would be used for new submissions.

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

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

The description gives explicit operational guidance: 'Retry this read; never resubmit from an unknown status.' This tells the agent when to call this tool (when polling or rechecking a previously submitted route) and when not to (rather than resubmitting an order/route when status is unknown). This is strong routing guidance even without naming a specific sibling.

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?

Annotations already declare readOnlyHint=true and idempotentHint=true, so the safe read-only nature is covered. The description adds value by indicating the returned data is 'live' and scoped to 'Relay-supported' sources routing into Base USDC, which is useful behavioral context beyond the annotations. 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 a single, concise sentence that is front-loaded with the core purpose ('Return live Relay-supported...'). Every word contributes meaning—no filler or redundancy. It is appropriately sized for a simple discovery tool.

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

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

For a zero-parameter, no-output-schema tool, the description conveys the essential information: what is returned (source chains and tokens) and the condition ('before a Peer Cash order'). It does not specify the exact output format, but given the simplicity and that annotations cover safety, it is sufficiently complete for an agent to understand when and how to invoke it.

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

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

The tool has zero parameters, so there is nothing to describe beyond the schema, which is empty. Per the calibration guidance, a baseline of 4 is appropriate when there are no parameters. The description does not need to elaborate on parameter meaning, since none exist.

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

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

The description clearly states a specific action ('Return') and a specific resource ('live Relay-supported EVM source chains and tokens that can route into Base USDC'). It is distinct from siblings like peer_cash_capabilities (broader) and peer_cash_quote_source (likely about quotes) by focusing on source assets for a Peer Cash order. The purpose is unambiguous and well-scoped.

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 'before a Peer Cash order', providing clear timing context. However, it does not mention any alternative tools (e.g., peer_cash_quote_source or peer_cash_capabilities) or specify when NOT to use this tool. The guidance is adequate but lacks exclusions or alternative routing, which would help an agent choose among the many peer_cash_* siblings.

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

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

Annotations already indicate read-only and non-destructive behavior. The description adds the 'local cache fallback' detail, which is useful context beyond the annotations, but it does not explain when the fallback triggers, how stale cached data might be, or any other behavioral implications.

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

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

The description is a single front-loaded sentence with no filler. It names the action and resource first and adds only the cache-fallback detail, which is the one meaningful behavioral qualifier.

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 schema covers parameters and annotations cover the safety profile, but there is no output schema and the cache fallback is left under-specified. The tool would be easier to invoke correctly if it explained when fallback data is used and what the response contains. Still, for a simple read-only list call, the definition is minimally adequate.

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

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

All four parameters (page, params, status, pageSize) have descriptions in the schema, so the description does not need to restate them. The description itself adds no additional parameter meaning, such as how status filtering works or how 'params' interacts with typed fields.

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

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

The description states a specific verb ('List') and a specific resource ('checkout sessions from the Pay API'). It clearly separates listing from the sibling peer_checkout_show, but it does not explicitly contrast with other list tools or describe when a checkout session is the right resource.

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 given about when to use this tool instead of peer_checkout_show or any sibling list tool. There are no exclusions, alternatives, or conditions such as 'use this when you need all checkout sessions' or 'use show for a single session.'

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?

Annotations already declare readOnlyHint=true and destructiveHint=false, so the description only needs to add non-obvious behavior. It does add the polling aspect, which is useful, but it does not disclose response shape, error behavior, or polling semantics—so the added value is moderate.

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

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

The description is a single front-loaded sentence that states the primary action first and appends the polling behavior without filler. 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 one-required-parameter read tool with readOnly annotations, the description is sufficient for selection and initial invocation. It omits return-format details and polling cadence, but the low complexity and clear schema make these minor 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 coverage is 100%, with sessionId described as 'Session identifier' and params documented as optional raw JSON. The description adds no parameter-level meaning beyond the schema, so the schema carries the semantic burden and the baseline of 3 is appropriate.

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

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

The description names a specific resource ('single checkout session') and action ('Show'), and the 'or poll its latest status' adds behavior that distinguishes it from peer_checkout_list and other show-type siblings. The scope is clear and immediately usable.

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 a single checkout session needs to be retrieved or polled, but it never explicitly names alternatives or conditions for when to prefer this tool. The 'single' wording hints at differentiation from list tools, but the guidance remains implicit rather than stated.

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 readOnlyHint and destructiveHint annotations already cover the tool's safety profile, so the description does not need to restate it. It adds only scope ('fiat'), but no behavior beyond what the annotations imply; this is acceptable for a trivial list endpoint.

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

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

A single front-loaded sentence containing only the essential verb and object. There is no filler, and for a zero-required-parameter list tool this is an ideal length.

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

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

For a read-only, zero-required-parameter list operation, the description is nearly complete: an agent knows what it does and that no input is needed. It could mention the return shape (e.g., an array of currency codes) since no output schema exists, but 'List' makes the expected result 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?

The only parameter is an optional raw JSON passthrough that the schema already describes at 100% coverage. The description adds no parameter detail, but none is needed because no required or typed 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?

Describes a concrete operation ('List') on a specific resource ('supported fiat currencies'), which is immediately useful. It does not explicitly distinguish this from sibling peer_market_meta_currencies, though the word 'fiat' narrows the scope.

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

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

The intended use is inferable: call when you need the configured fiat currency list. However, the description gives no guidance on when to prefer this over related config/market metadata tools, nor any exclusions.

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

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

The annotations already declare readOnlyHint=true and destructiveHint=false, and the description's 'List' verb is consistent with those. The description adds no further behavioral context such as response shape, ordering, or handling of the optional params object, but for a simple read-only listing this is acceptable.

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 entire description is a single clear, front-loaded sentence with no filler. Every word contributes to the meaning.

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

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

For a zero-required-parameter read-only tool, the description is nearly sufficient. The main gap is ambiguity around what 'platforms' means and why an agent should choose this over sibling tools like peer_market_meta_platforms, especially given no output schema.

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

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

Schema description coverage is 100%, and the only parameter is an optional raw JSON passthrough with no typed fields to clarify. The description therefore does not need to add parameter detail, and the schema already carries that information.

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

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

The description states a specific verb and resource: 'List supported payment platforms.' This clearly conveys the core function. However, it does not distinguish itself from similar sibling tools such as peer_market_meta_platforms or peer_config_currencies.

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 given about when to use this tool versus related alternatives like peer_market_meta_platforms or peer_config_currencies. There is no context about intended callers or situations, so an agent must infer usage 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?

Annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds one useful behavioral detail: the output is a merge of stored config and current global flags. It does not go deeper into conflict-resolution semantics or output shape, so it adds modest value beyond the 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 a single, focused sentence with no filler. The key action and resource are stated up front, and nothing is redundant.

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-only show tool with no required parameters and no output schema, the description conveys what the agent needs to invoke it correctly. It could be slightly more complete by noting how the optional params field interacts with the merge, but overall it is sufficient.

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

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

Schema description coverage is 100%, with a single optional 'params' field described in the schema itself. The tool description does not add extra meaning to that parameter, so the baseline score of 3 is appropriate.

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

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

The description uses a specific verb ('Show') and identifies the exact resource ('stored Peer CLI config merged with current global flags'). This clearly distinguishes it from sibling config tools like peer_config_currencies and peer_config_platforms, which target narrower subsets.

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 makes the tool's purpose clear but gives no explicit guidance on when to use it versus siblings such as peer_config_currencies or peer_config_platforms. An agent can infer it is for viewing merged CLI configuration, but no alternative or exclusion criteria are stated.

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?

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is established. The description adds the 'current controller-based' scope, which clarifies that this shows present delegation rather than historical or indexer data. It does not provide additional behavioral context such as response format, potential errors, or data freshness semantics.

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, efficient sentence that front-loads the operation and the object it operates on. Every word contributes to the core meaning with no filler or redundant restatement.

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-only tool with clear annotations and well-described parameters, the description is minimally adequate. However, with no output schema, it does not explain what the returned delegation information contains, and the phrase 'controller-based delegation' is left undefined, which could leave an agent guessing at the exact semantics.

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

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

Schema description coverage is 100%, so the input schema already explains escrow, deposit, and the raw params passthrough. The tool description does not add meaning beyond the schema, but with full coverage the baseline of 3 is appropriate.

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

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

The description uses a specific verb and resource: 'Show current controller-based delegation for a deposit.' This is clear about the operation's core purpose. However, it does not differentiate itself from nearby siblings like peer_indexer_delegations_by_deposit or peer_deposit_show, so an agent must infer which tool is appropriate.

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

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

The description gives no guidance on when to use this tool versus alternatives such as peer_deposit_show, peer_deposit_show_many, or peer_indexer_delegations_by_deposit. It states only what the tool does, not the conditions that would select it over other peer_* 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?

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds useful scoping behavior (configured wallet fallback vs explicit owner) but does not disclose pagination, ordering, or the effect of passing raw params. This is acceptable but not rich.

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

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

The description is a single concise sentence with no filler. The core verb, resource, and scoping mechanism are front-loaded, and every word contributes to understanding the tool.

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-only list tool, the description and annotations cover the essentials: safety, owner semantics, and parameter purposes. However, there is no output schema and no mention of the return shape, pagination, or limits, and the tool is not differentiated from several similar sibling list tools. The agent can likely invoke it correctly, but some context is missing.

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 both parameters already have descriptions. The tool description adds meaningful semantics by clarifying that omitting 'owner' uses the configured wallet while supplying it overrides that, and by indicating that 'params' is optional raw JSON merged below typed fields.

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 names a specific verb and resource ('List deposits') and gives the ownership scope: 'configured wallet or explicit owner.' It is clear about what the tool does, though it does not explicitly distinguish itself from sibling deposit-list tools such as peer_pv_deposit_list_owner or peer_indexer_deposits_list.

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 primary use case: list deposits for either the configured wallet or a caller-supplied owner. However, it provides no explicit guidance about when not to use this tool or which alternative to choose among the many deposit-related 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?

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description's 'Show' aligns with that safe profile. The description adds no further behavioral context such as return format, field expansions, or error behavior, but for a simple read-by-ID the annotations carry the main safety burden.

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

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

The description is a single front-loaded sentence with no filler. It efficiently states the verb, object, and how the object is identified.

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-only lookup with one required parameter and readOnly/destructive annotations, the description is mostly sufficient for correct invocation. Minor gaps remain: no output schema exists, the return contents are not described, and the relationship to many sibling deposit-show tools is left unclear.

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

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

Schema description coverage is 100%, and the schema already describes depositId as 'Deposit ID,' so the baseline is 3. The description merely restates 'by deposit ID' and adds no new meaning about the params object, ID format, or expected values.

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

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

The description uses a specific verb ('Show'), a clear resource ('a single deposit'), and the identifying key ('deposit ID'), which distinguishes it from deposit_list and deposit_show_many. However, it does not name any sibling or clarify how it differs from other deposit-show tools such as peer_pv_deposit_show or peer_indexer_deposits_show.

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 given for when to use this tool versus alternatives like peer_deposit_list, peer_deposit_show_many, peer_pv_deposit_show, or peer_indexer_deposits_show. The intended use case is only implied by the tool name and the required depositId parameter.

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?

Annotations already declare readOnlyHint=true and destructiveHint=false, and 'Show' is consistent with a read operation. However, the description adds no behavioral context beyond that: no mention of missing/invalid ID handling, batch limits, ordering, or what is returned. With annotations carrying the safety profile, the description contributes little extra transparency.

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

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

The description is a single front-loaded sentence with no wasted words. It states the verb, resource, and key scoping attribute efficiently, which is appropriate for conciseness even though other dimensions need more content.

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

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

For a batch-lookup tool, the four-word description is too thin. With no output schema and no stated encoding for the 'ids' string, an agent lacks sufficient information to reliably construct a valid call. The read-only annotations help, but they do not compensate for the missing operational details.

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

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

Schema coverage is 100%, giving baseline 3, and the description adds no meaningful parameter detail beyond the schema. The critical ambiguity remains: 'ids' is a string labeled 'Deposit IDs' but the description does not clarify whether multiple IDs are comma-separated, JSON-encoded, or repeated.

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

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

The description states a clear verb ('Show'), a specific resource ('deposits'), and a distinguishing scope ('multiple ... by ID'). This differentiates it from the singular peer_deposit_show and from list-based tools like peer_deposit_list, so an agent can immediately understand what this tool is for.

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

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

The description gives no guidance about when to choose this tool over alternatives such as peer_deposit_show, peer_deposit_list, or peer_indexer_deposits_by_ids. There is no stated context, exclusions, or sibling differentiation beyond the implicit 'multiple' in the name and description.

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?

Annotations already establish readOnlyHint=true and destructiveHint=false. The description adds no behavioral detail beyond the core check, such as whether it returns a boolean, whether it performs any network resolution, or whether a missing deployment is an error. It does not contradict the annotations, so this is a safe 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?

A single, front-loaded sentence that states the action and object without filler. It is appropriately sized for a simple availability check.

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

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

For a zero-required-parameter read-only check, the description is sufficient: an agent can call it to learn whether IntentGuardian is deployed. The phrase 'selected environment' is not defined, but it likely refers to a global context, and the implied boolean outcome is enough given the absence of an output schema.

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

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

The schema has one optional raw 'params' field with no required or typed semantic parameters; schema coverage is effectively complete. The description adds no parameter-specific detail, but none is needed because there are no meaningful inputs to explain.

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

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

The description states a specific action ('Check') and resource ('environment...IntentGuardian deployment'). It clearly conveys an availability probe and distinguishes it from the peer_guardian_* siblings, which target policy and funding concerns. It does not explicitly name an alternative, so it stops short of 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?

There is no guidance on when to use this tool versus any peer_* alternative. The description only states what it checks, leaving the agent to infer from the name and context that it is a preliminary availability probe. No exclusions or routing conditions are provided.

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?

Annotations already provide readOnlyHint=true and destructiveHint=false, and the description aligns by saying 'Read'. It adds useful context that the allowance is scoped to IntentGuardian, but it does not disclose output format, units, or edge-case behavior.

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

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

One compact, front-loaded sentence with no filler. The action and object are immediately clear.

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-only tool with two required parameters, the description conveys the core result (balance and allowance) and is supported by safety annotations. However, since there is no output schema, the absence of return shape or units is a small but notable 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 description coverage is 100%, covering payer, token, and params. The description adds minimal extra meaning beyond the schema, such as 'deposit token' and 'available to IntentGuardian', but not enough to 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?

States a specific read operation on two well-defined resources: payer token balance and allowance. It also names the spender context (IntentGuardian), making it distinct from sibling read/balance 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?

Provides no guidance on when to use this tool versus sibling tools such as peer_balance, peer_guardian_available, or peer_guardian_policy. No exclusions or alternative routing are 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?

Annotations already declare readOnlyHint=true and destructiveHint=false, which the description supports by using 'Read'. The description adds the 'live' qualifier, indicating real-time data, but does not disclose other behaviors such as response format or error handling. Given the annotations cover the safety profile, a 3 is appropriate.

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, concise sentence that is front-loaded with the action. There is zero filler, and every word contributes to clarifying the tool's 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?

This is a simple read-only tool with no required parameters and a clear purpose. The description adequately conveys what is being read, and the lack of an output schema or complex behavior means minimal additional context is needed. It is slightly above average but not exhaustive.

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

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

Schema description coverage is 100%, and the single optional 'params' field is documented generically for raw JSON. The description does not add any parameter-specific meaning beyond what the schema already provides, so it relies on the schema, which is sufficient.

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

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

The description states a specific verb ('Read') and a specific resource ('live IntentGuardian fee and extension policy'). It clearly identifies what the tool does, though it does not explicitly differentiate from sibling guardian tools like peer_guardian_available or peer_guardian_quote_extension.

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. The description simply states the action without context about when this policy read is appropriate or when to prefer another guardian-related 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?

Annotations already mark the operation as read-only and non-destructive. The description adds the context that the cost is "authoritative" and "on-chain," but it does not disclose quote expiry, failure modes, or whether the quote is binding. This is acceptable given the annotations but not rich.

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

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

The description is a single, front-loaded sentence with no filler. Every word contributes to identifying the operation and its scope.

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 only two required, well-documented parameters and the annotations cover safety, so the description is minimally sufficient. However, with no output schema, the description does not clarify the returned cost format, units, or how to interpret the quote, leaving some ambiguity for an agent.

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

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

Schema description coverage is 100%, so the input schema already documents intentAmount and additionalSeconds well. The description does not add semantic detail beyond what the schema provides, matching the baseline expectation.

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

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

The description uses the specific verb "Quote" and identifies the exact resource: the authoritative on-chain cost to extend an intent. This clearly distinguishes the tool from the many sibling quote-related tools by scoping it to the extension use case.

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

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

The phrase "to extend an intent" implies when the tool should be used, but the description gives no explicit exclusions or alternatives. With siblings like peer_quote and peer_cash_quote_source present, an agent must infer how this quote tool differs and when to prefer 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?

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds a little context ('via the indexer', 'composite deposit ID') but does not disclose behavior such as missing-record handling, pagination, or response shape. No contradiction with 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 a single sentence with no filler. The verb and object are front-loaded, and every word contributes to identifying the tool's 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?

For a simple, read-only fetch with one required parameter and high schema coverage, this description is close to sufficient. However, there is no output schema, no explanation of the 'options' behavior, and no mention of error cases or relationship to similar sibling tools.

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 depositId, params, and options are already documented. The description mostly restates 'composite deposit ID' from the schema and adds no meaningful parameter-level semantics beyond that.

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

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

The description states a specific verb ('Fetch'), a resource ('delegation record'), and a scope ('via the indexer', 'composite deposit ID'). It is clear and unambiguous, though it does not explicitly differentiate itself from sibling delegation-related tools.

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

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

The description provides no guidance on when to choose this tool over alternatives, no exclusions, and no context about prerequisites. An agent can only infer when to use it from the tool name and the nature of the lookup.

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?

Annotations already mark the tool as read-only and non-destructive. The description adds a minimal note about fetching multiple deposits by composite ID, which is consistent with annotations, but it discloses no other behaviors (e.g., pagination, error handling, or result format). With annotations covering safety, this is acceptable but not rich.

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

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

The description is a single, front-loaded sentence: 'Fetch multiple deposits by composite ID.' It contains zero filler and directly conveys the primary action and scope, making it perfectly concise and well-structured for quick parsing.

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

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

For a tool with two parameters, no output schema, and many siblings, this description is too sparse. It omits essential context like what a 'composite ID' is, how to pass multiple IDs, the shape of the returned data, and when to prefer this tool over peers. An agent would struggle to call it correctly without further investigation.

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 both properties (ids and params), so the baseline is 3. The tool description adds no extra meaning beyond the schema—it doesn't clarify what a composite ID is, how to format multiple IDs, or what params may contain. The schema descriptions themselves are also vague, but the tool description neither compensates nor contradicts.

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

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

The description clearly states the action ('Fetch') and resource ('multiple deposits') using a specific verb and noun. It conveys that this tool retrieves multiple deposits by composite ID, distinguishing it from single-deposit tools, though it doesn't explicitly name alternatives or edge cases.

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 the many sibling tools like peer_indexer_deposits_show or peer_deposit_show_many. The description offers no context about prerequisites, exclusions, or selection criteria, leaving the agent to infer usage 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?

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds that this fetches multiple deposits with relations, but it does not clarify what 'relations' means, how many IDs are accepted, or what happens with invalid or missing IDs.

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

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

The description is a single front-loaded sentence with no filler or redundant restatement. It earns its place by naming the action, resource, and distinguishing 'relations' qualifier.

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 large sibling family and the absence of an output schema, the description is too thin. It does not explain what 'relations' are returned, how 'composite ID' is formatted, or how this differs from close siblings peer_indexer_deposits_by_ids and peer_indexer_deposits_list_relations.

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 high and all properties have descriptions, so the baseline is 3. The tool-level description adds no parameter detail beyond what the schema already says, and the schema descriptions themselves are vague ('Composite IDs.', 'Relation options.'), so it does not elevate the score.

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

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

The description states a specific action ('Fetch'), a resource ('multiple deposits'), and a differentiator ('with relations by composite ID'). It is clear enough to distinguish from a plain fetch, but it does not explicitly contrast with the very similar sibling peer_indexer_deposits_by_ids or peer_indexer_deposits_list_relations.

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?

There is no guidance on when to choose this tool over alternatives such as peer_indexer_deposits_by_ids or peer_indexer_deposits_show. The phrase 'by composite ID' only implies a data shape, not a decision rule 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?

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description's 'Fetch' is consistent with them. It adds little behavioral context beyond that, such as result ordering, pagination, or scope constraints, but it does indicate the kind of data returned (fund activities).

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, front-loaded, and free of filler. Every word contributes meaning: the verb, the resource, and the scope are all present.

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-only fetch with one required parameter, the description plus schema is mostly sufficient. However, with no output schema and no note distinguishing it from peer_indexer_makers_fund_activities, an agent cannot fully infer the response shape or when this endpoint is the correct choice.

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 schema already documents depositId as a 'Composite deposit ID' and params as raw JSON. The description itself adds no extra meaning about how to construct or interpret the parameters.

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

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

States a concrete verb ('Fetch'), an object ('fund activities'), and a scope ('for a deposit'), so an agent can tell it apart from most siblings. It doesn't explicitly contrast with the closely named peer_indexer_makers_fund_activities, which keeps it from a top score.

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

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

The description gives no guidance on when to use this tool versus alternatives. The sibling list includes peer_indexer_makers_fund_activities and peer_indexer_query, but no condition, exclusion, or routing hint is provided.

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?

Annotations already state readOnlyHint=true and destructiveHint=false, so the description only adds 'via the indexer' as a source context. It does not disclose pagination behavior, filtering semantics, or response shape, but for a read-only listing tool with safe annotations this is adequate but minimal.

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, direct sentence with no filler or redundancy. It is front-loaded and easy to parse, though it could have included more useful usage detail without harming conciseness.

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

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

The context is complex: no output schema, nested recursive filter and pagination objects, and dozens of related deposit and indexer tools. The description does not explain what a deposit listing includes, how filtering/pagination behave, or how this differs from sibling list variants, leaving the agent under-informed for correct invocation.

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

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

The schema has 100% property description coverage, so the baseline is 3. However, the schema descriptions are generic ('Filter object.', 'Pagination object.') and the tool description adds no detail about valid filter fields or pagination syntax.

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 'List' and resource 'deposits', and names the data source 'via the indexer'. This distinguishes it from non-indexer deposit list tools, though it does not clearly differentiate it from closely related siblings like peer_indexer_deposits_by_ids or peer_indexer_deposits_list_relations.

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

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

The description provides no guidance on when to use this tool versus alternatives. Given the large sibling group (peer_deposit_list, peer_indexer_deposits_by_ids, peer_indexer_deposits_list_relations, etc.), the absence of exclusions or alternative routing leaves usage ambiguous.

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?

Annotations already mark this as read-only and non-destructive, so the safety profile is covered. The description adds only the related-entities behavior and the indexer source; it does not disclose pagination, relation-loading cost, or result shape.

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 definition is a single front-loaded sentence with no filler, redundancy, or restatement of the tool name. It is concise while still stating the basic verb and resource.

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 four nested-object parameters, no output schema, and no explanation of what 'related entities' includes or how filter, params, options, and pagination interact, the description leaves important calling decisions unexplained. It works as a label but not as a complete usage guide.

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 each parameter has at least a terse description such as 'Filter object', 'Relation options', and 'Pagination object'. The tool description itself adds no parameter meaning beyond what the schema already carries.

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 names a specific action ('list') and resource ('deposits') and adds the distinguishing feature 'with related entities', which separates it from the plain peer_indexer_deposits_list sibling. However, 'related entities' is undefined, so it does not fully disambiguate from peer_indexer_deposits_by_ids_relations.

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

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

The phrase 'with related entities' implies this tool should be used when related entities are needed, but the description never explicitly states when to choose it over the plain list or by-ids variants. No exclusions, prerequisites, or alternative tool names are provided.

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 read-only and non-destructive hints are already provided by annotations, and the description aligns with them. It adds the useful context that this reads through the indexer, but it does not disclose behavior for missing deposits, composite ID format, or relation expansion.

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

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

The description is a single, front-loaded sentence with no wasted words. It clearly conveys the action, resource, key parameter, and data source.

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 simple with one required parameter, but the description omits composite ID syntax, return behavior, and explicit differentiation from the many deposit-related sibling tools. It is minimally viable but leaves the agent to infer important selection and invocation details.

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

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

Schema descriptions cover 100% of parameters, so the baseline is 3. However, the description itself adds no meaning beyond the schema; 'Composite ID.' is generic and does not explain what form the composite ID takes or how params/options affect the request.

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

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

The description states a specific action ('Fetch'), a resource ('a deposit'), and a distinguishing mechanism ('via the indexer') plus a key identifier ('composite ID'). It is clear enough to separate this tool from peer_deposit_show and list-style siblings, though it does not name alternatives explicitly.

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 given about when to prefer this tool over sibling tools like peer_indexer_deposits_by_ids or peer_deposit_show. The phrase 'via the indexer' implies a context, but there are no exclusions, prerequisites, or alternative routing instructions.

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?

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds only 'daily snapshots,' implying a historical list, but does not mention pagination, ordering, or what the response contains. For a tool with a limit parameter, this is sparse 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 a single, concise sentence with no filler. It is front-loaded with the core verb and resource, and every word earns its place. There is zero waste.

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

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

For a tool with no output schema and only a vague description, an agent may not understand what a 'daily snapshot' entails, how the composite depositId works, or how the limit affects results. The description omits details that would help an agent call it correctly, even though annotations cover safety.

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 all three parameters have descriptions. The tool description itself adds no parameter-level meaning. The baseline for high coverage is 3, and while the parameter descriptions are minimal, the schema does carry the weight. The cryptic 'params' raw JSON is not clarified by the tool description either.

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

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

The description states a specific verb ('fetch') and resource ('deposit daily snapshots'), which clearly indicates the operation. However, it does not differentiate from sibling tools like peer_indexer_deposits_show or peer_deposit_show, which might also return deposit data. It is clear but lacks explicit sibling distinction.

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. There are many related deposit and indexer tools in the sibling list, but the description does not mention any conditions, exclusions, or alternatives. An agent has no clue when to pick this over peer_indexer_deposits_show.

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?

Annotations already declare readOnlyHint=true and destructiveHint=false, so the fetch semantics are safe and the description does not contradict them. The description adds only the 'multiple deposits' scope and the indexer as the source, but says nothing about pagination, ordering, or response 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?

A single, front-loaded sentence with no filler. Every word contributes to identifying the operation, and it is easily scannable.

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

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

For a read-only fetch with complete parameter descriptions, the core action is clear; however, there is no output schema and no mention of return shape, status filtering behavior, or conditions under which the call should be made. This makes it minimally viable but not complete for an agent facing many similar indexer tools.

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 schema already documents depositIds, statuses, and params. The description adds no new parameter detail beyond reinforcing that depositIds is for multiple deposits.

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 names a specific operation ('fetch'), a concrete resource ('intents'), and the selection basis ('multiple deposits'), which separates it from sibling intent tools such as peer_indexer_intents_by_owner and peer_indexer_intents_show. It is immediately understandable without needing to inspect the schema.

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

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

The description gives no guidance on when to choose this tool over the many sibling intent/deposit indexer tools, nor any exclusions or alternative suggestions. The agent is left to infer from the tool name alone which variant 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?

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds only the source ('via the indexer') but does not disclose pagination, ordering, eventual consistency, auth needs, or what the response contains.

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 entire description is one short, front-loaded sentence: 'Fetch intents by owner via the indexer.' It contains no filler and every word contributes meaning.

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

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

For a simple, read-only fetch this is minimally viable: owner is required and documented, annotations signal safety, and the name plus description convey the main purpose. However, there is no output schema, and the optional statuses and raw params behavior are only vaguely handled by the schema, leaving advanced usage underspecified.

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 owner, params, and statuses each have at least a minimal description. The tool description adds no additional parameter semantics beyond reinforcing the owner filter, and the descriptions for params and statuses remain vague.

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

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

The description uses a specific verb and resource ('Fetch intents') and states the scope ('by owner') plus the source ('via the indexer'), which helps separate it from the many peer_indexer_intents_* siblings. It is clear but does not explicitly distinguish itself from near-alternatives like peer_pv_intent_list_owner or peer_indexer_intents_by_deposit_ids.

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?

There is no guidance on when to use this tool versus alternatives. The phrase 'via the indexer' provides implicit context, but no exclusions, prerequisites, or sibling comparisons are offered.

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?

Annotations already indicate readOnlyHint=true and destructiveHint=false, and the description's 'Fetch' is consistent with that safety profile. The description adds only 'via the indexer' as provenance, but it does not disclose return shape, pagination, ordering, or how expiration is determined. This is acceptable but minimal given annotation coverage.

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

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

The description is a single, front-loaded sentence with no filler. The verb and resource are immediately clear, and every word contributes to the core meaning.

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

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

With no output schema, the return format is not described, and the definition does not clarify the exact meaning of 'expired' or how the 'now' and 'depositIds' parameters interact. The full parameter schema and read-only annotations reduce the burden, but the description is still thin for a domain-specific indexer 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 schema already documents all four parameters. The tool description adds no parameter-specific meaning beyond the 'expired' intent context, which only indirectly relates to the 'now' parameter. 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 uses a specific verb, 'Fetch', and a specific resource, 'expired intents', which distinguishes it from sibling intent tools such as peer_indexer_intents_by_owner or peer_indexer_intents_by_deposit_ids. It is clear, though it does not define what 'expired' means or contrast itself with those siblings.

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

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

The phrase 'expired intents' implies when the tool should be used, but the description provides no explicit guidance about when not to use it or which alternatives to choose from the large sibling family. It is usable but relies heavily on the tool name for context.

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

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

The annotations already indicate this is read-only and non-destructive, and the description is consistent with that. However, the description adds no behavioral context beyond the purpose statement—no mention of pagination, limits, output shape, filtering behavior, or what happens when invoked with no parameters, so it fails to disclose anything beyond what annotations already convey.

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

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

The description is a single short sentence with no wasted words, making it easy to scan and parse. It is appropriately concise, though it is so terse that some useful context is omitted, which keeps it from being a perfect 5.

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

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

There is no output schema, so the description carries extra responsibility for clarifying what the tool returns and how parameters affect behavior. It only says 'Fetch fulfillment events for intents,' leaving unclear what a fulfillment event contains, how hashes map to results, whether hashes are required, and how the arbitrary 'params' object modifies the query. Given the large sibling set and ambiguous generic schema types, this is under-specified.

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 schema already documents 'hashes' as 'Intent hashes' and provides a description for the raw JSON 'params' object. The description adds little beyond what the schema provides, which fits the baseline of 3; it neither clarifies param semantics further nor leaves them undocumented.

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

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

The description states a specific verb ('Fetch') and a clear resource ('fulfillment events for intents'), which makes the tool's core purpose identifiable. However, it does not differentiate this tool from similar siblings like peer_indexer_intents_fulfillment_amounts or peer_indexer_intents_fulfillment_and_payment, so it stops short of 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 implies the tool is for retrieving fulfillment events tied to intents, which gives basic usage context. It provides no explicit guidance about when to prefer this tool over the many closely related indexer/intent tools, nor any exclusions or alternative routing.

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?

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description's 'Fetch' wording is consistent with that and adds the specific resource returned, but it discloses no additional behavioral details such as error conditions or response structure.

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 efficient sentence that front-loads the action and the resource. There is no redundant or filler wording.

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

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

This is a simple read-only fetch with one required parameter and no output schema, so a short description is largely sufficient. The gaps—such as response shape or behavior of the optional params field—are minor for this low-complexity 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 intentHash and params are already documented in the schema. The description does not add any extra meaning about how the parameters should be used or formatted, so it stays at 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 states a clear verb ('Fetch'), a specific resource ('fulfillment amounts'), and a scope ('for an intent'). It is distinctive enough among the many peer_indexer_intents_* siblings, though it does not explicitly call out how it differs from similar tools like peer_indexer_intents_fulfillment_and_payment.

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

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

The description gives no guidance on when to use this tool versus related sibling tools, nor does it mention any exclusions or prerequisites beyond requiring an intent. The intended context must be inferred from the tool name and schema.

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?

Annotations already declare readOnlyHint=true and destructiveHint=false, so the read-only safety profile is covered. The description adds the scoping detail that it returns fulfillment and payment records for a specific intent, but it does not disclose pagination, return format, or any operational constraints.

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?

A single, front-loaded sentence with no filler; every word carries meaning. For a one-required-parameter read tool this is an appropriately sized definition.

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 simple read-only purpose, one required hash parameter, and full schema coverage, the definition is adequate for basic invocation. However, it lacks usage exclusions, return-shape hints, and contrast with closely named sibling tools, so an agent must infer some 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?

Schema description coverage is 100%, with intentHash described as 'Intent hash' and params described as optional raw JSON merged beneath typed fields. The description's 'for an intent' adds no new semantic detail beyond those schema descriptions.

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

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

The description uses a specific verb ('Fetch') and identifies a concrete resource ('fulfillment and payment records') scoped to an intent, so it is not a tautology. It is clear enough to distinguish from many indexer siblings, though it does not explicitly name an alternative or say what distinguishes it from peer_indexer_intents_fulfillment_amounts or fulfilled_events.

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 given on when to use this tool versus the many sibling indexer tools, nor are any alternatives or exclusions mentioned. The only context is the input parameter 'for an intent,' which is a constraint already visible in the schema.

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?

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description is consistent with that. However, beyond naming the indexer as the source, it adds no behavioral context such as response shape, pagination, 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?

The description is one front-loaded sentence with a clear verb and object and no filler. Every word contributes to the core meaning.

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

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

For a simple read-only fetch with one required parameter, the description is minimally sufficient. However, with no output schema and many closely related intent/indexer siblings, the description leaves ambiguity about return value and when this tool should be preferred over peer_intent_show or peer_indexer_intents_by_owner.

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 intentHash described as 'Intent hash.' and params described as optional raw JSON merged beneath typed fields. The tool description adds no additional parameter meaning, so the baseline of 3 is appropriate.

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

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

The description states a specific verb ('Fetch') and a specific resource ('a single intent via the indexer'), so the core action is clear. It does not explicitly differentiate from sibling lookups such as peer_intent_show or peer_indexer_intents_by_owner, but the 'single intent' phrasing carries the main selection signal.

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?

There is no guidance on when to use the indexer-backed fetch versus alternatives like peer_intent_show, peer_indexer_intents_by_owner, or peer_market_explorer_intent. 'Fetch a single intent' implies a by-hash lookup, but no conditions, exclusions, or preferred alternatives are 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?

The annotations already declare readOnlyHint=true and destructiveHint=false, which cover the safety profile. The description's 'Fetch' aligns with this, but it adds no additional behavioral context such as pagination, rate limits, or return format. Since annotations carry the primary burden and description is consistent, a 3 is appropriate.

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, short sentence that is directly front-loaded with the core action. No wasted words. It is concise and to the point, suitable for a straightforward fetch tool. Slightly more detail on output could be added, but it is appropriately brief.

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 one required parameter, no output schema, and read-only annotations, the description is adequate for a basic call but misses context that would help an agent understand the return shape or any limitations. It does not mention that it returns a list or any filtering options. Given the simplicity, it is minimally complete, but not fully comprehensive.

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% per context signals, so each parameter has a description (e.g., 'Maker address.', 'Activity limit.'). The description adds no extra meaning beyond these minimal definitions. Baseline is 3 when schema covers all params, and the description does not compensate further.

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

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

The description states a clear verb ('Fetch') and a specific resource ('maker-level fund activities'). It distinguishes from sibling tools like peer_indexer_deposits_fund_activities by specifying 'maker-level' rather than deposit-level, so an agent can grasp the scope. However, it doesn't elaborate on what 'fund activities' include, leaving some 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?

The description provides no guidance on when to use this tool versus alternatives (e.g., peer_indexer_deposits_fund_activities or peer_market_maker_history). It does not mention prerequisites, context, or any conditions that would select this tool. An agent must infer usage solely from the name and schema.

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?

Annotations already establish read-only/non-destructive. The description adds a useful cost/latency warning about arbitrary queries, which is beyond annotations. It provides no other behavioral details such as failure modes or response size 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?

Two compact sentences with the core action first and the caution second. Every word earns its place; no boilerplate or repetition.

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

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

For a raw query escape hatch with no output schema, the warning about cost is useful, but an agent is not told how to discover the GraphQL schema, what a successful response looks like, or how params/variables interact. Adequate minimally but not 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 description coverage is 100% for query, params, and variables. The description adds no parameter-specific meaning beyond the schema; it only warns generally about expensive queries.

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?

States a specific action ('Perform a raw GraphQL query') and resource ('the indexer'), clearly distinct from the many specialized peer_indexer_* siblings. It doesn't explicitly name an alternative, so not 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?

Only warns 'Use sparingly; arbitrary queries can be expensive.' It gives no conditions for when this raw tool should be preferred over the numerous specialized peer_* tools, no exclusions, and no mention of 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?

Annotations already declare readOnlyHint true and destructiveHint false, so the agent knows this is a safe read operation. The description adds only narrow scoping ('for an intent') and does not explain side effects, return behavior, or how routing inputs are derived, though this is partially acceptable given the 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 a single front-loaded sentence with no filler or redundancy. It is appropriately concise, though it omits enough context that it does not quite earn a 5.

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

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

For a simple two-parameter read-only tool, the required intentHash is inferable from the schema and 'for an intent.' However, 'fulfill routing inputs' is never explained, there is no output schema, and no indication of what the returned inspection data looks like, so an agent may be unsure what the tool actually returns.

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%: intentHash is documented as 'Intent hash' and params as 'Optional raw JSON params merged beneath typed fields.' The description adds little beyond the schema, only implying intentHash via 'for an intent,' so the baseline 3 applies.

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

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

The description uses a clear verb, 'Inspect', and names a specific resource, 'fulfill routing inputs for an intent', so it is not a tautology. However, it does not differentiate itself from sibling tools like peer_intent_show or peer_intent_hook_pre_get, and 'fulfill routing inputs' is unexplained domain jargon.

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 given for when to use this tool versus the many sibling intent, indexer, or market tools. The readOnlyHint implies an inspection use case, but the description provides no context, 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?

Annotations already declare readOnlyHint=true and destructiveHint=false, so the description contributes no additional behavioral context. It simply restates the fact that this is a read operation and does not mention any side effects, auth requirements, or scope limitations beyond what the annotations provide.

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

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

The description is a single, direct sentence with no filler or repetition. Every word contributes to the stated purpose, making it appropriately sized and 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?

For a simple read-only getter with one required parameter, the schema and annotations cover the essentials. However, there is no output schema and no explanation of what a 'pre-intent hook' is or what the returned value represents, leaving a moderate gap for an agent expected to use the result 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%, and depositId is documented as 'Deposit ID,' so the schema carries the parameter semantics. The description adds no extra meaning about how depositId relates to the hook beyond the word 'deposit,' which is already obvious from 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 states a specific verb ('Get') and resource ('the pre-intent hook for a deposit'), making the core purpose clear. It does not explicitly differentiate itself among the many peer_* sibling tools, but the resource is distinct enough that the purpose is not vague.

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

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

No guidance is provided about when to use this tool versus alternatives such as peer_deposit_show, peer_intent_show, or peer_intent_fulfill_inputs. The description leaves all usage-selection inference to the agent.

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?

Annotations already establish that this is a read-only, non-destructive operation. The description adds the meaningful behavioral detail that the tool falls back to a configured wallet unless an explicit owner is given, but it does not clarify precedence, result scoping, pagination, or other list behavior.

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

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

The description is a single sentence with no redundant wording and front-loads the action and resource. It wastes no tokens and is easy to parse.

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-only list tool, the description covers the main owner-scoping context, and the annotations plus full schema coverage reduce the burden. However, with no output schema and a large family of intent-listing siblings, the description leaves the agent without enough context to confidently choose this tool or understand return expectations.

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

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

The schema fully documents both parameters, and the description goes beyond it by clarifying that an 'explicit owner' overrides the configured-wallet default. This is useful semantic context beyond the raw 'Owner address.' schema description, although the params object is only described generically.

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

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

The description clearly states the action ('List intents') and the resource ('configured wallet or explicit owner'), making the basic purpose unambiguous. However, it does not differentiate this tool from similarly named siblings such as peer_indexer_intents_by_owner or peer_pv_intent_list_owner, so it falls short of full distinctiveness.

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

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

The phrase 'configured wallet or explicit owner' implies the main use case, but there is no explicit guidance on when to use this tool versus the many sibling tools that also list intents by owner. No alternate tools are named and no exclusion criteria are provided.

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?

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description's 'Show' wording is consistent with those. However, the description adds no behavioral context beyond the purpose, such as not-found behavior, response shape, or any special constraints.

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, clear, front-loaded sentence with no wasted words. It efficiently conveys the core operation and the required lookup key.

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-only lookup with one required parameter, the description is minimally viable. Still, it does not explain what output to expect, how to handle missing hashes, or how this tool differs from the many other intent-show siblings, leaving selection and error handling ambiguous.

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 schema already documents intentHash and params. The description's phrase 'by hash' reinforces intentHash's role but adds no format, source, or lookup semantics beyond the schema.

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

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

The description clearly identifies a specific verb ('Show'), a resource ('a single intent'), and a selection mechanism ('by hash'). It distinguishes itself from list-oriented siblings like peer_intent_list, but it does not differentiate among other show-style intent tools such as peer_indexer_intents_show or peer_pv_intent_show.

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?

There is no guidance about when to use this tool versus alternatives. The sibling list contains multiple tools that show intents by hash, but the description does not mention exclusions, prerequisites, or why an agent should prefer this one.

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?

Annotations already declare readOnlyHint=true and destructiveHint=false, so the read-only nature is covered. The description adds only the word 'recent' as a behavioral hint; it does not disclose whether results are paginated, how limit/since affect the response, what activity categories exist, or whether the output is aggregated or raw.

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

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

The description is a single, front-loaded sentence with no filler or redundancy. It earns its place as a compact summary, though it could be expanded with more useful details without becoming poorly 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 no output schema, four optional parameters, and a large cluster of similar peer_market_* and peer_indexer_* tools, the description is too thin. It does not explain what the response contains, what values type accepts, how since is interpreted, or which activity the tool refers to, leaving the agent to guess.

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

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

The schema has 100% parameter description coverage, so the parameters type, limit, since, and params are already documented. The description does not add meaning beyond the schema, but the baseline of 3 applies because the schema carries the burden and does so 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 states a clear verb ('Fetch') and a resource ('recent protocol activity from Peerlytics'), so it is not a tautology. However, 'protocol activity' is broad and does not specify which event types, domains, or metrics are included, and it does not distinguish this tool from closely related siblings such as peer_market_volume, peer_market_deposits, peer_market_intents, or peer_indexer_activities.

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

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

No guidance is provided about when to use this tool versus the many sibling tools. The description does not mention alternatives, exclusions, or conditions such as 'use for general activity feed' versus 'use peer_market_volume for volume data'.

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?

Annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds the authenticated-account scoping, which is helpful, but it does not mention pagination, rate limits, or response format. With annotations present, a mid-range score is appropriate.

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 focused sentence with an active verb and no filler. It front-loads the action and resource without redundant phrasing.

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-only list operation with no required parameters and no output schema, the description sufficiently identifies what is listed and for whom. The annotations cover the safety profile, so nothing essential for invoking the tool correctly is missing.

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

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

Schema description coverage is 100%, and the single optional params field is documented in the schema. The description adds no parameter-level meaning, but the schema carries that burden, so a baseline score of 3 is warranted.

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 ('List') and resource ('Peerlytics API keys'), with a clear scope ('authenticated account'). It distinguishes this tool from the many sibling tools by naming the exact resource being listed.

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 makes the invocation context clear: it lists API keys for the authenticated account. It does not name alternatives or enumerate when-not-to-use, but no sibling tool appears to cover the same API-key resource, so the lack of explicit exclusions is acceptable.

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

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

The readOnlyHint and destructiveHint annotations already cover the safety profile, so the description only needs to add behavioral context. It adds 'live' and 'published SDK quote route,' but does not disclose result semantics, pagination, rate limits, or quirks. No contradiction with 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?

One sentence contains the action, target, and scope with no wasted words. The key differentiator, 'across platforms,' is placed immediately after the verb.

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 indicate what the tool returns, such as quotes per platform, availability, or best price, but it is silent on return shape. The six-parameter schema, including a raw nested params object, needs more guidance on how fields drive the comparison and which sibling tools should be used instead.

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 even though the tool description omits parameter details. The schema's descriptions are terse but present, and the description adds no parameter-level meaning beyond what the schema already provides.

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

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

The description names a specific action (compare), a distinct resource (live quote availability), and a scope (across platforms). This clearly differentiates it from closely related siblings like peer_quote, which appears to target a single quote.

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 cross-platform phrasing implies when this tool is appropriate, but it does not explicitly name alternatives or give when-to-use/when-not-to-use guidance. Given the large sibling set containing other quote/market tools, explicit routing would materially help.

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?

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description's 'Check' is consistent with that. It adds the useful detail that both balance and usage are reported, but does not mention response shape, units, or rate-limit/reset behavior. With annotations covering the safety profile, the added context is 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?

One short sentence with no filler. The key action and resource are front-loaded, and every word contributes to the meaning.

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

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

For a simple read-only balance and usage check with zero required parameters, the description is nearly sufficient. The lack of an output schema means the agent may not know the exact response fields, but the tool's purpose is clear enough to invoke and interpret in most cases.

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 only parameter is an optional raw JSON passthrough with no typed fields. The description does not add parameter-level meaning, but no required parameters exist and the tool appears callable without arguments, so the baseline 3 applies.

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

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

The description states a specific verb ('Check') and a specific resource ('Peerlytics API credit balance and usage'). It does not explicitly distinguish itself from sibling tools like peer_balance, but the 'credit' and 'usage' scope narrows the meaning clearly.

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

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

The description gives no guidance on when to use this tool versus alternatives such as peer_balance or other market tools. There are no stated exclusions or conditions that would help an agent choose this over a sibling.

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 merely restates that the tool queries deposits with filtering, adding no behavioral context beyond the readOnlyHint and destructiveHint annotations. It does not disclose details like pagination behavior, raw JSON param handling, or response 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 is a single sentence with no filler and is front-loaded with the action and resource. However, it is so terse that it does not convey meaningful differentiating or behavioral details, making it concise but not fully effective.

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

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

This tool has 9 parameters, a nested raw JSON parameter object, no output schema, and many overlapping siblings. A one-line description is insufficient to orient an agent on the data source semantics, filtering behavior, or relationship to alternative deposit-list tools.

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 all 9 parameters are already documented in the input schema. The description's 'with filtering' adds no semantic meaning beyond what the schema provides, 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 a specific verb ('Query'), resource ('deposits'), and source ('Peerlytics'), and notes filtering capability. However, it does not differentiate from the many sibling deposit-related tools such as peer_deposit_list, peer_indexer_deposits_list, or peer_market_explorer_deposit.

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

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

No guidance is provided about when to use this tool versus the numerous similar deposit queries in the sibling list. There is no mention of prerequisites, alternatives, or exclusion conditions.

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 annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds a small amount of context by indicating the return is a wallet 'profile' sourced from Peerlytics, but it does not disclose output shape, pagination behavior, or any other operational traits beyond what annotations provide.

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

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

The description is a single, readable sentence with no filler. The action and target are front-loaded, and there is no unnecessary elaboration, making it optimally concise for the information it conveys.

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 straightforward read-only lookup, the description plus the annotations and fully covered schema provide enough to identify the required address input. However, with no output schema and a large set of sibling explorer tools, the description does not clarify what the profile contains or when to prefer this tool over peer_market_explorer_search or peer_balance, leaving an agent to infer the correct 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 description coverage is 100%, so the baseline is 3. The description adds slight meaning by clarifying that the address parameter refers to a wallet address, but the limit, offset, and raw params fields are left to generic schema descriptions like 'Result limit' and 'Offset.' The description does not compensate with additional parameter-level nuance.

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

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

The description uses a specific verb and resource: 'Look up a wallet address profile on Peerlytics.' It clearly identifies the action and subject, and the name supports that this is an address-focused explorer tool. It does not explicitly differentiate itself from sibling tools like peer_market_explorer_search, so it misses the top score.

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?

There is no guidance about when to use this tool versus alternatives such as peer_market_explorer_search, peer_balance, or other explorer tools. The description merely implies an address-based lookup, but it never states prerequisites, exclusions, or the selection context needed to route an agent correctly.

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?

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds only the domain context 'on Peerlytics' and provides no further behavioral detail such as response shape, pagination behavior, or behavior on invalid or missing deposit IDs.

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 concise sentence with no filler, which is structurally clean. However, it is so minimal that it provides little beyond the tool name and schema, bordering on under-specification rather than efficiently useful 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?

With no output schema and many closely related sibling tools, the description is not complete enough for an agent to confidently invoke this tool correctly. It does not explain what 'looking up' returns, how this explorer view differs from other deposit tools, or how the parameters like offset and params affect the call.

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 schema already documents id, limit, offset, and params. The description adds no additional parameter meaning, but per the baseline for high schema coverage, a 3 is appropriate.

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

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

The description states a clear verb ('look up') and resource ('deposit') in a named domain ('Peerlytics'), so an agent can tell this is a read/lookup operation. However, it does not distinguish this tool from many sibling tools with similar lookup semantics, such as peer_deposit_show, peer_indexer_deposits_show, or peer_market_explorer_search.

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

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

The description gives no guidance on when to use this tool versus alternatives. Given the large sibling list containing several deposit-related lookup tools, an agent has no explicit context for choosing this one, nor any exclusions or conditions.

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?

Annotations already declare readOnlyHint=true and destructiveHint=false. The description merely restates 'look up' and adds no behavioral context such as response shape, missing-hash behavior, or relationship to indexed intent data. It does not contradict the annotations, but it also adds nothing beyond them.

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 terse sentence with no filler, front-loading the key verb and resource. It is economical, though so minimal that it misses opportunities to add helpful context, so it does not earn a 5.

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-only lookup with one required hash parameter, the schema and annotations provide the core call details. However, the presence of many intent-related sibling tools and the absence of an output schema leave selection ambiguity and return behavior unspecified, making the description only minimally 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 description coverage is 100%, with 'hash' described as 'Intent hash' and 'params' as optional raw JSON. The description adds no additional meaning beyond the schema, so the baseline of 3 applies.

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

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

The description states a clear action and resource ('Look up an intent on Peerlytics'). However, it does not distinguish this tool from similarly named siblings such as peer_intent_show or peer_indexer_intents_show, so it lacks sibling differentiation.

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

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

No guidance is provided on when to use this tool versus alternatives. It does not mention any conditions, exclusions, or why an agent should prefer it over peer_market_explorer_search or peer_intent_show.

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 is consistent with the annotations (readOnlyHint=true, destructiveHint=false) by framing the operation as a lookup. It does not contradict the annotations, but it also adds little behavioral context beyond what the annotations and the simple verb already convey, such as return shape or additional constraints.

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, clear, front-loaded sentence with no filler or redundancy. 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-only lookup with one required parameter, the description and schema provide enough to invoke the tool correctly. The lack of an output schema makes return details unspecified, but that is not critical for a profile lookup, though a brief mention of what the profile contains 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 description coverage is 100%, with the address parameter described as 'Maker address' and the params object described as optional raw JSON. The description does not add new meaning beyond the schema, but the baseline 3 applies because the schema already documents all parameters 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 ('Look up') and a specific resource ('a maker profile on Peerlytics'), making the tool's core function clear. It does not explicitly distinguish itself from sibling tools like peer_market_maker_history or peer_market_explorer_search, but the term 'profile' conveys a current snapshot rather than history or search results.

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: use this tool when you need a maker profile for a given address. However, it provides no explicit guidance about when not to use it or which sibling tools are better suited for related needs, such as maker history or broader explorer searches.

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?

Annotations already declare readOnlyHint=true and destructiveHint=false, so the description adds no behavioral context beyond the scope of the search. It does not disclose result format, pagination, matching semantics, or any limitations. Given the annotations, the bar is lower, but the description still contributes no extra behavioral insight.

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?

A single, front-loaded sentence conveys the core purpose with no filler. It is appropriately short for a tool with only one required parameter and minimal behavioral nuance.

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 definition is minimally viable for a read-only search tool: the schema covers parameters and annotations cover safety. However, there is no output schema and no description of what the search returns, and usage guidance relative to the many sibling explorer tools is absent. An agent could invoke it, but may not know how to interpret results or when to choose it over alternatives.

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 schema already documents both parameters. The description adds some meaning by indicating the query spans multiple domains, but it does not elaborate on query syntax, expected formats, or how the optional params object is used. 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 uses a specific verb ('Search') and names four concrete resources (addresses, deposits, intents, vaults), making its scope immediately clear. It implicitly distinguishes itself from the many single-entity explorer siblings, though it does not explicitly state that it is the cross-entity alternative.

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 cross-entity lookup by listing multiple resource types, but it does not state when to prefer this tool over specific explorers like peer_market_explorer_address or peer_market_explorer_deposit. No exclusions or alternatives are mentioned.

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?

Annotations already declare readOnlyHint true and destructiveHint false, so the safety profile is covered. The description adds essentially no behavioral detail beyond the Peerlytics qualifier, omitting what a lookup returns, whether it is an exact-ID fetch, or any edge behavior.

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

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

The single sentence is brief and free of fluff, but it is so minimal that it sacrifices useful content. The description reads more like a short label than a structured tool definition.

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 and a large set of ambiguous sibling tools, the description should state what kind of vault data is returned and how this differs from nearby explorer and vault tools. It does neither, so the agent is under-informed for a correct call.

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 'id' described as 'Vault ID' and params explained as raw JSON merged beneath typed fields. The description does not need to compensate, so the schema-heavy baseline of 3 is appropriate.

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

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

The description states a clear verb ('Look up') and resource ('a vault on Peerlytics'), so an agent knows it is a retrieval operation. However, it does not differentiate this tool from closely named siblings like peer_vault_show or peer_market_vaults, so it falls short of 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?

No guidance is given about when to use this tool instead of the many sibling vault/explorer tools in the same list. There is no mention of alternatives, prerequisites, or the typical scenario for a vault lookup, leaving the agent to infer selection 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?

The readOnlyHint and destructiveHint annotations already establish the safe read-only nature of the tool. The description adds only mild domain context ('Peerlytics' and 'profile') and does not describe response shape, address format, or failure behavior, so it provides limited value beyond the 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 one short, front-loaded sentence with no filler. It is concise and readable, though it is so minimal that it misses opportunities to add routing or usage context that would make it more useful.

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

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

For a read-only tool with one required parameter and clear schema coverage, the minimal description is workable. However, with no output schema and no mention of alternatives among the many peer_market_explorer_* siblings, the agent gets only the bare essentials for correct invocation.

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

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

Schema description coverage is 100%, and the only required typed parameter, 'address', is documented as 'Verifier address.' The description adds no additional parameter-level meaning, so the 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 states a specific action ('Look up') on a specific resource ('verifier profile') within a named domain ('Peerlytics'). It is clear, but it does not explicitly distinguish itself from the many sibling explorer tools such as peer_market_explorer_maker or peer_market_explorer_address.

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 usage guidance is provided. The description does not say when to prefer this tool over alternatives, nor does it mention any exclusions or related tools, which is a notable gap given the large sibling list.

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?

Annotations already declare readOnlyHint=true and destructiveHint=false, but the description adds little beyond the generic phrase 'with filtering.' It does not disclose pagination behavior, filter semantics, rate limits, or anything about the shape of returned intents, so it adds minimal value beyond 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 short and front-loaded, with no fluff. However, for a seven-parameter tool with nested objects, it is under-specified; the phrase 'with filtering' is vague and does not earn its place as meaningful guidance.

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

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

There is no output schema and no explanation of return values, filter behavior, or how this tool differs from the many intent-related siblings. An agent would have to infer most contextual details from parameter names alone.

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 schema already documents all seven parameters. The description adds no extra meaning beyond the generic 'with filtering' and does not explain relationships between owner, recipient, status, depositId, or the nested params object.

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 names a clear verb ('Query'), a resource ('intents'), and a source ('Peerlytics'), so the core purpose is understandable. However, it does not distinguish this tool from several intent-related siblings such as peer_intent_list, peer_indexer_intents_by_owner, or peer_pv_intent_list_owner.

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?

There is no guidance on when to use this tool versus alternatives. The sibling list contains many intent-query tools, and the description does not explain what makes peer_market_intents the right choice, 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?

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds the source and data scope but does not disclose behavioral details like pagination semantics or leaderboard ordering. It does not contradict the 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 a single front-loaded sentence with no filler. It efficiently states the action and resource. A bit more usage context would improve it, but as written it is appropriately concise.

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 paginated read-only leaderboard tool, the description is minimally viable but leaves gaps: no return value shape, no ordering or ranking semantics, and no timing/availability context. With no output schema, some additional context would help an agent call it correctly in unfamiliar workflows.

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 coverage is 100%, so limit, offset, and params are already described in the schema. The description adds no parameter-level meaning beyond what the schema provides, which meets the baseline for high schema coverage.

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

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

The description clearly identifies the action ('Fetch'), the resource ('maker and taker leaderboard data'), and the source ('Peerlytics'). It is specific enough to indicate this is a leaderboard retrieval tool and is not a tautology. It doesn't explicitly contrast with siblings like peer_market_maker_history, but the 'leaderboard' term differentiates it reasonably.

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

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

No guidance is provided about when to use this tool versus alternatives such as peer_market_maker_history, peer_market_taker_history, or peer_market_activity. The description simply states what it fetches without explaining the appropriate context 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?

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds a small amount of context by identifying Peerlytics as the source, but it does not disclose pagination, time ranges, response shape, or other behavioral details beyond what the annotations imply.

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

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

The description is a single front-loaded sentence with no redundant words. It efficiently communicates the core action and subject.

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-only tool requiring only an address, the description is serviceable. However, it omits useful context such as what the returned maker activity history contains, any date/range constraints, and whether the response has a particular structure, which matters given there is no output schema.

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

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

Schema description coverage is 100%, with the address parameter documented as 'Maker address.' and the params parameter described as raw JSON merge. The description adds no additional parameter semantics beyond what the schema already provides, so the baseline score of 3 is appropriate.

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

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

The description names a specific verb and resource: 'Fetch maker activity history for an address'. This is clear and unambiguous. However, it does not explicitly differentiate itself from closely related siblings like peer_market_taker_history or peer_market_explorer_maker.

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

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

The description gives no guidance on when to use this tool versus alternatives. With siblings such as peer_market_taker_history and peer_market_activity, an agent is left to infer the intended use case 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?

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds a small amount of context by attributing the data to Peerlytics, but it does not disclose return format, ordering, pagination, or any special behavior.

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

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

The description is a single concise sentence, 'List supported currencies from Peerlytics.' It is front-loaded and contains no filler, making it easy to parse quickly.

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

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

For a zero-required-parameter read-only listing tool with annotations covering side effects, this description is nearly sufficient. It could be improved by mentioning the expected response shape, especially since no output schema is provided, but the core invocation context 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?

The only parameter is a generic optional 'params' object with schema description coverage of 100%, so the schema already explains it. The tool description adds no parameter-level meaning, which is acceptable given high schema coverage and zero required parameters.

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