peerlytics

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

With no annotations, the description carries the full burden and does so thoroughly. It discloses auth requirements, credit cost, cached vs inline delivery, retention limits, the shared data contract, and an unsupported protocol — far more behavioral context than typical.

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

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

Four dense sentences with no filler, front-loaded with the core purpose before moving to format and data details. Every sentence contributes a distinct, useful fact, and the structure makes the key format/cost/auth tradeoffs immediately visible.

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

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

Despite lacking an output schema, the description covers the response shape (signed URL vs inline JSON), retention periods, the shared field set, authentication constraints, and cost. An agent has enough information to select and invoke the tool correctly.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds real value beyond the schema by explaining what format=csv vs format=json actually returns (cached signed URL vs inline data) and by listing the shared fields across both formats.

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

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

The description opens with a specific verb and resource — 'Export wallet transaction events' — and immediately distinguishes this as an export tool rather than a simple get/list tool. It further clarifies the canonical role-aware classifier and format-specific outputs, making its purpose unambiguous relative to the numerous sibling tools.

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

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

The description clearly establishes context: API-key-only access, a 2,500-credit cost, and explicit rejection of x402. It implies this is for bulk or durable export rather than interactive queries, though it doesn't name specific alternatives or state when not to use it.

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

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

With no annotations, the description must fully disclose behavior. It only states 'Unified address stats', leaving out whether the operation is read-only, requires auth, or any other behavioral traits.

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

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

The description is extremely concise ('Unified address stats') but at the cost of informativeness. It does not adequately earn its place as a helpful guide.

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 4 parameters, 1 required, and no output schema, the description is completely inadequate. It provides no insight into the return value or behavior of the tool.

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

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

Schema coverage is 75% with good descriptions for limit, cursor, offset. However, the required 'address' parameter lacks a schema description, and the tool description adds no clarifying context, such as what type of address is expected.

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 'Unified address stats' is vague. It does not specify a clear verb or resource, and fails to distinguish this tool from numerous sibling tools like get_analytics_summary or get_market_summary.

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 agent has no context to choose between get_address and similar sibling tools.

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

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

No annotations exist, so the description fully bears the burden. It discloses that data is 'computed live from the indexer', describes the return payload structure, and mentions the cap. It does not discuss authentication or side effects, but the tool likely has no destructive 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?

Three sentences with no fluff. The first sentence states purpose; the second details optional parameter behavior; the third adds constraints. Every sentence is essential and well-ordered.

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 4 parameters, no output schema, and no annotations, the description is fairly complete. It explains the return shape and the cap. It could elaborate further on the 'composition' and 'comparison' blocks, but the information provided is sufficient for 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 coverage is 100%, and the description adds value beyond the schema by explaining default behavior for 'to' and 'from', precedence of 'range' over 'from'/'to', and the effect of 'compare'. It also clarifies the hard cap applies to 'range' and legacy 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 specifies the tool provides 'investor summary metrics' with clear differentiation between parameterized and non-parameterized usage. It distinguishes from sibling tools (e.g., get_market_summary, get_timeseries) by focusing on aggregated summary metrics with optional comparison.

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

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

The description explains when to use without parameters (cumulative buckets) and with parameters (windowed payload), and mentions the optional compare parameter. It also notes a hard cap (400-day window). However, it does not explicitly exclude alternatives or state when not to use this tool.

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

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

No annotations are provided, so the description carries the full burden. It describes return data but does not disclose whether the tool is read-only, requires authentication, has rate limits, or any other behavioral traits.

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

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

The description is a single sentence, adequately concise, but it reads as a bullet list without clear structure, making it slightly less 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 simple tool with one parameter and no output schema, the description lists key return fields but omits behavioral context and parameter details, leaving gaps.

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

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

The single parameter 'address' has no schema description (0% coverage) and the tool description adds no meaning about its 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 identifies the tool as a delegate view and lists specific data returned (deposits, liquidity, rate managers, success rate, deposit list), effectively conveying what the tool does and distinguishing it from siblings like get_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 guidance on when to use this tool versus alternatives. Does not specify context, prerequisites, or exclusions, 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?

