Degenscan Intel

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

With readOnlyHint=true already covering the safety profile, the description adds real behavioral context beyond annotations: per-call cost ($0.005/call), a 100 free calls/day quota, and the shape of what is returned (direction, confidence, horizon, tradable_now/next_open). It does not cover pagination or latency, so it falls short of a full behavioral picture.

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?

It is front-loaded with what the tool returns, then usage, then filtering, then cost — a logical order with no filler sentences. It is dense and runs long for a single paragraph, but each clause (event kinds, impact fields, pricing) 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?

With no output schema, the description carries the return-value burden and does so by describing the per-asset impact fields and tradable_now/next_open flags. Combined with 100% schema coverage on all 8 parameters and stated cost/quota, an agent has everything needed to call 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 the baseline is 3, but the description adds practical, non-schema meaning: that past `since` values backtest, and that min_confidence>=0.4 is a sensible acting threshold while universe=["NVDA","BTC"] narrows impacts. That is useful guidance over and above the field docs.

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 gives a specific verb ('List') and resource ('market-moving events since a point in time') and enumerates the event kinds covered, so the scope is unambiguous. It stops short of naming or contrasting the relevant siblings (impact_for, exposure_graph), so an agent cannot fully rule out overlap from the text alone.

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 supplies concrete use cases ('what happened in the last N hours that affects my book', and backtesting with a past `since`) plus operational filtering advice (universe=["NVDA","BTC"], min_confidence>=0.4). It does not state when NOT to use this tool or name the alternative to reach for instead, so it is clear context without 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?

Annotations only declare readOnlyHint=true; the description adds substantive behavioral context beyond that, disclosing the per-call cost ($0.02/call) and the shape of the returned reasoning. It does not mention rate limits or latency, but the cost disclosure is a meaningful operational trait an agent should know before invoking.

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, front-loaded with what the tool returns, then when to use it, then the id source and cost. No filler and every clause carries distinct 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?

