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 add meaningful behavior: it states the output includes 30d mean, volatility, IL risk, and forecast, and discloses that results are signed, timestamped, and cost $0.002 per call. It does not mention output shape or more detailed semantics of 'forecast' or 'IL risk', but it offers solid transparency beyond a bare purpose statement.

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, front-loads the main purpose, and uses a separate sentence for signature/timestamp and cost. It is not verbose, but terms like 'IL risk' and 'forecast' are left undefined, which slightly reduces 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?

For a tool with seven optional parameters, no output schema, and no annotations, the description gives a reasonable overview of returned metrics and filters but leaves important details unstated, such as the output structure, sort direction beyond 'Top', interpretation of forecast, and any access or rate-limit requirements. It is adequate but has clear gaps.

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

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

Schema description coverage is 100%, so the baseline is 3. The description echoes filters like chain, project, stablecoin, and TVL but adds essentially no meaning beyond the schema's own parameter descriptions, and it omits mention of limit, symbol, and maxSigma even though those are documented 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 defines the tool as returning top DeFi pools ranked by APY with supporting metrics and filters, so an agent can understand its core function. It does not explicitly contrast with the sibling defi_yield_movers, so it falls short of full sibling differentiation.

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

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

The intended use is implied: call this to get top-yielding DeFi pools with various filters. However, there is no explicit guidance about when to prefer this over defi_yield_movers, stablecoin_peg_monitor, or other siblings, and no when-not-to-use conditions are provided.

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

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

With no annotations, the description carries the full burden, and it does add some behavioral context: it labels the tool as an 'Anomaly feed' and discloses cost ('$0.002 per call'). It does not disclose ordering, pagination, or the exact criteria for what counts as an anomaly, but for a simple read-style movers endpoint this is a reasonable baseline.

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 short sentences with no filler. The key behavior is front-loaded, the 'Anomaly feed' classification adds context, and the cost note is useful for an agent deciding whether to call the tool. Every sentence earns its place.

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

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

For a 4-parameter tool with no annotations and no output schema, the description is minimal but mostly sufficient for selection. It conveys the intent, time windows, and cost, but it leaves chain values unspecified, does not clarify what a 'side' means relative to 'up and down', and provides no indication of the response shape.

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%: chain and window are undocumented in the schema. The description partially compensates by mentioning the '1d or 7d' windows, which maps to the window parameter, but it provides no meaning for chain and no additional semantics for limit or minTvl beyond their schema descriptions. The 'up and down' phrase hints at output sides but not parameter behavior.

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

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

The description clearly identifies the resource ('pools'), the metric (APY change over 1d or 7d), and the direction ('up and down'), so an agent can tell what the tool returns. It does not explicitly distinguish itself from the sibling defi_top_yields, but the 'APY change' framing strongly implies movers vs steady top yields.

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 'Anomaly feed' implies the tool is for detecting unusual APY movements, which gives some usage context. However, there is no explicit when-to-use versus alternatives such as defi_top_yields, no exclusions, and no guidance on selecting between 1d and 7d windows.

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 burdenessed. It discloses the $0.002 per call cost and describes the output contents and selection behavior (depegged coins plus largest by supply). It does not specify response format or pagination, but for a read-only monitor the main operational facts are present.

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 with no filler. The core behavior is stated first, followed by the pricing constraint. Every word earns its place.

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

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

For a simple read-only tool with zero required parameters and a fully documented schema, the description is nearly complete. It covers what data comes back and the cost, and the sibling list provides selection context. The main gap is a structured return format, but no output schema was provided.

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

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

Schema description coverage is 100%, so the schema already explains each parameter. The description adds context around 'depegged' and 'largest by supply' which loosely maps to threshold/limit/minCirculating, but it does not materially clarify parameter usage beyond the schema.

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

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

The description states a specific scope: it returns depegged USD stablecoins plus the largest stablecoins by supply, along with price deviation and 1d/7d supply change. This clearly distinguishes it from the yield-focused sibling tools without needing to name them.

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

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

Usage context is implied by the tool's domain and the sibling list: it is for monitoring stablecoin peg health rather than yield exploration. However, there is no explicit when-to-use/when-not-to-use guidance or mention of alternatives.

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

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

With no annotations, the description carries the burden of behavioral disclosure. It does disclose the output shape (a 0-100 risk score) and the cost per call, but it does not mention whether the operation is read-only, how results are returned, or any failure modes. It adds some value but leaves meaningful behavioral 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?

The description is a single compact sentence that front-loads the key risk categories and includes the useful pricing information. There is no fluff, though the structure is a dense list rather than organized guidance.

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

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

For a relatively simple two-parameter tool, the description provides enough to understand the general purpose and call it. However, with no output schema, it does not clarify the full return structure or whether a higher score means higher risk, which is important for interpreting 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 description coverage is 0%, so the description must compensate for undocumented parameters. It implies the tool inspects a token contract, which maps to 'address', and the risk analysis is chain-dependent, implying 'chainId', but it never explicitly names or explains either parameter. The description adds minimal semantic value beyond the schema.

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

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

The description clearly identifies the tool as a token security check, listing specific risk factors (honeypot, taxes, mintable, proxy, owner powers, holder concentration) and a 0-100 risk score. This distinguishes it from the sibling tools, which focus on yields and stablecoin pegs, even though no sibling comparison is made explicitly.

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

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

No guidance is given about when to use this tool versus alternatives or when not to use it. The description is purely factual about what it checks and its price, leaving the agent to infer the appropriate use case from the tool name and 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, 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.