With no annotations provided, the description carries the full burden. It offers no behavioral information such as whether the tool is read-only, has side effects, requires authentication, or has rate limits. The single word 'detail' is insufficient.

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 extremely terse (two words) but suffers from under-specification. It is not structured to be helpful for an AI agent; it lacks any context, examples, or clarity.

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

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

The description is severely incomplete given the tool's complexity (4 parameters, no output schema, no annotations). It does not explain return values, pagination behavior (cursor/offset), or how to interpret results. An agent would struggle to use this tool correctly.

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

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

The schema covers 75% of parameters with descriptions, but the tool description adds no additional meaning. For instance, the required 'id' parameter lacks description, and the description does not clarify its purpose or format. The description adds no value beyond the schema.

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

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

The description 'Deposit detail' is vague and essentially restates the tool name. It fails to specify what action is performed (e.g., retrieve, fetch) or what exactly is returned. It does not distinguish from sibling tools like get_deposit_context.

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 is no mention of required prerequisites, common use cases, or when to prefer this over other get_* 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 are absent, so the description carries full burden. It describes the return content (route facts, trust signals, next-action links) but does not disclose behavioral traits like read-only nature, authorization requirements, or performance 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 concise (two sentences) and front-loaded with the purpose. However, the first sentence 'Deposit agent context.' is somewhat vague and could be integrated into the second sentence.

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 tool with one parameter and no output schema, the description adequately explains the output nature but lacks parameter explanation and usage constraints. It is decent but not fully self-contained.

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 'id' has no description in the schema (0% coverage). The tool description does not explain what 'id' refers to (e.g., deposit ID), leaving the agent to infer its meaning from context.

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

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

The description clearly states the tool returns compact deposit workbench context (route facts, trust signals, next-action links) and distinguishes it from loading the full explorer payload, implying it's a lighter alternative to 'get_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?

The description implies use when needing lightweight context without the full explorer payload, but does not explicitly state when not to use it or name alternative tools. Sibling tools like 'get_deposit' exist but are not referenced directly.

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

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

With no annotations provided, the description carries full burden. It discloses that the tool resolves attribution from calldata and that the window is fixed, which are important behavioral traits. It does not cover auth requirements or response format, but for a read-only tool this is adequate.

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

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

The description is two sentences, front-loading the purpose and content, then adding a constraint about the window. Every sentence adds value with no redundancy.

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

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

For a single-parameter tool with no output schema, the description lists the types of data returned (deposits, intents, volume, top makers, etc.), explains attribution resolution, and notes the fixed window. This is comprehensive and requires no additional clarification.

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 single parameter 'code' has 0% schema description coverage, but the description clarifies it is an 'ERC-8021 integrator code', adding valuable context beyond the raw schema. It does not specify format or validation rules, but provides enough meaning for correct usage.

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

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

The description explicitly states the tool provides an 'Integrator view' with aggregated activity for an ERC-8021 integrator code, listing specific data points (deposits, intents, volume, top makers, top markets, daily activity). This clearly distinguishes it from sibling tools like get_maker or get_taker.

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

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

The description explains that the window is fixed at 90 days and that the legacy windowDays parameter was retired, giving context on constraints. However, it does not explicitly mention when to use or not use this tool versus alternatives.

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

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

With no annotations and a one-word description, there is no disclosure of behavioral traits such as idempotency, authentication needs, or side effects.

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

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

While extremely concise, the description is under-specified and fails to earn its place by providing useful information.

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

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

Given the one parameter with no description and no output schema, the description is wholly inadequate for helping an agent select or invoke the tool.

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

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

The single parameter 'hash' has no description in the schema (0% coverage) and the description adds no meaning beyond its existence.

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

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

Description 'Intent detail' is vague and tautological; it does not state a specific verb or resource, and fails to distinguish from sibling tools like get_deposit or get_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?

No guidance is provided on when to use this tool versus alternatives, nor any context about prerequisites or exclusions.

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

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

