Agent Desk API (deskfeed.dev)

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: refresh cadence (every 15 minutes), disclosure of data age in every response, explicit caveat that thresholds are uncalibrated and this is observation data, not signals or financial advice, plus the paid-per-call x402 mechanics including $0.005 USDC on Base and the automatic payment challenge/retry flow.

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?

Front-loads the core purpose and trigger condition, then stacks operational details efficiently. Some phrasing is padded ('Machine-readable monitoring feed for agents tracking early on-chain activity') and the em-dash chain makes it dense, but no sentence is purely redundant.

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

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

There is no output schema, yet the description enumerates the returned fields (pool name, hourly volume, spike ratio, price move, source link), and it covers units, cadence, data-age disclosure, disclaimers, and billing. An agent has everything needed to call and interpret it.

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

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

Schema description coverage is 100%, so both limit and window_hours are already fully documented in the schema. The description mentions a 15-minute sweep and hourly spike logic but adds no syntax, format, or meaning for either parameter beyond what the schema provides.

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

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

States a specific resource and scope: volume-anomaly observations across newly created BSC pools from a 15-minute sweep, including the exact trigger condition (hourly volume spike vs prior hour, floor $1,000 and 100x). An agent understands precisely what this returns, though it never names or distinguishes itself from event_facts, market_state, or ping.

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?

Names the intended consumer ('agents tracking early on-chain activity'), which implies when it applies, but gives no explicit when-not conditions, no prerequisites, and no comparison against the sibling tools. Usage context is implied rather than prescribed.

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 and does a lot of it: it discloses the upstream data sources (DexScreener, GoPlus, honeypot.is), the exact cost ($0.02 USDC on Base), and the payment-challenge/retry mechanics, plus a scope disclaimer that the output is descriptive only. It omits rate limits and failure behavior (e.g. what is returned for an invalid or non-existent pool).

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?

Front-loaded with the payload contents in a single dense clause, followed by sources, scope caveat, and payment mechanics — every sentence carries information. The output enumeration is long but each item is a distinct field an agent would otherwise not know about, given there is no output schema.

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, enumerating the returned fields is essential and done well, and the payment model is fully explained. Remaining gaps are error/failure behavior and any latency or rate-limit expectations for a tool that fans out to three upstream providers.

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

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

Schema description coverage is 100%, so both parameters are already documented, including the token-to-pair resolution and the window_hours mapping to DexScreener windows. The description adds no meaning beyond that — window_hours is not mentioned at all — so the baseline 3 applies.

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

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

Names a specific resource (BSC pool) and enumerates exactly what the autopsy returns: age, liquidity, volume/spike ratios, buy/sell pressure, holder concentration, LP lock, honeypot/tax/mint/ownership flags, and a 0-100 risk grade. That is far more than a restatement of the name. It does not, however, differentiate itself from the sibling bsc_verdict, which by name appears to also produce a verdict — an agent must guess which to pick.

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?

States clearly what input is accepted ('BSC pool/pair address', with token addresses auto-resolving to the largest pair) and explains the x402 payment retry flow, so an agent knows an initial 402 is expected rather than an error. It gives no explicit when-to-use/when-not or a named alternative among bsc_verdict/bsc_alerts, which keeps it below a 5.

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

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

With no annotations, the description carries the full burden and does so well: it names data sources (GoPlus, honeypot.is, DexScreener), states results are 'Live per request' (no caching), flags 'not financial advice', and fully explains the x402 pay-per-call cost, network, automatic payment challenge, and client retry 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 core purpose and outputs are front-loaded, and each clause (sources, disclaimer, payment flow) carries distinct information. It is a dense single paragraph rather than a run-on, though the payment/provenance clauses could be separated for faster scanning.

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

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

There is no output schema, so the description must describe returns — and it enumerates every field the caller gets (score, grade, take, risk facts, card link). It also covers provenance, freshness, legal caveat, and the payment handshake, leaving nothing an agent needs in order 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 coverage is 100% and the single 'token' parameter is fully documented in the schema (0x + 40 hex format). The description only restates 'send a BSC token address', adding no syntax or format detail beyond the schema, so the baseline 3 applies.

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

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

The description states a precise verb+resource: send a BSC token address, receive a risk verdict (score, grade, plain-language take, risk facts, card link). The scope is specific enough that no sibling (bsc_alerts, event_facts, market_state, ping) could be confused with it, even without naming an alternative.

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

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

