x402Pulse

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

With no annotations, the description carries the full behavioral burden. It does useful work by disclosing the payload shape ('each with prices and the skilled-trader lean from x402Pulse scoring') and a disclaimer framing, which is more than most. It is silent on freshness/caching of attention signals, whether results are ranked or capped, and any rate or authentication constraints — material gaps for a time-sensitive market 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?

Three short sentences, front-loaded with the core concept before the use-case framing and the disclaimer. Little waste, though 'Attention meets prediction markets' is mildly promotional framing rather than informative content.

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 two-parameter, no-annotation, no-output-schema tool, the description adequately conveys what comes back and what it is for. But it leaves the `lang` parameter's meaning entirely unexplained and says nothing about recency of the attention signals, which is the central value proposition an agent must trust.

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 50%, and the description adds nothing to close the gap: `lang` has no schema description and no explanation in prose, leaving unclear whether it selects the Wikipedia language, a locale, or the market language. `limit` is already documented in-schema as '1 to 10' and the description neither repeats nor clarifies it. No semantic value is added 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 names a specific, distinctive resource and operation: Wikipedia attention trends (trending or spiking topics) matched to open Polymarket markets, enriched with prices and a scoring-derived trader lean. That is far more than a restatement of the name. However, it never distinguishes itself from its closest siblings (attention_spikes, attention_topic, attention_trending), so an agent must infer the boundary rather than being told it.

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?