No annotations provided, so description bears full burden. It explains the two computational modes and a hard cap on the window, but does not mention response structure, pagination behavior, or any authentication or rate limit considerations. Adequate but not comprehensive.

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

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

Extremely concise: two sentences plus a note. No wasted words, key information front-loaded. Every sentence adds value.

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

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

Tool has 6 parameters and no output schema, but description omits response structure (e.g., leaderboard entries, fields, pagination cursors). For a list endpoint, this is a significant gap that hinders agent understanding of what the tool 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 coverage is 100%, so baseline is 3. The description adds minimal extra meaning beyond the schema, merely grouping from/to/range as triggers for per-window mode. Key details like range precedence are already in the schema.

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

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

The description clearly states the tool returns a maker/taker leaderboard and distinguishes two modes (cumulative vs per-window) based on parameters. The name 'get_leaderboard' combined with the description makes the purpose unambiguous and distinct from sibling tools.

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

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

No explicit guidance on when to use this tool vs sibling tools like get_maker or get_taker. The description only differentiates between parameter modes within the tool itself, not external alternatives.

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

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

No annotations exist, and the description does not disclose any behavioral traits. It does not state whether the tool is read-only, requires authentication, or has any limitations.

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 only three words, which is under-specified. It lacks any structured explanation of the tool's purpose or parameters.

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 single parameter and no output schema, the description should provide more context about the return value and the concept of a 'maker portfolio'. It is incomplete.

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 'address' has no description in the schema, and the description adds no additional context about its meaning or format. With 0% schema coverage, the description fails to compensate.

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 'Maker portfolio' is vague. It does not specify what the tool returns or what a 'maker portfolio' entails. It fails to distinguish from sibling tools like get_maker_history or get_taker.

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 guidelines are provided. The description does not indicate when to use this tool versus alternatives such as get_maker_history or get_taker.

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

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

No annotations are provided, so the description carries full burden. It discloses the behavioral difference between providing window parameters and omitting them, including the default recent window of 30 intents. This is good transparency for a read-only tool.

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

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

The description is two sentences, front-loading the core function and immediately clarifying behavior. Every word earns its place; there is no redundancy.

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

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

Given 7 parameters, high schema coverage, and no output schema, the description covers the essential behavioral context. It explains the two main usage modes and the effect of parameters. It does not detail return values, but that is acceptable without output schema.

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

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

Schema coverage is 86%, high. The description adds value by explaining the collective effect of window parameters (from/to/range) on metric recomputation. However, individual parameter semantics are well-covered by the schema, so the description provides modest additional meaning.

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

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

The description clearly states the tool returns 'maker history metrics' and explains behavior with and without window parameters. It is specific but does not explicitly differentiate from sibling tools like get_maker or get_taker_history.

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

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

The description explains when to use window parameters vs not, noting that without them it returns lifetime aggregates and a recent window, and with them metrics recompute. It does not provide explicit when-not-to-use or alternative tools.

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

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

No annotations provided, and the description fails to disclose any behavioral traits (e.g., pagination behavior, rate limits, data freshness). The single phrase is entirely insufficient.

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?

Extremely short but not concise—it is under-specification. The description should convey essential details, not just a vague label.

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 no annotations, the description is wholly inadequate. It provides no context about return values, pagination (despite cursor/offset params), or how filters affect 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?

Schema coverage is 100%, so parameters are well-documented in the schema. The description adds no value, but the baseline for high coverage is 3.

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

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

Description 'Market intelligence snapshot' is vague; lacks a specific verb and does not distinguish the tool's action (e.g., fetch, list). It gives little sense of what the tool returns.

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 on when to use this tool versus siblings. Many sibling tools exist (e.g., get_analytics_summary, get_protocol_overview), but the description offers no context for selection.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It does disclose the nature of the payload (full orderbook with multiple data facets) and mentions 'DRM-aware metadata', which hints at permission-related behavior. However, it omits operational details such as authentication requirements, rate limits, pagination, or the shape of the response. For a read-only tool this is acceptable but not thorough; it adds value with the 'DRM-aware' note but lacks completeness.

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

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

