Degenscan Intel

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

Annotations declare readOnlyHint=true, so the safety profile is already covered. The description adds the per-call cost ($0.005/call), which is useful behavioral context, but it does not disclose return format, pagination, rate limits, or filtering behavior beyond the brief 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?

Two short sentences: one purpose statement, one cost note. No filler, and the core purpose is front-loaded.

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 an 8-parameter read-only tool with no output schema, the description is too thin—it omits return value expectations, filtering semantics, and the roles of parameters like q, kinds, until, min_severity, and min_confidence. The schema covers some parameter detail, but the description does not compensate for the lack of an output schema or complex usage context.

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 75%, so most parameters are documented in the schema. The description only references the since parameter via <since> and gestures at the universe filter; it adds no syntax, format, or meaning beyond what the schema already 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?

The description frames a retrieval task—what happened in the world since a given time that affects the universe—so the agent understands the resource is world events and the temporal scope. However, it lacks an explicit action verb like 'list' or 'retrieve', and it does not name any sibling tool to differentiate from impact_for or regime_snapshot.

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 on when to use this tool versus siblings like impact_for, regime_snapshot, or explain. There is also no mention of prerequisites, alternative tools, or 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?

The readOnlyHint annotation already establishes this as a safe read, so the bar is lower. The description adds genuinely useful behavioral context in the form of pricing ($0.02/call), which is not captured by any structured field. It stops there, with no mention of what happens for an unknown event_id or what the rationale looks like.

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, front-loaded clauses with zero filler: purpose first, cost second. Very tight and appropriately sized for a one-parameter tool.

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 returns, and 'human-readable rationale' is only a partial answer. For a single-parameter, read-only tool this is minimally adequate but leaves the response shape and error behavior unstated.

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?