'Find markets the public is suddenly paying attention to' frames the intended use case, and 'Data, not investment advice' sets expectations about interpretation. But there is no explicit when-to-use versus when-not, no named alternative among the three sibling attention_* tools, and no stated prerequisites or locality constraints. Usage is implied rather than guided.

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 but does meaningful work: it defines the metric (ratio to previous week's median), the time window (yesterday), the data source (Wikimedia pageviews, CC0), and a data-quality caveat (likely automated traffic filtered). It omits sort order, default behavior, and any rate/pagination limits.

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 signal, followed by two short qualifier sentences on traffic filtering and licensing. The opening sentence is dense but every clause carries information; nothing is 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 and no annotations, so the description should describe what is returned (fields, ordering, whether ratios/raw counts are included) and defaults for the four parameters. It explains the concept but not the returned payload or parameter defaults, leaving real gaps for a data-query 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 coverage is only 50% and both 'lang' and 'minViews' are bare strings with no description. The description adds only an indirect hint ('Any language') for lang and never clarifies minViews, limit, or that the ratio inputs are numeric despite being typed as strings, so it 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 gives a specific resource and metric: Wikipedia articles whose pageviews surged relative to the prior week's median, with a clear signal meaning ('earliest sign of breaking public interest'). It is understandable without the schema, but it never distinguishes itself from the close sibling attention_trending, so an agent must guess between 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 is implied rather than stated: 'yesterday' and 'earliest sign of breaking public interest' suggest when the tool is relevant. However, there is no explicit when-to-use/when-not guidance and no mention of the near-identical sibling attention_trending, leaving the agent to infer 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions the data source (Wikimedia pageview data, CC0) and the output elements, but it doesn't state whether the operation is read-only (implied but not explicit), whether there are rate limits, authentication requirements, or any side effects. For a data retrieval tool without annotations, more could be said to clarify 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 description is a single sentence that is front-loaded with the core purpose and output details, followed by a usage tip and data source. It is efficient with no wasted words, though the parenthetical use case list could be seen as slightly verbose.

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?

Given three parameters, no output schema, and no annotations, the description covers the purpose and output elements but misses some contextual details like the behavior of the lang parameter, potential limitations (e.g., data freshness), and explicit differences from sibling tools. It is adequate but not fully complete.

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 67%, with parameters days and title having descriptions ('7 to 90' and 'Exact Wikipedia article title'), while lang has none. The description adds some semantic meaning by stating 'Use the exact article title, e.g. Bitcoin,' which reinforces the title requirement, but it doesn't explain the lang parameter or provide additional format details for days beyond the schema. Baseline 3 is appropriate given moderate coverage.

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 a specific verb and resource: 'Attention history for any topic: daily Wikipedia pageviews of one article...' with detail on what is returned (baseline, latest day vs. baseline, spike days, 7-day trend). It distinguishes itself from sibling tools like attention_spikes and attention_trending by focusing on a single article's history over 7-90 days. However, it doesn't explicitly differentiate from those siblings, so it's not a perfect 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 implicitly conveys when to use by specifying 'one article' and the range, but it does not provide explicit guidance on when to choose this tool over alternatives like attention_spikes or attention_trending. No exclusions or prerequisites are mentioned. This is minimal viable 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 it does disclose meaningful behavioral traits: content is cleaned of site pages, rank change vs. prior day, new entries, week-long regulars, and automated surges are flagged separately, plus the underlying data source (Wikimedia pageviews, CC0). Missing are auth/invocation traits, but for a public read-only tool this is solid disclosure.

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 the core resource and scope before the secondary signals and provenance. Efficient and well-ordered, though the middle list is dense and could be tightened.

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 appropriately describes return content (rank change, new entries, regulars, surge flags). For a 2-param read-only tool with full schema coverage this is nearly complete; default lang behavior and the meaning of the limit scale are the only 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 both parameters (lang, limit) are documented in the schema. The prose adds no parameter-level meaning, 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?

States a specific resource (yesterday's most-viewed Wikipedia articles) and a specific scope (any language, cleaned of site pages). It is concrete enough to distinguish from generic search tools, but it never names or contrasts with the closely related siblings attention_topic and attention_spikes, so sibling differentiation is left implicit.

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 'A daily read of what people are paying attention to' implies the intended cadence and context, but there is no explicit when-to-use, when-not-to-use, or alternative routing, despite multiple attention_* siblings that overlap in intent.

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 well: it discloses cadence (every 15 minutes), coverage limits (only the 30 busiest open markets), the tempering against thin evidence, the confidence rating, and a data-not-advice caveat. It omits auth/permission needs, rate limits, and what happens when no markets qualify.

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 dense, front-loaded sentence that leads with the definition before the mechanics, plus a short disclaimer. Every clause carries information, though the detector logic and caveat in a single sentence make it slightly heavy.

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 must convey returns, and it does reasonably: it explains that qualifying markets come back with a low/medium/high confidence rating. It still doesn't describe the actual response fields or ordering, leaving a modest gap.

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 only 50%, and the description adds nothing about either parameter — it never references limit or category. The category enum is self-documenting, and limit's bounds (1-20) are in the schema, so the gap is real but not severe; a baseline 3 is 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?

Specific verb+resource+scope: 'Polymarket markets where smart money disagrees with the odds,' with the exact detection criteria (skilled traders' implied probability vs. price). This clearly separates it from siblings like smart_money, skilled_whales and attention_markets.

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 strong context for when the tool is relevant: it explains the scan universe (30 busiest open markets), the refresh cadence (15 minutes) and the confidence filter, which tells an agent what questions it can answer. It never explicitly excludes cases or names a sibling to use instead, 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?

With no annotations, the description carries the full burden. It does disclose useful behavioral context: the data source (openFDA), the return shape (clean structured text) and a safety disclaimer ('Not medical advice'). It omits anything about lookups that return nothing, rate limits, or whether a missing drug is an error.

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 dense sentence that front-loads the resource and enumerates the payload, followed by a short disclaimer. Every clause earns its place, though the enumerated field list makes the sentence slightly heavy.

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 single-parameter read tool with no output schema and no annotations, the description is largely self-sufficient: it names the source, the returned fields and a liability caveat. The main missing element is any indication of behavior when the drug is not found.

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% and the single 'drug' parameter is documented as 'Drug brand or generic name'. The description's mention of brand and generic names merely echoes the schema rather than adding format, casing or matching-behavior detail, so the baseline of 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?

States a specific verb and resource (FDA drug label lookup) and enumerates the exact data returned (boxed warning, indications, contraindications, warnings, interactions, brand/generic names, manufacturer, route). It is clear what the tool does, but it never distinguishes itself from the closely named siblings health_drug_approvals, health_drug_safety and health_drug_shortages.

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 — look up a drug's label — but there is no explicit when-to-use, no exclusions, and no routing advice against the sibling drug tools (approvals vs. safety vs. label). An agent must infer the boundary itself.

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. It discloses the data source (CMS), the breadth of the scorecard, and the comparison methodology (better/same/worse vs national average), and read-only lookup is strongly implied by 'scorecard' and 'Look up'. It does not state behavior for unknown IDs or names, whether results are cached/rate-limited, or what happens when multiple hospitals match a name.

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?

Single dense sentence that front-loads the resource and its returned fields, then closes with the lookup modes and disclaimer. Every clause carries information, though splitting the returned-fields list from the lookup instruction would improve scanability.

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, so the description must describe returns itself — and it does, covering ratings, comparisons, and rank/percentile. Combined with 100% parameter coverage, the only remaining gap is edge-case behavior (no match, ambiguous name) which is a minor omission for a lookup 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 coverage is 100%, so the baseline is 3, but the description adds real semantics beyond the schema by specifying the acceptable lookup combinations (ID alone, or name together with state) — a coupling the flat schema does not express. It does not clarify what happens when only name is supplied without state.

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 concrete verb and resource ('Hospital scorecard for any U.S. Medicare hospital') and enumerates the returned content: CMS star rating, type, ownership, emergency services, national-average comparisons, and state rank/percentile. An agent can immediately tell this apart from health_drug_label, health_recalls, or travel_advisory.

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 lookup guidance ('Look up by CMS facility ID or name plus state') and scopes the domain to U.S. Medicare hospitals, with a 'Not medical advice' boundary. It stops short of naming when not to use it or pointing at close alternatives such as health_hospitals, so sibling routing is left 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?

No annotations exist, so the description carries the full burden. It usefully discloses the sort logic (CMS star rating, then net score defined across mortality, safety, readmissions) and a liability disclaimer, but says nothing about authentication, rate limits, result size, or what happens when no filters are supplied.

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 dense but front-loaded paragraph: purpose first, ranking methodology second, available filters third, disclaimer last. No sentence is filler, though the nested parenthetical for the net-score definition and type enum is slightly cramped for 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?

With no annotations, no output schema, and all parameters optional, the description should clarify default behavior — it never says what comes back when state/city are omitted (all states? error?). It covers sources and ranking well but leaves the zero-filter call ambiguous.

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%, so the description must compensate — and it largely does, naming city, state, minimum stars, emergency services, and the four hospital type enum values (acute, critical access, children's, psychiatric) with plain-language meaning. Only the `limit` parameter (1-50) is left to the schema alone.

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 (hospital ranking) with the data source named (CMS Care Compare), which is far more than a restated name. However, it does not distinguish itself from the singular sibling tool health_hospital, so an agent has no signal for which of the two 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?

The filtering capabilities implicitly tell the agent when the tool is applicable (need a ranking for a state/city with optional stars/type/emergency filters). There is no explicit when-not guidance, no prerequisite statement, and no routing to or away from the health_hospital sibling.

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 behavioral burden. It does add useful context — the data source ('openFDA data'), a disclaimer ('not medical advice'), and an explanation that Class I is the most serious — but it says nothing about result limits, pagination, or that this is a read-only lookup (inferable but unstated).

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 paragraph that front-loads the resource and returned fields before moving to filters and provenance. Every clause carries information; only the trailing 'not medical advice' is marginally tangential, though still purposeful for a health data 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 and no annotations, the description does the heavy lifting by enumerating returned fields (product, reason, status, dates, distribution) and naming the data source. The only meaningful gap is that the limit parameter's cap (1-50) and result-set behavior are left unexplained.

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 60% (days and limit have partial descriptions, firm has one, type and class have none). The description compensates by mapping filters to parameters — class, company (firm), and time window (days) — and by explaining the Class I/II/III severity ordering, which is genuine semantics the enum alone does not convey. It does not cover the limit parameter's meaning.

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 the specific resource (FDA drug and food recall enforcement reports) and enumerates the returned content: recall class, recalling firm, product, reason, status, dates and distribution. This is clearly distinguishable from sibling health tools such as health_drug_safety or health_drug_approvals, which cover adverse events and approvals rather than recalls.

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 says 'Filter by class, company and time window', which implies how to narrow results, but never states when to choose this tool over health_drug_safety or health_safety_signals, nor any exclusions. Usage is inferable from the resource description but not explicitly guided.

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 does add meaningful interpretive context — the signal definition and the explicit caution that a signal is not evidence of harm or medical advice — but it says nothing about return format, data recency, or FAERS reporting limitations, which an agent would need for a read tool with no structured safety hints.

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 purpose and method, then the caveats; every sentence carries substance and there is no filler. It is 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 annotations and no output schema, the description must stand alone. It adequately conveys what the tool computes and how to read the result, but it omits output shape and, more importantly, any discrimination from the near-identical health_drug_safety sibling.

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?

There is a single required 'drug' parameter whose schema description already covers it at 100%. The description adds no format guidance (brand vs generic, casing, multi-drug input), so the baseline 3 applies rather than a higher score.

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 (FDA FAERS drug safety signals) and a precise method (proportional reporting ratio and chi-square with Evans criteria), which is far beyond a tautology. However, it never distinguishes itself from the very similarly named sibling health_drug_safety, leaving an agent unable to tell the two apart 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?

There is no statement of when to use this tool versus alternatives such as health_drug_safety, health_drug_label, or health_drug_approvals. The closing caveats ('a statistical prompt for study, not evidence of harm. Not medical advice.') frame interpretation but do not provide routing 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 behavioral burden. It usefully discloses the data source (EIA WPSR), the cadence (weekly), and the derived metrics returned per series (build/draw, YoY, 5-year average). It does not state units, how quickly data appears after the EIA release, or any access/rate constraints, so coverage is 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?

Two dense sentences, front-loaded with the source and scope, with the enumerated series doing real work. The closing disclaimer is short and purposeful for a financial-data tool. 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 parameters and no output schema, the description must convey what comes back, and it does so concretely by listing the five stock categories and the three comparative metrics. It stops short of units, release lag, and temporal coverage, which an agent would still want.

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 is nothing for the description to disambiguate; the baseline of 4 applies. Schema coverage is nominally 100% but vacuous given an empty properties object.

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 the exact resource (U.S. oil inventories from the EIA Weekly Petroleum Status Report) and enumerates the specific series covered: commercial crude, Cushing, SPR, gasoline, distillate. That is far more specific than a bare name restatement, but it never distinguishes itself from nearby siblings such as oil_supply or oil_markets, leaving the agent to infer the boundary.

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-tool guidance. The only usage-adjacent sentence is the disclaimer 'Data, not trading advice,' which frames tone rather than routing. An agent choosing between this and oil_supply, oil_prices, or oil_markets gets no help.

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 does add real context: the data source (Polymarket), the scoring methodology (skill-weighted money versus market odds via x402Pulse), and a scope disclaimer ('Data, not trading advice'). It says nothing about refresh cadence, pagination, geographic coverage, or response shape, so the disclosure is partial rather than complete.

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, with the resource identification front-loaded and the disclaimer kept to a short trailing clause. The parenthetical explaining the 'skilled-trader lean' metric is dense but earns its place by defining a non-obvious term; otherwise there is little waste.

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 single-optional-parameter tool with no output schema and no annotations, the description covers what the data is, where it comes from, and how the skill signal is computed. It stops short of describing the return structure or result volume, which is a modest but real gap given the absence of an output schema.

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% and the single optional 'limit' parameter is self-explanatory ('1 to 10'). The description adds nothing about the parameter, so the baseline 3 applies — the schema does the work 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?

The description states a clear resource — oil prediction markets on Polymarket covering oil prices, OPEC, Strait of Hormuz and fuel — plus the distinguishing payload (skilled-trader lean from x402Pulse). That content-level specificity separates it from siblings like oil_prices, oil_positioning, and oil_supply, though it never names a sibling 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 explicit when-to-use or when-not-to-use statement, nor any named alternative. The closest thing to guidance is the implied framing that this is market-odds data with a trader-skill overlay rather than raw price data, which a careful agent can use to route, but the description leaves that inference to the reader.

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 behavioral burden. It discloses the data's content and hints at weekly cadence via 'weekly change', but says nothing about update lag, source freshness, or that it is a read-only snapshot — and the 'not trading advice' caveat is helpful framing rather than a behavioral trait.

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, then a dense but informative enumeration of returned fields, closed by a short disclaimer. Every clause carries content; the single long sentence is slightly list-heavy but not padded.

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 parameters, the description must (and largely does) enumerate what comes back, covering all the reported categories. It stops short of stating update frequency/lag or units, but is complete enough for an agent to call and interpret a zero-arg data 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 baseline there is no parameter semantics to add beyond the empty schema. Nothing is misdocumented.

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 data resource (WTI crude oil positioning from the CFTC Commitments of Traders) and enumerates exactly what it returns: managed money long/short/net, weekly change, ratio, 3-year percentile, producers, swap dealers, open interest. This clearly separates it from siblings like oil_prices, oil_inventories, and oil_supply 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?

Usage is only implied — the description tells you what data it holds, from which an agent can infer it's for positioning/crowding analysis, but it never says when to choose this over oil_markets, oil_prices, or oil_inventories. The closing line 'Data, not trading advice' is a disclaimer, not usage 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?

No annotations are provided, so the description carries the full load, and it does disclose meaningful traits: official EIA daily spot figures rather than live futures, plus the 'data, not trading advice' limitation. It does not mention update cadence, latency, or authentication needs, but it is clearly a read-only reference endpoint. Useful behavioral context, short of exhaustive.

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 source, then the returned fields, then two short caveats. Every sentence adds information, though the trailing 'Data, not trading advice' is more of a legal disclaimer than selection guidance and could be folded into the futures caveat. Tight for the amount of ground covered.

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 parameters, the description must convey what comes back, and it enumerates every metric (spot prices, four change windows, 52-week range/position, spread) and its provenance. Nothing further is needed for an agent to call this 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 per the baseline there is nothing for the description to disambiguate. The description appropriately spends its words on the returned metrics instead, which is the right use of space for a parameterless endpoint.

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 the exact resource (WTI and Brent daily spot crude oil prices from EIA) and enumerates the derived fields returned: 1-day/1-week/1-month/1-year changes, 52-week range and position, and the Brent-WTI spread. The clause 'Official daily figures, not live futures quotes' cleanly separates it from nearby sibling tools such as oil_markets and oil_positioning. An agent knows precisely what it gets without opening the (empty) 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?

Usage is only implied: the 'not live futures quotes' caveat steers the agent away when it wants intraday/futures data, and the enumerations imply when the tool is appropriate. There is no explicit when-to-use statement, no named alternative among the oil_* siblings, and no stated prerequisites or exclusions. Adequate but leaves routing 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?

With no annotations, the description carries the full behavioral burden. It does disclose the returned data shape (skill score, edge over odds paid, return, specialty), which is useful, but says nothing about auth needs, rate limits, pagination, or freshness of 'recent' trades.

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 tight sentences, front-loaded with what the tool is, then the descriptive payload. The final clause is slightly redundant with the 'skilled... only' framing but otherwise 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 two-param read tool with no output schema, the description covers the core concept and much of the return content. It is adequate, though it could more explicitly guide selection against the closely related 'whales'/'smart_money' siblings.

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 'min' and 'limit' are already documented in the schema. The description adds no parameter-level detail, e.g. allowed ranges or default behavior. 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?

States a specific verb+resource (recent large Polymarket trades by skilled traders) and defines the filter concept (Solid/Sharp skill scores, informed whales vs big gamblers). It clearly conveys what the tool returns, but it never names the adjacent siblings ('whales', 'smart_money', 'top_traders') to distinguish this from generic whale or smart-money tools.

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 'skilled only' and 'separates informed whales from big gamblers' framing implies the use case (filtering out noise trades), but there is no explicit when-to-use, when-not-to-use, or named alternative tool. Usage must be inferred.

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 at all, the description carries the full burden, and it does disclose the substance of the output (holders per side, skill scoring dimensions, lean and agreement). However, it says nothing about read-only/freshness/permission traits or any constraints. It is informative about return content but silent on operational 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?

Two sentences that are front-loaded with the core payload and free of filler. The accepted-input variants are placed after the value proposition, which is the right ordering. The disclaimer tags on cleanly without bloating.

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 single-parameter, read-only analytics tool with no output schema, the description is largely self-sufficient: it explains what gets returned and even the scoring dimensions. The only shortfall is the absence of routing against very similar sibling tools, which an agent would still have to infer.

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 single parameter ('Polymarket market URL, slug or condition ID') is already fully documented. The description's 'Accepts a market link, slug or condition ID' merely restates the schema, adding no syntax or format detail. Baseline 3 is 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 gives a specific resource (Polymarket smart money) and scope ('for one market'), then enumerates exactly what is produced: biggest holders on each side, skill scores (edge, win rate, ROI), and skilled-money lean vs. market odds. The verb is analytical rather than a single action verb, but the output is unambiguous. It does not, however, distinguish itself from overlapping siblings such as skilled_whales, whales, or top_traders.

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, no prerequisites, and no named alternative. Given that skilled_whales, whales, and top_traders are plausible overlapping tools, the agent gets no help deciding among them. The 'data, not investment advice' line frames the tool's nature but does not route usage.

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. It discloses useful traits: the ranking methodology, the available time scopes and categories, and the deliberate framing that it surfaces big-volume losers the profit leaderboard hides. It does not mention auth requirements, rate limits, pagination, or result shape, which are meaningful gaps for a data-retrieval 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?

Two tight sentences with the ranking premise front-loaded, followed by scope and the differentiator. No filler sentences; the value proposition is stated efficiently.

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 read-only retrieval tool with no output schema, the description explains what is returned conceptually (traders ranked by edge, return, consistency across scopes). It leaves the per-trader result shape unspecified, but the ranking semantics are complete enough to call the tool 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 only 33% (only 'limit' is described), so the description must compensate, and it does partially: it explains that period spans day/week/month/all-time and enumerates the category values (sports, politics, crypto, economy). It misses the 'other' category and the 1-25 limit range handling, but overall adds substantial meaning over the raw 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 resource (Polymarket trader leaderboard) and states the exact ranking basis (edge over odds paid, return, consistency) versus raw size, which tells an agent what it gets. It does not, however, differentiate itself from similar-sounding siblings such as skilled_whales or smart_money, leaving that distinction to be inferred.

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 implies when to reach for it by listing period and category scoping ('day, week, month or all time', 'per category'), giving the agent context. But it never states when not to use it or names an alternative sibling for related queries, so usage is only implied rather than guided.

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 behavioral burden. It usefully describes the returned fields, but never states that this is a read-only lookup, nor anything about data freshness, caching, or source cadence, leaving the safety profile to inference.

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 dense sentences, front-loaded with the resource, with zero filler. The level scale, code format, and mode selection all earn their 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 lookup with no output schema, the description adequately covers returned fields and both modes. Minor gap: with zero required parameters it does not state what calling with neither 'country' nor 'minLevel' returns.

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%, so the baseline is 3, but the description adds real meaning: it defines the country-code format with examples (MX, GB, JP) and expands minLevel '1 to 4' into the actual scale (1 Exercise normal precautions to 4 Do not travel). That enriches semantics beyond the schema's bare strings.

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 (U.S. State Department travel advisories) and the exact content returned (level, summary, risk factors), covering both single-country and list modes. It is clearly distinct from siblings like travel_airport_status or travel_exchange_rates.

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 two operating modes (one country via 'country', or all countries at/above a level via 'minLevel') are implied, which helps route usage within the tool. However, it names no alternatives and gives no explicit when-to-use versus other travel_* tools or when-not conditions.

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 and no output schema, the description carries the full disclosure burden and does real work: it states the forecast horizon, the period-based structure, the specific hazard flags (low clouds, storms, snow, strong gusts) and that a delay-risk rating is included. It omits update cadence, data source, units, and any coverage limitations, so it is strong but not exhaustive.

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 a single dense sentence that front-loads the scope (24-30 hours worldwide) before enumerating return contents, and the closing exclusion is well placed. It reads as slightly run-on, but each clause contributes information rather than padding.

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-parameter read tool with no annotations and no output schema, the description conveys enough about the return shape (periods, weather fields, delay-risk rating) for an agent to know what it will get and when it is appropriate. Missing interpretation details such as units or the delay-risk scale are minor given the overall coverage.

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 airport parameter is already documented as accepting IATA or ICAO codes. The description only reinforces this with "any airport worldwide," adding no syntax, format, or validation 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 names a specific verb and resource (airport weather forecast) and scopes it precisely to the next 24-30 hours worldwide, listing the granular fields returned (wind, gusts, visibility, ceiling, flight category, delay-risk). It implicitly separates itself from travel_airport_status (current conditions) by emphasizing the forecast horizon, but never names a sibling explicitly, keeping it 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?

It provides a clear exclusion, "Not for flight planning," which steers the agent away from a plausible misuse. However, it names no alternative tool (e.g., travel_airport_status for current conditions), so the when-to-use guidance is contextual rather than fully routed.

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 disclosure burden and does well: it states the data is live/current, that FAA coverage is limited to U.S. airports while weather is global, and that some restrictions are private-aircraft-only and labeled as such — all behaviorally relevant. It does not cover failure modes such as invalid or non-U.S. airport codes, so it is not exhaustive.

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 the returned content, then coverage scope, then the exclusion. The parenthetical about private-aircraft restrictions is the only dense bit and it carries real information, so nothing is wasted.

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 single-parameter read tool with no annotations and no output schema, the description adequately previews the return payload (delays, ground stops, GDPs, closures, plain-language weather, delay-risk rating). Remaining gaps — error handling for unknown codes, response shape details — are minor for this tool class.

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% and there is only one parameter ('airport', documented as IATA or ICAO code), so the schema already does the work. The description adds no format hints, examples, or edge-case guidance beyond that, 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 names a specific resource and verb-like framing ('Airport status right now') and then enumerates exactly what is returned: live FAA delays, ground stops, ground delay programs, closures, current weather, and a delay-risk rating. The 'right now' framing and 'Not for flight planning' clause separate it from the sibling travel_airport_forecast without needing the 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 a clear negative boundary ('Not for flight planning') and states data scope per source (FAA covers U.S. airports, weather covers worldwide), which tells the agent when the result will be partial. It stops short of naming the alternative sibling (e.g. travel_airport_forecast) for future-looking queries, so routing is implied rather than explicit.

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, and it discloses useful behavior: results are ranked by severity, reasons are plain-language, only current U.S. airspace disruptions are included, and private-aircraft restrictions are segregated. It does not state read-only safety or any rate/auth characteristics, which is a modest remaining gap for a no-annotation 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?

Three tight sentences, front-loaded with the resource and scope, then the categorization caveat, then the exclusion. No filler; every clause adds 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?

For a zero-required-param read tool with no output schema and no annotations, the description covers what is returned (current disruptions ranked by severity with plain-language reasons), the geographic scope, and the interpretive caveat. Nothing essential for correct invocation or interpretation 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 100%, but the single schema description is only 'true or false', so the description's mention that restrictions are 'separated out' is the main clue to what includeRestrictions controls. It still doesn't state the default or the exact effect of true vs false, so it adds only partial meaning over the terse 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 verb+resource+scope: 'Every current FAA disruption in U.S. airspace, ranked by severity,' then enumerates the exact disruption types it covers (ground stops, GDPs, arrival/departure delays, airspace flow programs, closures). This is clearly distinguishable from siblings like travel_airport_status and travel_airport_forecast, which are airport-specific.

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 a clear when-not ('Not for flight planning') and a usage caveat that steers agent behavior (private-aircraft-only restrictions separated out so they aren't reported as closures). It stops short of naming the sibling an agent should use for flight-planning or single-airport queries, so routing is only partially closed.

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 does add real behavioral context by disclosing the scoring basis ('latest 200 finished bets, losses included'), which tells the agent about the sample window and that results are not cherry-picked. However, it omits any auth requirements, error behavior for unknown/invalid wallets, or latency/rate considerations.

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 the core purpose and followed by the concrete return fields. The metric list is somewhat long but each entry earns its place by telling the agent what to expect. No filler or redundancy.

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 correctly compensates by enumerating the returned fields (skill score, edge, win rate, ROI, PnL, specialty, open positions). Combined with the disclosed scoring window, an agent has enough to invoke and interpret the tool, though absent error/auth notes keep it short of a 5.

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 parameter is documented as a 'Polymarket proxy wallet address' with a strict regex pattern. The description adds nothing beyond the schema here ('for any wallet'), so the baseline 3 for high-coverage schemas is 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 gives a specific verb+resource ('Polymarket trader scorecard for any wallet') and enumerates the metrics produced, so the agent knows exactly what it returns. It implies single-wallet analysis via 'any wallet' with a required address, which distinguishes it from leaderboard-style siblings like top_traders or whales, but it never names or explicitly contrasts those 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?

Usage is only implied: the required 'address' param and 'for any wallet' phrase signal that this is the tool for evaluating one specific wallet. There is no explicit when-to-use, when-not-to-use, or routing to siblings like smart_money or skilled_whales, which a caller might reasonably confuse this with.

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 disclose real behavioral detail: the 90-day insider window, open-market vs. pre-planned 10b5-1 distinction, cluster-buy detection, and plain-language decoding of 8-Ks. It still omits data freshness/latency (an expensive multi-source aggregate), permissions, and rate/usage limits, so it is strong but not complete.

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 purpose and the value proposition ('in one call'), then a dense but useful enumeration of returned data. The closing 'Data, not investment advice' is a worthwhile disclaimer; no sentences are wasted, though the single long item list is somewhat heavy.

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 largely does, enumerating every data category an agent would get back. It is complete enough to call correctly, with only freshness/timing and pagination behavior left unspecified.

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?

Only one parameter and schema description coverage is 100%, so the schema already documents the ticker. The description adds the constraint 'Any U.S.-listed ticker', a marginal but real clarification; baseline 3 applies when the schema does the heavy lifting.

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+resource ('Company brief from SEC filings') and enumerates exactly what the brief contains: quarterly/trailing financials, margins and growth, 90-day insider activity with 10b5-1 classification, decoded 8-K events, and new 5%+/activist stakes. It effectively reads as a superset of the sibling wallstreet_financials and wallstreet_insider_trades tools.

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 scopes applicability ('Any U.S.-listed ticker') and the 'in one call' phrasing implies this is an aggregate to prefer over piecemeal calls, but it never explicitly says when to use this versus wallstreet_financials, wallstreet_insider_trades or wallstreet_events. Usage is inferable rather than stated.

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 data source (8-K filings), that events are 'ranked', and that each includes a link, which is meaningful behavioral context. However, it says nothing about return format, ranking methodology, or pagination/limits for the days window.

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 resource and the event taxonomy, followed by a short disclaimer. The event list is long but informative, and there is essentially 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?

The description thoroughly covers what data is returned but, with no output schema and no annotations, it leaves return structure, ranking output shape, and the required ticker parameter undocumented. Adequate for content discovery but incomplete 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?

The description mentions no parameters at all. Schema coverage is only 50% (ticker has no description, days only gives a numeric range), and the description does nothing to compensate by explaining ticker format or the meaning of the days window.

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+resource ('Material corporate events from SEC 8-K filings') and enumerates the exact event types returned. It clearly distinguishes this tool from siblings like wallstreet_financials, wallstreet_insider_trades, and wallstreet_yield_curve without requiring the agent to open any 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?

The content scope implies when the tool is useful (tracking material corporate events), but there is no explicit when-to-use/when-not guidance and no routing to alternatives such as wallstreet_company_brief. Usage must be inferred from the data coverage rather than stated.

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 operational burden. It does disclose rich output behavior (8 quarters/5 years coverage, edge-case handling when companies change reporting labels) and adds a 'data, not investment advice' disclaimer, but it says nothing about auth requirements, rate limits, or error behavior. Useful content disclosure, incomplete operational disclosure.

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 purpose and scope, closing with the disclaimer. No filler or repetition; every clause adds substantive information about coverage or semantics.

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 correctly takes on the burden of describing returns in detail (fields, time coverage, derived metrics, TTM totals) and notes an important edge case. It falls short only on ticker format and data freshness/scope limitations.

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?

Only one parameter (ticker) and schema coverage is 0%, so the schema contributes nothing. The description implies a company identifier is supplied but gives no ticker format or exchange-suffix guidance, leaving the sole parameter under-specified.

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?

Specific verb (retrieves) and resource (standardized company financials from SEC XBRL filings), with an explicit enumeration of returned line items (revenue, net/operating income, diluted EPS, cash flow, balance-sheet items, margins, YoY growth, TTM). The scope is specific enough to separate it from wallstreet_company_brief, wallstreet_events, and wallstreet_insider_trades without opening any 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?

Usage is implied (fetch financials for a ticker), but there is no explicit when-to-use, no named alternative, and no condition distinguishing it from wallstreet_company_brief or wallstreet_yield_curve. An agent can infer the intent but is not routed to the right sibling.

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 disclose meaningful content behavior: the exact fields returned (who traded, buy/sell, shares, price, value, post-trade holdings) and the 10b5-1 pre-plan flag plus cluster-buy detection. However, it says nothing about auth requirements, data freshness/latency, rate limits, or pagination behavior, leaving operational traits uncovered.

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 purpose is front-loaded before a compact field enumeration, and the whole definition is two sentences with no filler. The middle list of returned fields is long but each item is informative rather than 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?

With no output schema, the description must explain return values and it does so thoroughly, listing who/how-much/price/value/holdings/plan-status plus totals and cluster detection. It is nearly complete for the tool's data contract, though it omits usage routing and parameter meaning.

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 75%, and the description adds no parameter information at all. The 'days', 'limit', and 'openMarketOnly' meanings live only in the schema, and 'ticker' is undocumented in both places, so the description does not compensate for the gap. Baseline 3 is appropriate given the schema does most of the lifting.

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 and resource ('Insider trades decoded from SEC Form 4 filings') and enumerates exactly what data is returned, making the tool's scope easy to grasp. It does not explicitly differentiate itself from siblings like smart_money or whales, which also concern institutional/positioning data, 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, no alternatives named, and no prerequisites. The only guidance is the trailing disclaimer 'Data, not investment advice,' which does not help an agent decide when this tool is the right choice over the many sibling market-data 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?

With no annotations, the description carries the full burden. It does disclose the payload shape and freshness cadence ('latest daily', 'vs. the previous day, a month and a year ago'), which is useful, plus a disclaimer ('Data, not investment advice'). But it says nothing about auth, rate limits, caching, latency, or whether the underlying feed can be delayed — gaps for a zero-annotation 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 dense sentence that front-loads the resource and then layers detail from most to least important — yields, spreads, inversion flags, then changes. No filler; every clause names a distinct data element. The closing disclaimer is short and earns its place for a financial 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 and no input schema, the description must specify return contents, and it largely does: instruments, spreads, inversion flags, and comparison periods. The remaining shortfall is operational (auth, source, delay) and the comparison baseline for 'changes' is stated but not the format of the flags.

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 no parameters, so the baseline is 4 and there is nothing for the description to compensate for. The enumeration of included metrics arguably documents the (empty) selection surface, confirming no filtering options exist.

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 (U.S. Treasury yield curve) with a crisp enumeration of what it contains: daily yields 1M-30Y, 10Y-2Y and 10Y-3M spreads, inversion flags, and period-over-period changes. It is clearly distinct from the other wallstreet_* siblings (company_brief, events, financials, insider_trades), though it never explicitly diffs against 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?

No explicit when-to-use or when-not-to-use statement, and no alternatives are named. Usage is only implied by the content — an agent infers 'call this when you need current Treasury curve data or a recession-signal read.' The parenthetical that inversion is 'a closely watched recession signal' hints at intent but does not constitute routing 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. It does disclose a genuine behavioral trait not in the schema: 5- and 15-minute crypto markets are filtered out, plus the return fields (trader name, outcome, price, USD size). It omits read-only nature, auth needs, rate limits, and pagination 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?

Two compact sentences that front-load the core scope, then the filtering rule, then the sibling pairing. Every clause contributes; sizing is appropriate for the tool's simplicity.

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 the return fields and noting the crypto-market exclusion. For a two-optional-parameter read tool this is nearly sufficient, though the absence of any read-only/safety statement is a minor gap given the lack of annotations.

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 (min as USD size, limit as 1–50). The description only echoes 'above a size you choose' and adds no format, default, or range 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 specific verb and resource: 'the largest recent buys and sells across all markets above a size you choose,' with the returned fields named. It clearly identifies the tool as a whale-trade feed, but it does not differentiate itself from closely named siblings like skilled_whales, smart_money, or top_traders, leaving an agent to infer the distinction.

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 offers a usage hint by recommending pairing with /v1/wallet to assess a whale, and implies the size threshold is user-chosen. However, there is no explicit when-to-use versus siblings (e.g., whales vs skilled_whales), and no stated exclusions beyond the crypto-market filter, so guidance is only implied.

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