The description is a single dense sentence that front-loads the resource name ('Network orderbook.') followed by a list of contents. It is concise with no filler, though the list runs together and could be more readable with bullet points. Every phrase adds meaning, so it earns a 4 for efficiency despite minor structural rigidity.

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

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

Given the tool has five optional parameters, no output schema, and a complex payload, the description is reasonably complete. It enumerates the major components an agent would expect (rate levels, per-deposit availability, activity, stats, FX rates, DRM metadata), which provides enough context for a caller. However, without an output schema, it does not describe the response structure or how these components are organized, which is a slight gap for a tool of this complexity.

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

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

The input schema documents all five parameters with detailed descriptions (e.g., min_size default, currency filtering, include_gated behavior). The description itself adds no additional parameter semantics beyond what the schema already provides. Since schema coverage is 100%, the description does not need to compensate, so a 3 is appropriate — it neither enhances nor detracts from the schema's clarity.

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

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

The description clearly identifies the tool as the 'Network orderbook' and enumerates its contents (rate levels, per-deposit availability, intent bounds, payment pairs, etc.). It distinguishes itself from other data tools by focusing on orderbook depth, but does not explicitly contrast with siblings like get_market_summary or list_currencies, so it loses a point for lack of explicit differentiation.

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

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

The description implies usage for orderbook queries by listing what it returns, but provides no explicit guidance on when to use it versus alternatives. There is no mention of scenarios where a different tool would be more appropriate, nor does it state prerequisites or caveats like requiring a taker for gated data beyond what the schema explains. It is neither misleading nor entirely absent, but the onus falls on the agent to infer purpose from the contents.

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 lists the returned data categories (deposits, makers, takers, etc.) but does not disclose behavioral traits such as read-only nature, authentication needs, rate limits, or side effects. Without annotations, the description covers basic behavior but lacks depth.

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

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

The description is concise with a single sentence that front-loads the key purpose. However, the list format could be more structured (e.g., using bullet points) to improve readability without adding 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?

The description lacks details on output format, units, pagination, or data shape, especially since no output schema is provided. The tool has two parameters but only 'window_days' is explained in the schema; the description does not fully compensate for the missing context.

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

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

The description does not add meaning to the 'platform' parameter beyond linking it to the tool, and the schema description for 'window_days' already covers its details. With 50% schema coverage, the description should compensate for the undocumented 'platform' parameter but fails to do so.

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

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

The description clearly states it's a view of payment platform metrics, listing deposits, makers, takers, intents, volume, and currency breakdown. It distinguishes from siblings like get_maker or get_taker by focusing on aggregate platform data, but could be more explicit about the retrieval action.

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 on when to use this tool versus alternatives like get_protocol_overview or get_market_summary. The description does not specify prerequisites or exclusions, leaving the agent to infer usage context 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?

With no annotations, the description carries full burden. It discloses that certain ranges use cached buckets while others trigger live compute, which is useful. However, it does not mention authentication requirements, rate limits, or error handling 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?

Three sentences with no wasted words. The first sentence states the purpose, the second explains parameter usage, and the third lists content. Front-loaded and efficient.

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

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

Input parameters are well explained given their optionality, but with no output schema, the description only vaguely mentions included metrics. It lacks details on the response structure, pagination, or bounding of the window. Adequate but incomplete.

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

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

Schema coverage is 100%, but the description adds value by explaining that `range` takes precedence over `from`/`to`, default behavior of `to`, and that legacy enum values were retired. This goes beyond what the JSON 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?

Description clearly states the tool provides an investor-focused protocol diligence overview and lists included metrics (growth, throughput, liquidity quality, etc.). However, it could be more specific about how this overview differs from other summary tools among siblings like get_analytics_summary.

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

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

Description explains the use of `range` shortcuts for cached vs live compute, but does not provide explicit guidance on when to use this tool versus sibling tools like get_analytics_summary or get_market_summary. No alternatives or exclusions 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?