One required parameter (event_id) with 0% schema description coverage. The phrase 'one event's impacts' implies event_id identifies a single event but adds no format, source, or validity detail. Marginal value over the schema, hence a middling score rather than a 4.

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 (explain) and resource (one event's impacts) and clarifies the output is a human-readable rationale. However, it never distinguishes this tool from the sibling impact_for, which presumably also concerns event impacts, so an agent cannot tell which to choose without outside knowledge.

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 when-to-use, when-not-to-use, or alternative guidance at all. The proximity of siblings like impact_for and exposure_graph makes the absence of routing guidance a real gap.

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 non-destructive read, so the baseline bar is lower. The description adds a genuinely useful behavioral fact the annotations do not carry: the per-call cost of $0.002. It still says nothing about graph size, latency, or how depth affects the response.

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, and the core resource description is front-loaded ahead of the cost note. Efficient, though the terseness is part of why other dimensions are under-served.

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 beyond readOnlyHint, so the description carries the full load. It omits the semantics of depth, gives no sense of the shape or size of the returned sub-graph, and offers no usage context, leaving meaningful gaps for a 2-parameter graph-expansion 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?

Schema description coverage is 0%, so the description must compensate for the two undocumented parameters, and it does not. Neither asset_id nor depth is mentioned; in particular the meaning and impact of depth (1-3, default 2) is left entirely to 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?

States a specific resource (a sub-graph around an asset) and enumerates exactly which node types it contains: suppliers, customers, countries, commodities, regulators, correlated assets. That is concrete and lets an agent know what comes back. It lacks an explicit verb and does not differentiate itself from the closely related sibling impact_for, 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?

The description gives no when-to-use guidance, no prerequisites, and never names or contrasts an alternative such as impact_for or explain. An agent must infer the routing decision from the sibling names 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?

readOnlyHint=true already establishes this as a safe read, so the description's job is to add context beyond that. It does disclose per-call cost ($0.003) and that source events are returned alongside the aggregate, which is useful. It says nothing about latency, rate limits, or how the aggregate is computed/windowed, so it is only a partial addition.

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 sentence with the resource and scope first, the returned payload second, and the cost last. Every clause carries information; there is 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 and three parameters, the description needs to carry more weight. It explains the headline field and cost, but leaves the since-window semantics and the interpretation of "directional pressure" (scale, sign, time decay) to guesswork, which matters for correct 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 only 33%: asset_id is the lone documented parameter, while limit and since are bare fields with defaults but no explanation (notably the string format and accepted values for since beyond the "24h" default). The description supplies no parameter meaning at all and therefore does not compensate for the coverage 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?

The description names a specific resource and the shape of the result: aggregated directional pressure on a single asset, plus the underlying source events. An agent can see it is an asset-scoped aggregation rather than a raw event feed like events_since. It does not explicitly differentiate itself from siblings such as explain or exposure_graph, 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?

There is no statement of when to call this versus events_since, explain, or exposure_graph, and no prerequisites or exclusions are given. The only usage-adjacent cue is the price tag, which hints at cost-sensitivity but not at routing.

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 the safety profile is covered. The description adds a genuinely useful behavioral fact - $0.01/call cost - but says nothing about freshness, latency, response size, or rate limits for a snapshot 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?

A single sentence front-loads the highest-value content and closes with the cost. No filler, no redundancy with 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 output schema, the description must convey return content, and it does list the four result categories. For a zero-parameter read-only snapshot this is nearly sufficient, though freshness and response shape are left unstated.

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. There is no parameter semantics to clarify, and the description correctly implies a no-argument call.

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 specific content the tool delivers: open venues, 24h event pressure by asset, high-severity events, and prediction-market context. This makes the resource clear, but it never states a verb or explicitly distinguishes itself from siblings like universe or events_since, 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?

There is no when-to-use guidance and no named alternatives among the six siblings. An agent must infer the appropriate context from the content list alone, and the only extra clause is pricing.

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 the safety profile, so the description's useful addition is scoping: it covers *every* connector and enumerates the three returned facets (health, cadence, last run). It still doesn't disclose freshness, re-run cost, or whether results are cached, but with annotations carrying the safety burden a 3 is appropriate.

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 fragments, fully front-loaded: the payload first, the cost qualifier second. Nothing is padded and an agent can parse it in one read.

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, read-only, no-output-schema tool, the description tells the agent what it gets back (health, cadence, last run across all connectors) and adds a cost cue. Given how little there is to specify, that is close to sufficient, though it stops short of describing formatting or freshness.

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; there is nothing for the description to disambiguate and no risk of misuse from vague argument semantics.

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 the resource (every connector) and the three properties reported (health, cadence, last run), so the agent knows exactly what this yields. It's a noun phrase rather than verb+resource, and the tool name/description shift between 'sources' and 'connectors', but the intent is unambiguous and it doesn't overlap with siblings like regime_snapshot 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?

No when-to-use guidance, no prerequisites, and no routing to or away from siblings. The only usage-adjacent signal is 'Free', which hints this is a no-cost status check, but that is not the same as telling the agent when to prefer this over universe or regime_snapshot.

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 declaring this a safe read, the description adds real context beyond annotations: the scoping of the universe (volume-ranked top-100 plus other asset classes) and that the call is free. It does not disclose refresh cadence, universe size, or whether results are paginated, so behavioral disclosure remains partial.

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 front-loaded sentence covering resource, scope, returned fields, and 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 zero-parameter lookup with no output schema, the description conveys the resource, its coverage, and that it returns ids and tags, which is most of what an agent needs. Slightly short on the shape of the response (count, ordering, update frequency), but adequate overall.

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 there are no parameter semantics for the description to compensate for — the baseline for a parameterless tool applies. No misleading parameter claims are made.

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 what the tool returns: the current asset universe with ids and tags, and enumerates the covered asset classes (top-100 US equities by volume, indices/ETFs, crypto, commodities/FX/rates). This is a distinct reference-listing purpose that an agent can separate from siblings like explain, regime_snapshot, or impact_for. It lacks an explicit verb and does not name a sibling, but the resource is specific and 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 would infer this is the tool to call to discover valid asset ids and tags before invoking other tools. No explicit when-to-use, when-not-to-use, or alternative is given. The 'Free' note hints it can be called liberally, which is mild guidance, but nothing routes the agent between this and the other listing-like siblings.

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