'in one call' implies this is the one-stop risk check, suggesting when to reach for it over composing multiple sources. However, there is no explicit when-not, no named alternative, and no statement of prerequisites beyond the payment note. Usage is implied rather than directed.

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 present, the description carries the full burden and does so well: it discloses freshness ('Fresh every 15 minutes'), trust-tier semantics distinguishing primary official sources from aggregated headlines, and the exact payment behavior ('$0.005 USDC on Base', challenge returned automatically, x402-capable clients retry). Cost, auth flow, and data provenance are all surfaced.

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?

Front-loaded with what the tool returns, then filters, then freshness, then payment mechanics — a sensible ordering with no filler. It is dense but slightly overloaded for a single paragraph, with the return-field enumeration competing with the payment instructions.

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, so the description's enumeration of returned fields (source, publisher, timestamp, original link, trust tier) is doing necessary work, and the payment/freshness context covers the rest of the invocation envelope. Minor gaps remain on error handling beyond the payment retry path and any pagination behavior for limit.

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 three parameters (limit, symbol, category) are already documented with examples and bounds. The description only restates the filter dimensions ('symbol, category, and count') without adding syntax or defaults, so the baseline 3 is correct.

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 precise resource with scope: 'Verified market-moving events for crypto agents' and enumerates the payload fields (headlines categorized, tagged to BTC/ETH, source, publisher, timestamp, link, trust tier). The verb is implicit (returns events) rather than explicit, and no sibling tool (bsc_alerts, market_state, ping) is named for contrast, so it stops short of a 5.

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

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

Usage is implied through 'Filter by symbol, category, and count,' which tells the agent the levers it can pull, but there is no explicit statement of when to reach for this tool over market_state or bsc_alerts. The x402 payment note gives operational context for invocation but not selection guidance.

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

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

With no annotations, the description carries the full burden and does so well: 15-minute refresh cadence, data age disclosed in every response, read-only 'descriptive data' framing, and detailed payment behavior (x402, $0.01 USDC on Base, automatic payment challenge with retry semantics). These are exactly the non-obvious operational facts an agent needs.

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?

Front-loaded with the resource and symbol scope, then progressively adds metric list, usage note, freshness, and payment. Dense but every sentence carries information; the 'not financial advice' clause is the only near-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?

There is no output schema, so the description compensates by enumerating the returned fields (mark/index price, funding rate, OI change, taker buy share, per-timeframe EMA/RSI/ATR, prior 20-bar high/low). Payment, freshness, and symbol scope are all covered, leaving no material gap for 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 coverage is 100% with an enum and an inline default, so the schema already documents the only parameter, including the ALL value. The description adds only the implicit notion of multi-symbol coverage in one call, which is marginal. Baseline 3 applies.

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

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

The description states a specific verb-scope-resource combination: multi-timeframe market state for a named list of perpetual futures symbols returned in one call, then enumerates the metrics returned. It is unmistakable against siblings (bsc_alerts, event_facts, ping), which cover unrelated domains.

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

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

It names the target consumer and context — 'trading agents needing clean market context' — which tells the agent when this is the right call. It does not name any alternative or when-not-to-use condition, so it stops short of a 5.

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

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

No annotations are provided, so the description carries the full burden. It adds only the cost disclosure "(free)" and says nothing about the response shape (status code, latency, uptime), error behavior, or rate limits — significant for a probe tool whose entire value is its return value.

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 words plus a parenthetical, front-loaded with the core purpose and zero padding. It is arguably under-specified rather than wasteful, which is a completeness issue rather than a structure one.

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 should compensate by describing the result of a successful/failed ping. For such a trivial, universally understood tool the omission is survivable, but it is still a real gap for an agent trying to interpret the response.

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

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

The tool takes zero parameters, which is the baseline-4 case, and the empty object schema is fully consistent with the description. Nothing more is needed here.

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?

"Health check" names a specific, widely-understood operation and the tool has zero parameters, so an agent knows exactly what it does. It does not need to distinguish itself from bsc_alerts/event_facts/market_state, which are in unrelated domains, but it also gives no hint of what a "ping" 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 explicit when-to-use or when-not-to-use statement, but usage is strongly implied: a free health check is for verifying service liveness before other calls. The "(free)" tag usefully signals it is cheap to call, which is a mild routing hint.

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