No annotations provided, and the description does not disclose behavioral traits such as read-only nature, side effects, or auth requirements. It only lists data fields without indicating safety or usage 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?

Description is a single sentence listing key data points; it is concise and to the point. However, it lacks structural elements like bullet points or separation of concerns.

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 one parameter and no output schema, the description is incomplete. It does not explain return format, pagination, or edge cases, leaving the agent with insufficient information for reliable 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 has 0% description coverage and no parameter documentation. The description mentions 'taker wallet' but does not explain the address parameter's format, purpose, or constraints, adding minimal value beyond the schema.

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

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

Description clearly states it provides a taker portfolio and lists included data types (volume, intents, allocations, activity). It implicitly distinguishes from siblings like get_maker and get_taker_history by focusing on portfolio overview.

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

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

No explicit guidance on when to use this tool versus alternatives. The description only implies usage for taker portfolio data, but does not mention prerequisites, limitations, or sibling tool differentiation.

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

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

With no annotations, the description carries the full burden. It discloses that within a window, intents fields reflect only the period and cumulative responses fall back to lifetime stats. It also explains the range parameter precedence and deprecation of offset. However, it does not mention rate limits, authentication, or whether the tool is read-only.

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

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

The description is two sentences, front-loaded with the tool's purpose and then elaborating on key behavioral detail. Every sentence adds value, with no filler.

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

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

Given the complexity (7 parameters, window semantics, deprecation), the description covers essential behavioral aspects but lacks detail on return format (no output schema) and the meaning of 'lifetime TakerStats.' The reference to maker history assumes prior knowledge of that endpoint's pagination.

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 (86%), so baseline is 3. The description adds value beyond the schema by explaining the order of precedence for range vs from/to, the use of cursor for pagination, and the deprecation of offset. This helps the agent understand how parameters interact.

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

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

The description clearly states it provides 'taker history metrics' and explains the window/pagination semantics by referencing the maker history endpoint. It distinguishes itself from sibling tools like get_maker_history by explicitly naming the similar but different endpoint.

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

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

The description references the maker history endpoint for similar semantics but does not explicitly state when to use this tool over siblings like get_taker or get_analytics_summary. It lacks guidance on when not to use it or clear alternatives beyond the maker reference.

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

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

Without annotations, the description carries the behavioral burden. It discloses the credit cost, explains the effect of group_by on response structure (single buckets vs series[]), and documents the range parameter's hard cap and legacy retirement. It does not explicitly state read-only behavior, but the context suggests a read operation. Overall, it provides good transparency.

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

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

The description is three sentences, front-loaded with purpose, then cost, then an important parameter effect. Every sentence adds value with no wasted words.

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

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

Given 10 parameters, no output schema, and no annotations, the description covers the main behavior and key parameter interactions. It could be slightly more complete by mentioning pagination or response structure details, but it is largely sufficient for the complexity.

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

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

Schema coverage is 100%, so baseline is 3. The description adds significant value by explaining how group_by transforms the response, the precedence and behavior of range over from/to, and the retirement of legacy range values. This goes beyond the schema definitions.

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

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

The description clearly states the tool provides historical time-series data with specific entities (deposits, intents, volume) and granularity options (hour, day). It distinguishes itself from sibling tools by focusing on aggregated time-series, not individual records.

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

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

The description mentions a credit cost (60 per call) but does not explicitly state when to use this tool versus alternatives like get_analytics_summary or individual entity tools. It implies usage for time-series aggregation but lacks explicit guidance on when to choose this over siblings.

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

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

With no annotations provided, the description must communicate behavioral traits. It only notes authentication support ('API key auth and x402'), but does not disclose whether the operation is read-only, idempotent, rate-limited, or has any prerequisites or side effects. The word 'explorer view' implies reading, but is not explicit.

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

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

The description is three sentences and moderately concise, but contains redundancy: 'delegated deposits' is mentioned twice. The order is acceptable, with the core purpose first, but the second sentence restates much of the first with extra details.

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

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

