yieldprobe: DeFi intel for agents

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

With no annotations, the description carries the full burden and does well: it discloses the ranking methodology ('ranked by spot APY, not a safety verdict'), provenance ('DefiLlama data, signed and timestamped'), and cost ('$0.02 USDC on Base per call'), all of which an agent needs before invoking. It does not cover auth/rate-limit behavior or result pagination, leaving minor gaps.

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

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

Three tight sentences: purpose and filters first, caveats and ranking second, provenance and price last. Every sentence carries information, though the pricing/provenance sentence could be considered secondary to invocation decisions.

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

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

No output schema exists, and the description compensates by naming the return fields (APY, 30d mean, volatility, IL risk) and the ranking basis. Combined with full schema coverage on inputs, an agent has enough to invoke correctly, with only minor gaps around result volume/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 description coverage is 100%, so all seven parameters are already self-documenting. The description echoes the filter dimensions (chain, stablecoin exposure, project, min TVL) but adds no syntax, defaults, or format guidance beyond what the schema provides; 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?

States a specific verb and resource ('Compare DeFi yield candidates') and immediately scopes the output fields returned (spot APY, 30d mean, volatility, IL risk). It also carves out adjacent territory by declaring it is 'not a safety verdict or executable deposit quote', which distinguishes it from sibling tools like token_security_check and any deposit-execution 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 phrase 'before choosing a deposit' gives a clear situational trigger for use, and the 'not a safety verdict or executable deposit quote' clause states an explicit non-use case. It stops short of naming a specific alternative tool to use instead, so it falls just below the top score.

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 behavioral burden. It usefully discloses pricing ($0.02 per call), which is real value add, but says nothing about return shape, whether both gainers and losers are always returned, or rate/usage limits.

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

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

Three short clauses, front-loaded with the core behavior, then the framing (anomaly feed), then the cost. Nothing is wasted, though it is terse enough that it under-explains rather than over-explains.

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 4-param tool with no annotations, no output schema, and zero required parameters, the definition leaves several things unsaid: what the response contains, how chain interacts with results, and when to prefer this over defi_top_yields. It is usable 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 coverage is 50%: limit and minTvl carry their own defaults in the schema, while chain and window do not. The description mentions the 1d/7d window values and the up/down split, partially covering the undocumented params, but says nothing about chain filtering or how limit splits across sides.

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 resource (pools) and the exact metric (largest APY change, up and down) with the two supported windows, which is enough to distinguish it from a static ranking tool like defi_top_yields. It stops short of naming siblings explicitly, so an agent must infer the delta-vs-level distinction itself.

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

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

"Anomaly feed" gestures at a use case but gives no explicit when-to-use guidance, no contrast with defi_top_yields or stablecoin_peg_monitor, and no prerequisites. The agent is left to guess whether this is for monitoring, research, or alerting.

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 supplied, so the description carries the full behavioral burden. It does disclose genuinely useful non-schema behavior: the per-call cost ($0.02) and the exact nature of the returned data. However, it never says whether calls are read-only/side-effect free, whether results are cached or point-in-time, or how 'full' interacts with the other filters — gaps that matter for an unannotated tool.

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

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

Two tight sentences with zero filler; the returned content is front-loaded and the cost note is a single trailing clause. Nothing is redundant or 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?

With no annotations and no output schema, the description covers the essentials for a zero-required-parameter query tool: what comes back and what it costs. It is slightly short on behavioral context such as read-only nature and result freshness, but a calling agent has enough 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 every parameter (full, limit, threshold, minCirculating) is already documented in the schema with defaults and bounds — the baseline of 3 applies. The description reinforces the 'largest by supply' and 'depegged' selection logic that limit/minCirculating/threshold implement, but adds no syntax or interaction detail beyond the schema.

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

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

The description states concretely what the tool returns: every depegged USD stablecoin plus the largest by supply, along with price deviation and 1d/7d supply change. That is a specific resource with defined scope, and it is clearly distinct from the yield- and security-oriented siblings. It stops short of naming those siblings or an explicit 'not for X' clause, so it is clear but not fully differentiated.

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 statement of when to use this tool versus defi_top_yields, token_security_check, or any alternative, nor any prerequisites or exclusions. The use case (checking peg status) is only inferable from the name and the returned fields. This is the definition's weakest area.

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 usefully discloses the output shape (0-100 risk score) and a real behavioral trait, the $0.02 per-call cost. However it says nothing about authentication, rate limits, or behavior on unsupported inputs, leaving meaningful gaps for a zero-annotation tool.

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

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

Two short sentences, front-loaded with the substantive risk dimensions and ending with the cost. Every clause earns its place 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?

For a simple two-parameter read tool with no output schema, the description covers what is checked and what is returned, which is a reasonable minimum. It is still incomplete on input expectations (chains, address format) and on how the risk score should be interpreted or what happens on failure.

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% and the description adds no parameter meaning at all — it never mentions the address or chainId inputs, the required 0x-prefixed 40-hex address format, or which chains are supported. The only semantics live in the raw schema enum/pattern.

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

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

The description names the specific risk dimensions checked (honeypot, taxes, mintable, proxy, owner powers, holder concentration) and the output form (0-100 risk score), so the agent knows exactly what the tool does. It lacks an explicit verb+resource framing like 'analyze a token contract', so it stops short of a 5, but the purpose is unambiguous.

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

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

Usage is only implied: an agent can infer this is the tool to call when evaluating a token's safety before interacting with it. There is no explicit when-to-use statement, no exclusions, and no mention of the sibling tools, which are unrelated yield/stablecoin tools anyway.

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

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

With no annotations, the description carries the full burden. It discloses the cost (free) and the specific types of information included. It does not explicitly state whether the operation is read-only or any side effects, but for an info-gathering tool this is implied and not a major gap. It also omits any mention of return format, but given the absence of an output schema, the description provides adequate transparency for the agent.

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

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

The description is a single, information-dense sentence. It front-loads the key facts ('Free') and then lists the content areas and the usage guidance. Every word earns its place, and it is highly efficient.

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

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

For a zero-parameter tool with no output schema, the description fully covers what the tool does, what it contains, and when to use it. There is nothing else an agent needs to know to decide whether to invoke it. The absence of return details is acceptable given the simple nature 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?

The tool has zero parameters, so the schema provides no parameter details. The description does not need to explain parameters, and the baseline for 0 params is 4. It correctly adds no irrelevant parameter 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 clearly states the tool's purpose: it provides service information (prices, payment network, HTTP endpoints, and how to pay). This distinguishes it from the sibling tools which focus on specific financial data like yields, movers, stablecoin peg, and token security. No confusion with alternatives.

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

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

Explicitly instructs the agent to call this first when uncertain, which is a direct usage guideline. It implies this tool is a prerequisite or fallback for orientation, though it doesn't list exclusions. Still, the guidance is actionable and clear.

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