Pulse402 Oracle

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint, so the safety profile is covered. The description adds that results are 'live' and chain-scoped to Base, but says nothing about data freshness, upstream rate limits, or what an 'executable' path guarantees — gaps that matter for a live telemetry oracle.

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

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

A single dense sentence with no filler, and the read-only/scope qualifiers are front-loaded. 'Telemetry oracle' is slightly jargon-heavy but does not waste space.

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

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

For a one-optional-param, well-annotated tool this is close to sufficient, but with no output schema the description should sketch the shape of returned route/discrepancy data. It also omits any explanation of the threshold parameter, leaving real 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 0% for the single parameter min_spread_bps, and the description never mentions it. An agent gets no clue what the unit is, whether 10 bps is the floor for inclusion, or how the default affects results, so the description fails to compensate for the schema gap.

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: calculates live cross-DEX price discrepancies and executable smart-router paths, scoped to Base. That is concrete enough to separate it from siblings like pulse_base_liquidity and pulse_threat_intel, though it never names or contrasts them 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?

There is no statement of when to call this versus pulse_base_liquidity or the other siblings, and no prerequisites or exclusions. The agent must infer usage from the purpose sentence alone.

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

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

Annotations already declare readOnlyHint, idempotentHint, and a non-destructive profile, so the safety burden is lifted. The description still adds useful context beyond the structured fields: that data is real-time, that netflow is a 60s window, and that slippage is quoted at three fixed notional sizes. It doesn't say how fresh the reserves are, whether it is per-pool or aggregated, or what happens with an unknown symbol.

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

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

One sentence, front-loaded with the read-only nature and what is returned. No waste, no filler. It is perhaps too compressed given that the parameters are undocumented, but the sentence itself 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?

There is no output schema and no annotations about return behavior, so the description is the only place the return values are presented. It does name the three outputs, which is good. However, it omits the symbol parameter entirely and does not say whether the response is per-pool or aggregated across Base DEXes. That leaves real gaps for a tool with a complex data payload.

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 0%, so the description must carry the burden and it does not: the single 'symbol' parameter is never mentioned. The schema shows it as optional with no format, no example, and no guidance on how it filters the pools or what the default behavior is without it. The only parameter information must be guessed from the purpose sentence.

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+resource: read-only oracle returning Base DEX pool reserve deltas, 60s netflow velocity, and slippage quotes at three sizes. That is concrete enough to picture the output. It does not differentiate from siblings like pulse_arb_routes or pulse_polymarket_velocity, which also sound like data/oracle feeds, so it falls short of a 5.

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

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

No when-to-use, when-not-to-use, or alternative is named. The sibling list contains several pulse_ tools, and nothing tells the agent which one to pick for which question. The agent can only infer usage from the purpose sentence.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=true, and destructiveHint=false, so safety behavior is largely covered. The description adds useful context about what is scanned (Polymarket markets for velocity and orderbook imbalance), but it does not disclose return shape, cadence, or whether results are a snapshot versus a streamed feed.

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

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

The description is a single, front-loaded sentence that packs the read-only nature, target domain, and detection thresholds without any filler. Every phrase contributes to understanding the tool's scope.

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

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

For a complex, open-world telemetry scan with no output schema, the description gives the core detection logic but leaves important gaps: what the result set looks like, how many markets are covered, and whether the tool returns current snapshots or historical observations. More behavioral detail is needed for an agent to invoke it confidently.

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 the undocumented 'min_velocity_pct' parameter. It partially does by tying the scan to a '>2% in 5 min' threshold, which clarifies the parameter's role and default window, but it does not explicitly state the parameter's units or confirm that the 2% default maps to 'min_velocity_pct'.

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

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

The description states a specific action ('scanning Polymarket prediction markets') and the signals it detects ('probability velocity >2% in 5 min and orderbook imbalances'), which is far more specific than the name alone. It implicitly distinguishes itself from siblings like pulse_arb_routes or pulse_base_liquidity by focusing on velocity/imbalance telemetry rather than routing or liquidity depth.

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 implied by the stated scan criteria (velocity spikes and orderbook imbalances), so an agent can infer this tool is for detecting fast market movement. However, there is no explicit guidance on when to prefer this over sibling tools such as pulse_arb_routes, nor any stated exclusions or prerequisites.

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

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

The annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, and the description mostly repeats the read-only aspect. It does not explain sanitization behavior, what the feed returns, what happens to supplied text, or any rate limits or auth requirements.

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

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

The description is a single compact sentence with no wasted words, and it front-loads the read-only nature of the tool. However, the compound phrase is dense and mixes two functions, which slightly weakens structure.

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 return-value explanation, the description should clarify what an agent receives, but it does not. It also leaves the only parameter undocumented, so the definition is incomplete for even a low-complexity tool.

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

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

The single optional parameter text_to_sanitize has 0% schema description coverage and is never mentioned in the description. The phrase 'prompt-injection sanitization' hints at its purpose at best, but the description provides no meaning, format, or expected input semantics for the parameter.

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 is a noun phrase that conflates a read-only threat feed with prompt-injection sanitization, so the actual operation is unclear. Because the schema contains a text_to_sanitize parameter, an agent cannot tell whether the tool retrieves threat intel, sanitizes supplied text, or does both.

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

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

There is no guidance on when to use this tool versus its siblings such as pulse_arb_routes or pulse_base_liquidity. The only implied context is that it is security-related, but no prerequisites, alternatives, or exclusions are stated.

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