Given the lack of output schema, the description hints at return fields (vault detail, deposits, configs, snapshots) which is helpful. However, it does not specify the structure or whether snapshots are returned by default with the 'days' parameter. For a tool with two parameters and a complex response, the description is adequate but not thorough.

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

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

Schema description coverage is 50%: only 'days' has a schema description. The tool description adds no meaning for the required 'id' parameter (likely vault ID but not stated). For 'days', the schema already provides the default and max, so the description adds no value. The description should clarify both parameters, especially 'id'.

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 that the tool returns vault details including delegated deposits, oracle configs, floor configs, and historical snapshots. This is specific about the resource and data returned, distinguishing it from simpler vault-related tools like get_deposit or get_vault_analytics. However, the term 'rate-manager explorer view' is somewhat jargon and could be clearer.

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 its many siblings (e.g., get_vault_analytics, get_deposit, get_deposit_context). There is no mention of alternatives, exclusions, or typical use cases, leaving the agent to guess.

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

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

No annotations exist, so the description carries full burden. It discloses the two behavioral modes, parameter precedence (range over from/to), and output fields for each mode. This is transparent and accurate.

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

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

The description is two sentences with clear structure: first sentence states general purpose, second sentence details parameter-specific behaviors. No wasted words.

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

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

Without an output schema, the description adequately describes return values for both modes, listing specific fields. It covers the main use cases, though could mention pagination or limits if any exist.

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?

Although schema coverage is 100%, the description adds significant meaning: explains default values, precedence rules, output fields per parameter combination, and format details. This goes well beyond the schema.

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

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

The description clearly states it provides 'Vault and delegated liquidity overview' and distinguishes two modes: cumulative analytics without parameters and per-vault rollups with time parameters. This differentiates it from sibling tools like get_vault, get_analytics_summary, and others.

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

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

The description explains when to use each parameter configuration (without params vs. with from/to/range) and notes authentication support. It doesn't explicitly direct to alternatives but the context is clear.

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

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

No annotations exist, and the description provides no behavioral information such as whether the tool is read-only, has side effects, or requires special permissions. The agent has no insight into 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?

The description is extremely short (two words) but at the cost of being under-specifying. It is not concise in a helpful way; it lacks essential information.

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

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

For a tool with 4 parameters (1 required) and no output schema, the description 'Verifier stats' is grossly incomplete. It fails to explain what the tool returns, what the address parameter represents, or any other context.

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

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

The input schema has 4 parameters with 75% description coverage (limit, cursor, offset have descriptions, but address lacks one). The description adds no additional parameter meaning, and with coverage below 80%, it should compensate but fails to do so.

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 'Verifier stats' is vague; it does not state a clear verb and resource. It is unclear what 'stats' means and how this differs from sibling tools like 'get_address' or 'get_analytics_summary'.

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. There is no mention of prerequisites, context, or alternatives, leaving the agent without usage direction.

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?

Given no annotations, the description effectively discloses pagination behavior (cursor/offset), parameter precedence (range overrides from/to), and retirement of legacy values. It adds significant behavioral context beyond mere existence.

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 focused sentences: one for purpose, one for parameter usage. It is front-loaded and every sentence adds value. No redundancy or 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?

The description handles 13 parameters by explaining pagination and date range logic, but does not cover all filter parameters (e.g., taker, depositor). The response structure is partially described (next_cursor, has_more). Good, but leaving some parameter details to the schema.

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

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

Schema coverage is 62%, but the description adds meaning by explaining the relationship between range, since, to, cursor, and offset. It clarifies the pagination contract and shortcut behavior, surpassing 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 states 'Protocol activity feed. Recent protocol events.' This clearly identifies the tool as listing activity events, distinguishing it from sibling list tools for currencies, deposits, and intents.

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

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

The description does not provide explicit guidance on when to use this tool versus alternatives. It lacks context on when not to use it or how it differs from related tools like list_deposits or list_intents.

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

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