No output schema exists, but the description enumerates the return content (rationale, graph path, source link, corroboration), so an agent knows what to expect. Combined with the read-only annotation and the id-provenance note, nothing needed to call it correctly is missing.

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% and the single param has no schema description, but the description compensates by explaining provenance: 'Takes the event id from those tools' (events_since/impact_for). That tells the agent where a valid value comes from, which the bare string-typed event_id field does not.

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 (explain) and resource (ONE event's impacts) and enumerates exactly what the explanation contains: direction/confidence rationale, exposure-graph path, source document link, corroborating sources. It also distinguishes itself from siblings events_since/impact_for by naming them as the source of the event id rather than duplicating their role.

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?

Gives explicit triggering conditions: use when an impact from events_since/impact_for is surprising and you need the reasoning before acting, or when you want to log a rationale. Both the alternative tools and the when-to-use condition are named, leaving little to inference.

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 declare readOnlyHint=true, so safety is covered; the description adds genuinely new behavioral context beyond that: the content of the returned graph and a per-call cost of $0.002, which matters for invocation decisions on an agent budget. It stops short of describing result shape or how large a depth=3 response can get.

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 resource definition, then usage, then cost in three efficient moves with no filler. The long enumerative first sentence is dense but every item listed is a distinct return category an agent would otherwise have to guess.

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, the description carries the burden of describing returns and does so by enumerating node types, including coordinates for facilities. It omits any indication of result size, structure, or stability, which is a minor gap for a graph-traversal tool with a depth cap of 3.

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 documents both asset_id (with example ids and a pointer to `universe`) and depth (hop meaning and default). The description's mention of 'second-order trades' loosely reinforces depth=2 but adds no syntax or semantics the schema lacks; 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?

Names a specific resource (an asset's exposure graph) and enumerates its contents concretely: suppliers, customers, revenue/production countries, commodities, regulators, indices, correlated assets, facilities with coordinates. It is clearly not a generic lookup, but it never contrasts itself against the closest sibling, impact_for, which appears to serve overlapping analytical purposes.

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?

Gives two explicit use cases: finding second-order trades (event on TSM → NVDA/AAPL) and identifying which regulators/countries to watch for a holding. That is strong context, but there is no when-not-to-use guidance and no alternative tool named for cases where a direct impact read is wanted instead.

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 readOnlyHint=true already covering the safety profile, the description goes further by disclosing concrete cost ($0.003/call) and the shape of the payload (bias range, drivers, source events with graph path). It omits latency/rate-limit behavior, but adds real context beyond the annotation.

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 sentences, front-loaded with what the tool returns before the usage guidance. Every clause carries information — fields, range, use case, price — 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?

With no output schema, the description carries the burden of explaining return values, and it does so by enumerating the payload fields. Combined with the readOnly annotation, an agent has enough to call it correctly, though precise field formats/typing are left implicit.

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 limit, since, and asset_id are already fully documented in the schema. The description reinforces the window concept but adds no syntax or format detail beyond the schema, making the baseline 3 appropriate.

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 resource and scope (net directional pressure on ONE asset over a window) and enumerates what the result contains: bias (−1..+1), event count, strongest supportive/negative drivers, and source events with rationale and graph path. It is clear what the tool produces, though it does not explicitly distinguish itself from siblings like explain or exposure_graph.

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 gives concrete when-to-use guidance: before entering or sizing a position, or to explain a move (with a worked example, 'why is MSTR down today?'). There are no explicit exclusions or named alternatives, so it falls 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?

Annotations only declare readOnlyHint=true, so the description carries the rest and does: it discloses the $0.01/call cost, frames output as information not a forecast, and names the enrichment fields returned. It stops short of describing resolution failure behavior or feed latency.

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 core action and scope, then prerequisites and cost. It is dense but mostly earns its length; the parenthetical example list runs slightly long.

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, the description compensates by enumerating what comes back (events with relevance, source tier, corroboration, per-asset impacts). Inputs, pricing, and the information-not-forecast caveat are covered; the shape of the return payload could be more explicit.

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 limit, since, and market are fully documented in the schema, including the Gamma API resolution path. The description adds no additional parameter semantics beyond that 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?

States a specific verb and resource: resolves a market (by id, slug, or question text) to odds, then returns primary-source feed events bearing on the question. The listed return attributes (relevance, source tier, corroboration, per-asset impacts) make the tool's output scope unambiguous and distinguishable from generic feed siblings like events_since.

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?

Gives explicit when-to-use context: before trading or quoting a probability on Polymarket/Kalshi-style markets, or to detect a fresh primary event the market hasn't repriced. No when-not or named alternative sibling is given, which keeps it 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?

Annotations already declare readOnlyHint=true, so safety is covered. The description adds genuinely new behaviorally relevant context: the per-call cost ($0.01/call) and the recommended polling cadence, both of which affect how an agent should budget and schedule calls.

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 value proposition, then the cadence guidance, then cost — every sentence earns its place and nothing is padded. Dense enumeration of contents is scannable rather than bloated.

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 what comes back, and it does: venue statuses, next opens, ranked event pressure, top-severity events, and prediction-market probabilities. Combined with cost and cadence, an agent has enough to call 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?

The tool takes zero parameters, so the baseline is 4. The description correctly implies a parameterless, fire-and-forget snapshot, and there is nothing in the schema that needs compensating for.

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 enumerates its contents (venue open status, event pressure, top-severity events, prediction-market probabilities), which is concrete and non-tautological. It doesn't explicitly name a sibling to contrast against, but 'one-call situational picture' versus the narrow siblings (impact_for, events_since) makes the breadth distinction inferable.

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 says when to call it — 'first in a session, or every few hours, to decide whether to look deeper' — giving clear cadence and intent. It stops short of naming alternatives or stating when not to use it (e.g. when a targeted sibling like impact_for is sufficient).

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?

readOnlyHint=true already tells the agent this is a safe read. The description adds real context beyond annotations: the connector count (~40), the 'best-effort' reliability model, and the 'Free' cost signal, which is meaningful for an agent planning API budget. It stops short of noting auth needs or latency.

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 sentences, zero filler, and the content list is front-loaded before the usage guidance. Every clause carries information an agent needs.

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, the description compensates well by enumerating the returned fields and the tool's cost. It is essentially complete for a zero-param read tool, though it omits error/pagination or freshness-window details that could matter.

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?

Zero parameters, so there is nothing for the description to disambiguate; the baseline of 4 applies. The description correctly spends no words on phantom inputs.

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 (transparency report on ~40 data connectors) and enumerates the fields returned: tier, cadence, last successful run, items ingested, last error. Easily distinguished from siblings like universe or regime_snapshot, which cover different 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?

Gives clear context for use: 'judge freshness before trusting a quiet feed' and 'see which sources are best-effort.' That is actionable when-to-use guidance, though it names no explicit alternatives or exclusion conditions among the 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?

readOnlyHint=true already establishes this is a safe read, so the description's job is to add context beyond that. It does: it discloses the version stamp returned on every response, the exposure tags included, and that the call is free (a cost signal useful for agents optimizing quota). It stops short of describing pagination or response size, which for a 'list every asset' call would be worth knowing.

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 sentences, front-loaded with what is returned and followed by the single action instruction. The parenthetical enumeration is dense but every element is load-bearing, and there is no redundant restatement of the title.

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 input parameters and no output schema, the description carries the full burden of describing the return value, and it does: asset ids, class, name, exposure tags, and universe version. It also states the free cost profile, so an agent has everything needed to call and consume this 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 takes zero parameters, so per the rubric the baseline is 4. The description correctly implies there is nothing to configure — it is a whole-universe dump — which matches the empty 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 names a specific verb (list) and resource (every asset id the service scores), then enumerates the covered classes (top-100 US equities, indices/ETFs, 15 crypto, commodities, FX, rates) and the returned fields. An agent can distinguish this from siblings like exposure_graph or regime_snapshot without opening a schema.

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 gives explicit sequencing guidance: 'Call it once to map your tickers to asset ids before using the other tools.' That tells the agent when this tool is appropriate relative to the rest of the set, though it doesn't state exclusions or conditions under which re-calling is warranted.

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