With no annotations, the description must disclose behavior. It fails to state it is read-only or harmless. The term 'metadata' is vague and does not clarify what fields are returned (e.g., currency codes, names, decimals).

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?

Extremely concise at two words, but it under-specifies the purpose. Conciseness is positive, but the trade-off is loss of clarity. Every word earns its place, but more are needed.

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

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

Given no output schema, the description should hint at return structure (e.g., list of currency objects with fields). It does not. For a tool with no complexity, it is barely 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?

No parameters exist, so the description has no burden. Baseline 4 is appropriate; the description adds no param info but none is needed.

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 'Supported currencies metadata' indicates the tool deals with currencies, but lacks a verb to clearly state it lists them. The name 'list_currencies' helps, but the description could be more explicit like 'Returns metadata for all supported 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 on when to use this tool versus siblings. Siblings are diverse (e.g., get_address, plan_routes), but no mention of context or alternatives. The tool is simple, but still no usage direction 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?

With no annotations provided, the description carries the full burden and delivers richly: it discloses default limit (50), max cap (200), window semantics (server filters on creation timestamp), response echo of a window block, precedence of `range` over `from`/`to`, deprecation of `offset`, retirement of legacy range values with effective date, hard cap on range windows (400 days), and the supported pagination path via cursor. This far exceeds typical behavioral disclosure.

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

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

The description is compact and front-loaded: opening verb+object phrase, then limits, filters, window semantics, and ending with a useful return-field note. Every sentence adds value. A tiny deduction for density—the final parenthetical list is long—but it's information-dense rather than padded.

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 13-parameter list endpoint with no output schema and no annotations, the description is remarkably complete. It covers defaults, pagination, deprecation, date semantics, and return-field context. It doesn't explain the sort default or all 13 parameters explicitly, but with 92% schema coverage the schema handles those, and the description covers the high-risk behavioral aspects.

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 92%, so the schema does most of the work. The description adds meaningful cross-parameter context: how filters combine, window behavior, `range` precedence, legacy value retirement, and the `next_cursor` pagination path. It even identifies which market rows include DRM and oracle pricing fields, adding value beyond individual parameter descriptions. Minor deduction for not enumerating every filter parameter, but it names the important ones.

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

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

The description opens with 'Filtered deposit list. Deposit search.' which clearly identifies the tool's function as listing/searching deposits with filtering capabilities. It distinguishes itself from siblings like get_deposit (single deposit) and list_activity/list_intents by explicitly scoping to deposits and describing specific deposit-centric filters (depositor, delegate, platform, currency, date window).

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

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

The description clearly states usage context: filters are optional, empty query returns a bounded page, and specifies default/max limits. It explains when to use date windows and how filters combine. It doesn't explicitly contrast with alternatives, but the sibling differentiation (deposit-specific filters vs get_deposit's single-item lookup) makes the when-to-use fairly clear.

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

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

With no annotations, the description carries the burden of behavioral disclosure. It provides concrete details: default limit=50, max 200, default sort order, and retirement of legacy aliases (owner, to_address) on 2026-04-30. These go beyond what the schema states and give the agent actionable expectations about pagination, sorting, and alias handling. It omits return-value structure but covers core behavior well.

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

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

The description is three sentences, front-loaded with the core purpose, and then efficiently packs defaults, filters, sort, and alias migration notes. Every sentence adds value and no space is wasted on fluff. It is easy to scan and 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?

Given 12 optional parameters, no output schema, and no annotations, the description covers the essential behavior well: filters, pagination bounds, default sort, and alias changes. It lacks an explicit statement of return fields or pagination cursor usage, but those are partially in the schema. The description is sufficient for a list tool with this parameter richness.

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 92% (11 of 12 parameters have descriptions), so the baseline is 3. The description adds contextual nuance beyond the schema, such as the retirement date for legacy aliases and the default sort direction. It also hints at the precedence of `range` over `from`/`to` (though the schema also states this). This extra context nudges the score above 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 opens with 'Filtered intent list. Intent search.' which clearly identifies the resource (intents) and the action (list/search). It distinguishes itself from siblings like get_intent (singular) and list_deposits by emphasizing filters specific to intents (e.g., taker, recipient, verifier, deposit_id, status). This makes the tool's niche immediately apparent.

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

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

The description explains that filters are optional and an empty query returns a bounded page, providing a clear sense of when to use the tool. It does not explicitly name alternatives or exclusions, such as 'use get_intent for a single intent', but the context of siblings and the focus on filtering imply the appropriate use case. This is clear context without formal exclusions.

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

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

No annotations provided; no behavioral traits disclosed. The description does not indicate whether the tool is read-only, what data it returns, or any side effects. Completely opaque.

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?

Very short, but the single noun phrase is not front-loaded with actionable information. Conciseness is achieved at the expense of clarity.

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

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

Without output schema or annotations, the description is the sole source of info. It fails to explain what the tool returns, how to interpret results, or any other context. Completely inadequate.

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

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

No parameters exist, so schema coverage is trivially 100%. The description adds minimal meaning beyond the empty schema by indicating the topic (payment platforms metadata), but lacks details on output structure or content.

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

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

Description is a noun phrase 'Payment platforms metadata' without a clear verb. It does not explicitly state that the tool lists or retrieves platforms, making it vague. Sibling tools like 'get_platform' suggest this returns multiple items, but the description fails to confirm.

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 on when to use this tool vs siblings like 'get_platform' or other list tools. No context provided for appropriate use cases.

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

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

With no annotations provided, the description carries the full behavioral disclosure burden. It candidly explains determinism, the possible return forms (single, multi_intent, partial allocation), the take-link existence condition, preservation of amount and payment pair, inclusion of trailing-30-day evidence, and the caveat that historical evidence does not currently influence ranking.

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 five sentences, and each sentence carries substantive information: purpose, ranking mechanics, output kinds, take-link conditions, and evidence behavior. It is front-loaded with the high-level purpose and contains no redundant 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 complex route-planning tool with no output schema, the description is quite complete: it states the input intent, ranking inputs, return leg taxonomy, take-link conditions, and evidence caveats. It still omits exact output fields and an explicit read-only or non-executing statement, but the core invocation behavior is well covered.

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 6 parameters have descriptions in the schema, so schema coverage is 100% and the baseline is 3. The description adds a ranking relationship to amount_usd and mentions payment-pair preservation, but it does not meaningfully clarify parameter formats, defaults, or constraints 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 opens with the verb 'Plan' and then specifies 'Ranks visible orderbook routes for a requested USDC amount', clearly identifying both the resource and the planning function. It distinguishes itself from sibling data-retrieval tools by emphasizing deterministic route ranking and allocation leg types.

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

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

The description provides a clear invocation context: use this tool when you need ranked best routes for a USDC amount, with details about route leg types and take-link behavior. However, it does not explicitly name sibling tools or state when not to use it, so it stops short of full alternative guidance.

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

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

No annotations are provided, so the description carries full burden. It only states the search scope and fails to disclose critical behavioral traits (e.g., read-only nature, authentication requirements, rate limits, pagination behavior). This is insufficient for a tool with such broad functionality.

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 wasted words. However, it may be too terse, sacrificing useful context for brevity.

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

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

Given the tool has 6 parameters, no output schema, and no annotations, the description is too minimal. It does not explain the behavior, result format, pagination (cursor vs offset), or how the search logic works across multiple entity types. This leaves agents with significant gaps in understanding.

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 high (83%), so the schema already documents most parameters. The description adds no additional meaning beyond the search scope, so it does not improve understanding beyond the baseline.

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

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

The description clearly states the verb 'Search' and the resources (intents, deposits, addresses), making the tool's purpose apparent. However, it does not explicitly distinguish this from sibling list tools like `list_intents` or `list_deposits`, leaving some ambiguity about when to prefer this tool.

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

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

The description provides no guidance on when to use this tool versus alternatives, nor does it mention prerequisites or exclusions. This is a significant gap given the presence of many sibling tools with overlapping functionality.

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