Helious market intelligence

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

Annotations already cover read-only/idempotent/non-destructive, and the description adds genuinely new context beyond them: the call 'Draws no credit', so agents know it is free to invoke defensively. It does not disclose auth requirements or whether entitlement data can be stale, which keeps it below 5.

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 tight sentence that front-loads the payload (account entitlements) and ends with the cost-free assurance. The 'steps to relay to your user...' clause is a bit recursive and slightly obscures what the tool returns versus what the agent should say.

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 the return contents, and it does list them (readable scope, cost, remaining quota, upgrade path). It stops short of describing the response shape or how quota periods are defined, a minor gap for a simple info 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 there is nothing for the description to disambiguate and the baseline of 4 applies. The description correctly spends no words on arguments.

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

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

Names a specific resource (the connected account's access/plan state) and enumerates its contents: readable scope, per-call cost, remaining monthly quota, and upgrade steps. It is clearly distinguishable from every sibling, which are all market-data lookups. Slightly muddled phrasing ('what a call costs and what is left this month') keeps it just short of a crisp verb+resource statement.

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 mention of 'the steps to relay to your user when a result needs more than the account allows' hints at calling this after hitting a limit, but there is no explicit 'call this before/after X' or exclusion guidance. An agent must infer the trigger condition.

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 read-only, idempotent and non-destructive, so the safety bar is low. The description still adds real domain behavior: results are 'measured at the close', it explains what the tail means for interpretation, and it discloses the buyer categories and verdict fields, none of which appear in annotations. The per-call freshness/credit model is only carried by the schema.

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

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

Front-loads the resource and the metric list, then the tenor guidance, which is a sensible order. The closing line about the tail is interpretive rather than instructional, but it is a single short sentence that earns its place as a hint about which number matters.

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, and the description compensates by enumerating what a result contains (yield, tail, bid-to-cover, buyer breakdown, verdict). Combined with the rich parameter schema, an agent has enough to call it correctly; only the live-vs-delayed data behavior is left entirely to the 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%, with the tenor parameter already documenting plain forms, classes, and curve segments in detail. The description restates the tenor idea and gives one example without adding format or syntax 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?

Names the specific resource (US Treasury auction results) and enumerates the exact metrics returned: high yield, tail vs when-issued, bid-to-cover vs 12-auction average, buyer split, and the desk verdict. It does not explicitly distinguish itself from the closest sibling get_treasury_issuance, but the 'results at the close' framing makes the domain unmistakable.

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?

Offers a useful mapping from a natural user question ('how did the last 10-year auction go') to the tenor parameter, which is genuine usage guidance. However, there is no statement of when to use this tool versus alternatives or prerequisites/exclusions, so it stops short of explicit 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 cover the safety profile (readOnly, idempotent, non-destructive, openWorld), so the description only needs added context. It does add real substance: the plan includes ordered tool calls, per-tool returns, credit cost priced at the caller's cadence, and plan coverage. It doesn't mention whether the plan is cached or how cost is estimated, but the output content is well disclosed for a tool with no output schema.

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, front-loaded with the deliverable and followed by the usage trigger. Every clause (ordered tools, returns, credit cost, plan coverage) earns its place, though the opening phrase "What to build with Helious and how" is slightly awkward and the sentence is long.

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

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

All four parameters are optional and there is no output schema, so the description must explain what comes back, which it does by enumerating the plan's contents. Combined with the rich schema descriptions, an agent has enough to invoke it correctly; only caching/estimation details are 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 description coverage is 100%, so the schema already explains each parameter, including the non-obvious empty-value behaviors for goal and cadence. The description adds no parameter-level meaning beyond that, so 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 and deliverable: for a stated goal it returns the tools to call in order, what each returns, credit cost at your cadence, and plan coverage. This clearly separates it from the data-fetch siblings, and 'before the first data call' positions it as the planning step ahead of 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?

Explicit when-to-use: "Use this when someone is building an integration, a bot, a dashboard or a strategy, before the first data call." That gives both the trigger and the sequencing relative to data calls. It stops short of naming an alternative or a when-not condition, but for a unique meta-tool that gap is small.

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 read-only, idempotent, open-world behavior. The description adds the account-scoping caveat ('numbers follow the connected account'), which is genuinely non-obvious, but it does not mention credit costs, latency/freshness trade-offs, or the 1-hour delay that the schema's 'fresh' parameter reveals.

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 resource definition and no filler. The trailing 'Market data: numbers follow the connected account' is slightly cryptic but is the only account context given, so it 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 read-only tool with zero required parameters, full schema coverage, and no output schema, the description gives enough to call it correctly: what data, what time range, and that values are account-scoped. It is only thin on describing the shape of returned readings versus historical rows.

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 all three parameters (fresh, limit, since) are already documented in the schema, including the credit cost and delay details. The description adds nothing about parameters, 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 (cross-asset correlation matrix) with the exact asset set enumerated (stocks, bonds, dollar, gold, oil) and the data window (30-120 days). This clearly separates it from siblings like get_fx_board or get_vol_board that cover a single asset group.

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?

'Newest reading plus past boards' implies both a current-snapshot and historical use, but there is no explicit when-to-use or when-not-to-use guidance relative to alternatives. No prerequisites or plan caveats are stated in the description 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?

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so safety is covered. The description adds the record composition of a flip, but says nothing about pagination, default limits, or the one-hour-delayed live-view behavior that the schema flags as costing 5 credits.

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 that names the resource and immediately lists the payload fields. No filler, no restatement of the title.

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

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

With no output schema, the description does the necessary work of describing what a returned row contains. It is only slightly short of complete: bounds on history depth and result size are left entirely to the 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 parameter docs are unusually rich, including the credit cost and latency trade-off for 'fresh'. The description contributes nothing beyond the schema, which is acceptable given the coverage but earns only the baseline.

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

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

States a specific verb+resource ('past curve regime changes: every flip') and enumerates the returned fields (time, prior regime, session close). This clearly distinguishes it from current-state siblings like get_rates_and_curve and get_treasury_curve, though it never names those siblings 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?

Usage is implied by 'past' and 'how the session closed' — an agent can infer this is a historical event log — but there is no explicit when-to-use, no exclusion criteria, and no named alternative among the many curve-related siblings.

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 establish that this is a read-only, idempotent, non-destructive open-world call. The description adds substantial behavior beyond annotations: digest fields, source-verified quotes, the deliberate absence of market direction in minutes, and the 60-minute delayed account 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 front-loaded with the core purpose and remains reasonably compact for the tool's complexity. A few phrases, such as repeated emphasis on full documents versus headlines, could be tightened, but the content largely earns its place.

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

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

With no output schema, the description usefully summarizes what each digest contains and notes the delayed-news behavior. It does not fully describe output shape or pagination, but the schema covers the parameters and the remaining gaps are minor.

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 kind, fresh, and limit are already documented in the input schema. The description does not add parameter-specific syntax or defaults beyond the schema, so the baseline score of 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 states a specific verb and resource: it returns the desk's read of full FOMC minutes and Fed/ECB speeches, not headlines. It also enumerates the digest contents, so an agent can distinguish this from market-data siblings without opening 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 implies when to use the tool by contrasting full-document digests with headlines, and it explains why minutes omit bond or equity direction. However, it does not explicitly name alternatives such as get_feed or state when not to use this tool, leaving routing guidance partly 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?

Annotations already declare readOnly/idempotent/non-destructive/openWorld, so the safety profile is covered. The description goes beyond that by disclosing output semantics an agent could not infer: confirmed-vs-estimate status, BMO/AMC timing, and consensus-vs-actual EPS with beat/miss — genuinely useful for deciding when to call it. It does not mention the paid 'fresh' path described in the schema, which is the one behavioral gap.

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

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

Two sentences, zero filler, front-loaded with the returned fields and finished with an explicit scope statement. Every clause carries information the agent needs.

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

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

With no output schema, the description does the heavy lifting by enumerating return fields, which is the main completeness requirement here. All three parameters are schema-documented and the tool is read-only, so remaining gaps (default behavior when symbol is omitted, limit/paging) are minor and covered by the schema itself.

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 all three parameters are already documented, and the description only restates the symbol parameter's format ('AAPL'). It adds no guidance on limit or on the fresh/credit trade-off beyond what the schema says, 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 (US mega-cap earnings) and enumerates exactly what is returned: report date, confirmed vs estimate, before-open/after-close, consensus EPS, and reported EPS with beat/miss. The closing sentence ('This is the tool for any question about a company's earnings date or EPS') pins the scope unambiguously, and no sibling covers earnings, so there is nothing to confuse it with.

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 positive usage rule — 'Pass symbol for one name, like AAPL' — and implies the unfiltered case by describing the tool as covering companies generally. It stops short of naming when NOT to use it or pointing at an alternative (e.g. a broader market-context sibling), so it is clear context without exclusions.

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

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

Annotations already cover the safety profile (readOnly, idempotent, openWorld, non-destructive), and the description adds substantive operational context: plan-dependent history windows (12 months Starter, 24 Pro, 10 years Ultimate), an hour of latency for non-live accounts, and a 5-credit cost for the `fresh` live view.

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

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

Front-loads what the tool returns, then defaults, then the alternate mode, then plan limits. Dense but each clause carries information; the pricing/latency sentence for `fresh` is slightly buried mid-description.

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 7-parameter, no-output-schema tool it explains both return shapes (aggregate calendar rows and per-release consensus records), caps, and plan constraints. Ordering of calendar-mode results and whether results are paginated beyond `limit` are not stated.

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 cross-parameter meaning: `event` converts the call into a per-release consensus history where `since` sets the floor and `limit` caps rows at 520, and `country` filters the calendar mode. This goes beyond the per-parameter schema text.

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 resource (economic releases with forecasts, prior and actual) and names the extra content types included (Fed speakers, auction times). It also describes a second mode selected by the `event` parameter. It does not explicitly distinguish itself from siblings like get_auctions or get_fed_roster, whose data it partly overlaps.

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?

Explains the default window (yesterday through 7 days) and how to widen it via days_back/days_ahead, how to narrow to a country, and when to switch to the `event` mode to read a single release's consensus record instead. No guidance about when to prefer sibling tools for auctions or Fed speakers.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and non-destructive, so the safety profile is fully covered structurally. The description adds content scope but says nothing about whether results are cached, how the hour-behind live lag applies, or how speeches are bounded in time — context the one parameter hints is relevant.

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

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

One sentence, front-loaded with the resource, and every clause enumerates a distinct piece of returned content. No filler or repetition of schema material.

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 usefully doubles as a return-value preview by listing the roster fields. The remaining gap is the freshness/lag model, which affects whether the agent should spend credits on `fresh`, but for a zero-required-parameter read tool this is largely adequate.

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 `fresh` parameter is documented at length in the schema (credit cost, lag behavior, no-key no-effect). The description contributes nothing about it, so the baseline 3 applies.

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

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

Names the resource (FOMC roster) and enumerates the content returned: governors and presidents, who votes this year, lean, and upcoming speeches. That is specific enough to distinguish it from macro-data siblings like get_rate_odds or get_economic_calendar, though it never pairs the resource with an explicit retrieval verb.

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 by the content list — an agent can infer 'call this when you need FOMC membership'. There is no statement of when to prefer it over adjacent tools (get_economic_calendar for speech timing, get_rate_odds for policy expectations) and no prerequisites 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?

Annotations already cover read-only/idempotent/non-destructive, and the description goes far beyond them: it discloses the one-hour news delay and the 5-credit fresh override, retention windows per content type, depth tied to the connected account, outlet-name stripping, and the stable id/thread_id behavior. That is unusually rich behavioral context with no contradiction.

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 and most sentences carry useful detail, but the whole definition is a single dense paragraph. The outlet-anonymization rule is stated twice (once as 'No headline names its outlet, author or link' and again at length at the end), which is avoidable repetition.

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 7-parameter, zero-required feed tool with no output schema, the description is complete: it covers what is returned, the two score channels, per-plan depth, retention, filter behavior, delay/fresh economics, and source anonymization. An agent has enough to call it correctly.

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

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

Schema coverage is 100%, so baseline is 3. The description earns above baseline by explaining the topic-versus-category distinction with a concrete example (a stock story off the wire has category news and topic equities), and by noting that filters search the whole window and matched counts every match.

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

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

The description states a specific resource (the combined Helious feed) and enumerates what it contains: posts (releases, auction results, board updates, brief, squawk) and headlines. An agent can tell this is the general feed rather than a specialized endpoint, but it never names or routes against siblings like get_auctions or get_squawk_sessions.

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 strongly implied by the content description and the filter semantics (q, categories, kind, topics, since), and the fresh/delay tradeoff is explained. However, there is no explicit when-to-use guidance versus the many specialized sibling tools, and no exclusions or alternatives are named.

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 readOnly, idempotent and openWorld, so safety is covered. The description adds a genuinely useful trait beyond them — that values are account-dependent ('numbers follow the connected account') — but says nothing about plan-based history depth, pagination, or latency, which the schema only partly hints at.

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 core scope front-loaded and no filler. The second sentence is slightly clipped but still earns its place by naming the data provenance.

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 does sketch the return shape ('newest reading plus past boards', seven currencies) and the account linkage. It still leaves the score's scale/sign convention unstated, which is a minor but real gap for interpreting results.

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 `fresh`, `limit` and `since` are fully documented in the schema, including the credit cost and plan limits. The description adds no parameter syntax or format detail beyond that, 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 (FX momentum scorecard), its scope (seven major currencies scored against the basket) and its coverage (newest reading plus past boards). This clearly separates it from siblings like get_vol_board or get_rates_and_curve, though it doesn't name them explicitly.

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

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

There is no when-to-use guidance and no mention of alternatives among the many sibling board/history tools. The only usage cue, the `fresh` live-view option, lives in the schema rather than the description, so an agent gets no routing advice here.

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 readOnly, idempotent, openWorld, and non-destructive, so safety is covered. The description usefully adds provenance (Helious, live ship tracking) and the tanker/cargo split. It omits material behavioral facts an agent would care about, notably that the default view can lag roughly an hour behind and that a paid live view exists — though that detail lives in the `fresh` parameter description rather than here.

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 with zero filler: subject (ships), scope (per day), dimension (tanker/cargo), and source (Helious). Nothing to trim.

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 bears responsibility for describing the return shape; it gives dimensionality (per day, split by vessel type) but not format, units, or default lookback when `days` is absent. Combined with the undisclosed default latency, an agent has gaps before calling.

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 `days` and `fresh` are already documented in structured data; baseline 3 applies. The description adds nothing about parameter semantics — no default range, no units — beyond clarifying what 'ships' means for interpretation of results.

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: daily ship transits through the Strait of Hormuz, broken down by tanker vs. cargo, with a named data source. An agent can tell exactly what data comes back. It doesn't name a sibling, but no sibling overlaps this domain, so differentiation is inherent rather than stated.

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 never says when to use this tool, what the default time window is when `days` is omitted, or how it relates to any alternative. Usage must be inferred entirely from the name and schema.

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 cover read-only/idempotent/open-world, and the description adds genuinely new behavioural facts: every measure comes with YoY plus 1/3/6-month annualised, and the response says which basket components drive the headline. It also notes the data is published statistics available on every tier, which is real context beyond the annotations. It stops short of describing size limits, freshness lag, or cost implications of `fresh` beyond what the schema says.

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 scope, and the second and third sentences carry substantive payload about the return shape. The phrasing is dense and slightly long-winded, but nearly every clause earns its place; no filler sentences.

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 steps in usefully by explaining the return shape (YoY plus 1/3/6-month annualised, plus headline drivers), which is exactly the gap an output schema would otherwise fill. It does not cover how `window` interacts with `history`, series length limits, or what the response looks like when `measures` is omitted, so it is 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 coverage is 100%, so all four parameters are already documented in the schema. The description restates `measures` as a key filter and `history` as adding the monthly series, which is confirmatory rather than additive. `window` and `fresh` (including the 5-credit cost) are 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?

The first sentence names the specific resource (US inflation measures) and enumerates the families covered — headline/core CPI and PCE, supercore, trimmed means, median, sticky/flexible, components. That enumeration clearly separates it from siblings such as get_jobs, get_economic_calendar, or get_rates_and_curve without the agent 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 rather than stated: it is the tool for US inflation readings, and the description notes `measures` filters by key while `history` adds the monthly series. It does not say when to prefer this over e.g. get_series for a single CPI series, nor any exclusions, so the agent has 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?

With readOnlyHint/idempotentHint already covering the safety profile, the description adds substantive context: all values are in THOUSANDS, sector detail sums exactly to the headline, percentage-type figures live under `standing` rather than the measure axis, and the data is tier-agnostic published statistics. That is real payload semantics an agent could not infer from the annotations.

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?

Scope is front-loaded in the opening clause, then return format, then filtering behaviour — a sensible order with no filler. The first sentence is a long enumeration, but each item adds discriminating detail 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?

There is no output schema, so the description must carry return semantics, and it largely does: measure axes, month-over-month change plus 3/6/12-month windows, thousands as the unit, and where percentages land. It could say more about how sector attribution is keyed in the response, but nothing essential for correct invocation 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%, so both `measures` and `history` are already documented in the schema, and the description mostly restates them ('measures filters by key, history adds the monthly series'). `window` and `fresh` are left entirely to their schema descriptions. Baseline 3 is appropriate when the schema carries the parameter burden.

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 concrete resource scope — every US employment measure (nonfarm payrolls split private/government, ten private sectors, claims, JOLTS) — and states the return shape (monthly change plus 3/6/12-month windows in thousands). An agent can immediately tell this apart from siblings like get_inflation, get_earnings or get_economic_calendar.

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 domain boundary is explicit enough to route correctly: it covers US employment/claims/JOLTS only, and 'Published statistics, so it answers on every tier' tells the agent there are no entitlement preconditions for the base data. It stops short of naming a sibling alternative or a when-not-to-use condition, so it is clear context without exclusions.

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

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

Annotations already declare readOnly/idempotent/openWorld, so the description rightly spends its words elsewhere: it discloses that the payload includes scored economic releases plus a desk-authored causal read (event/flow/quiet) and the trading regime, which is material context an agent could not infer. It stops short of noting latency, pagination or failure behavior for the composite call, but the per-account lag is covered by the fresh parameter schema.

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 routing instruction, then the payload inventory, then the sequencing advice — a sensible order with little filler. It runs slightly long in enumerating every asset class, but each clause maps to a real capability.

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 carries the return-value burden and does so by enumerating the cross-asset board, the scored releases, the desk's causal read and the regime. An agent knows what comes back and roughly how to interpret it; only output shape/formatting details are left implicit.

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

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

With a single parameter at 100% schema coverage, the schema already fully documents 'fresh' including the 5-credit live view and free-where-already-live case. The description only adds 'Market data: numbers follow the connected account', which is light supplementary context rather than genuine meaning 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?

States a specific verb and scope ('one call gives the whole cross-asset board... equities, the Treasury curve, FX, volatility, commodities') and names the exact question it answers ('why is the market doing this'). It is unmistakably distinct from the granular siblings like get_fx_board, get_vol_board and get_treasury_curve.

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

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

Explicitly instructs 'Use this before the individual board tools: it saves five calls', giving both ordering and rationale against named alternatives. The 'START HERE' framing tells the agent exactly when this tool is the entry point versus a follow-up.

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

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

The annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so safety is covered. The description contributes one useful behavioral fact: the numbers are market data and follow the connected account, implying account-dependent freshness. It says nothing about the board's ordering mechanics beyond 'best to worst', pagination behavior, or how `fresh`/credit consumption interacts with results, leaving the schema to explain the tiering.

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 resource and its returned fields, then the alternate symbol mode. Every clause is relevant, though the phrase 'its price, its move on the session and where it ranks' partially restates the first sentence's field list.

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 board with no output schema and fully documented parameters, the definition covers both invocation modes and the field set an agent can expect. The remaining gaps (limit behavior, board ordering details, credit cost of `fresh`) are covered in the schema, so the description is essentially complete 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 100%, so all three parameters are already documented, including ticker syntax and the empty-string case. The description adds only the single-symbol framing and visibly does not address `fresh` or `limit`. Its wording 'ONE company' also slightly narrows the schema's 'one or more ... comma separated' without contradicting it.

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

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

Names a specific resource (the NASDAQ-100 board), a specific operation (ranked best to worst on the session) and enumerates returned fields: price, change, sector. It also names the second mode, a single-company lookup. The resource name alone distinguishes it from siblings such as get_fx_board and get_vol_board, though it never explicitly contrasts 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?

Explicit conditional guidance: omit the symbol for the full ranked board, or 'Pass symbol to ask about ONE company instead, like AAPL or NVDA'. The Ramp shows concrete examples of the argument form. No guidance is given about when a different tool or different tier is warranted, 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?

Annotations already declare readOnly/idempotent/openWorld, so the safety profile is covered; the description adds genuinely non-obvious methodology: computed from settlement prices against the effective fed funds rate rather than the target midpoint. That distinction materially affects how an agent interprets the numbers. It doesn't mention rate limits or refresh cadence beyond the 'fresh' param note.

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

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

Front-loaded with what the tool returns, followed by the intent-matching phrases, then the methodology caveat. The example list is slightly repetitive but earns its place for routing. No filler sentences.

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, and the description compensates by enumerating the return content: probability per meeting, implied effective rate after each one, and total move priced across the path. Combined with the documented single optional parameter, an agent has enough to call it and interpret results.

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 'fresh' parameter is fully documented in-schema, including the 5-credit cost and no-op without a key. The description adds nothing about parameters beyond a passing reference to pricing, so 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 (Fed cut/hike odds per remaining FOMC meeting) with the underlying method (fed funds futures), which is more precise than the title alone. It does not explicitly distinguish itself from close siblings like get_rate_path or get_rates_and_curve, which are likely the nearest competing concepts.

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?

Offers concrete trigger phrasings ('what are the odds of a cut in September', 'is the Fed cutting', 'what is priced in for the next meeting'), so an agent can pattern-match user intent confidently. It stops short of naming when a sibling should be preferred instead.

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

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

Annotations already declare safety (readOnly, idempotent, non-destructive), so the description adds valuable domain context: rates are traded prices not forecasts, the time-gap comparison reflects market changes not different instruments, and the two lanes are not directly comparable. It omits cost/auth details, which the schema covers.

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 dense but front-loaded with the core purpose, then moves into necessary caveats. Every sentence carries useful information, though some phrasing (e.g., the lane comparison warning) is lengthy; it remains appropriate for the tool's complexity.

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 explains the return contents (implied rates now plus six and twelve months ago) and warns about non-comparability. It leaves the exact response shape and the effect of the `history` parameter implicit, but covers the essential domain semantics an agent needs.

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 baseline is 3, but the description adds substantial meaning to the `lane` parameter by explaining `sr3` (sixteen quarterly 3-month SOFR futures grouped into whites/reds/greens/blues) and `ff` (forty-eight monthly 30-day fed funds contracts). It does not elaborate on `fresh` or `history`, but the schema documents those sufficiently.

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

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

The description states a specific resource and scope: 'What the market is paying for US interest rates up to four years out,' with two named strips (`sr3`, `ff`). It is clear what the tool returns, though it does not explicitly differentiate itself from siblings like `get_rates_and_curve` or `get_treasury_curve`.

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 important interpretation guidance ('Do not compare the two lanes contract by contract') but does not say when to use this tool versus alternatives such as `get_rates_and_curve` or `get_curve_history`. The agent must infer selection from the resource description 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?

The annotations already establish that this is a safe, idempotent, open-world read. The description then adds genuinely new behavior: whether the yields are live or an hour stale depends on the account, and accounts without a key get a note rather than numbers. That latency and auth context is not available anywhere in the structured fields. It doesn't cover rate limits or the 5-credit cost of the fresh flag, which only the schema mentions.

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 no filler, and the payload of report contents is front-loaded. The trailing clause 'a note instead of numbers without one' is a slightly opaque way of saying the response degrades to a message when unauthenticated.

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 has to describe what comes back and it does: yields, spreads, regime classification, and the time of the flip. The important remaining gap is how it differs from a sibling such as get_treasury_curve, which the description leaves unaddressed.

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 optional 'fresh' parameter is fully documented in the schema, including its cost and its no-effect-without-a-key caveat. The description's reference to 'current or an hour behind according to the connected account' explains why freshness is account-dependent, but it adds no syntax or format detail beyond what the schema provides.

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

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

Names the concrete resource and contents: Treasury yields, 2s10s and other spreads, and curve regime with the flip time. That is far more specific than the sibling get_curve_history or get_yield_closes names alone. However, it never distinguishes itself from get_treasury_curve, which sounds like it returns much the same thing, so an agent has no basis for choosing 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?

There is no statement of when to use this tool rather than get_treasury_curve, get_yield_closes, get_curve_history, or get_rate_path, and no exclusions or prerequisites are given. Usage has to be inferred entirely from the tool name.

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 read-only, idempotent, open-world and non-destructive behavior, so the safety burden is largely covered. The description adds genuinely useful scope information: the consensus_history block is bounded by 'the plan's history window' and contains consensus, first actual, previous and revised prior at each print. It says nothing about latency or credit cost, which live only in the schema.

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 payload is front-loaded: the primary content list comes first, and the secondary consensus_history explanation follows. Two sentences, no filler. The second sentence is dense and slightly run-on ('the consensus, first actual, previous and revised prior at each print'), which keeps it just short of a 5.

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 has to carry the return-value burden, and it does: it names the five data components and explains the consensus_history structure. For a two-parameter read tool this is close to sufficient, though history depth and value formatting remain 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?

Schema description coverage is 100%, and both parameters (slug, fresh) carry detailed schema text including the slug source (list_series) and the fresh/credits tradeoff. The description adds no parameter-level meaning beyond that, so the baseline of 3 applies even though nothing is missing.

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 resource (one economic data series) and enumerates exactly what comes back: latest print, forecast, surprise in standard deviations, history, and a consensus record. That is far more specific than the title alone. It does not explicitly contrast itself with list_series or get_economic_calendar, so sibling differentiation is only implied by 'One ... series'.

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 guidance. The singular 'one series' hints that this is a single-item lookup versus a listing endpoint, but the agent must infer that from the phrasing rather than being told. No alternatives or prerequisites are named.

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 readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds only the one-week retention window and one-entry-per-event shape. It does not disclose the credit-charging live-view path or the one-hour lag that the schema hints at, which is exactly the kind of behavioral detail worth surfacing here.

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 tight sentence with the resource and scope front-loaded and no filler. It is efficient, though the brevity contributes to the missing usage and parameter context.

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 and both parameters are optional, so the description needn't explain return values in depth; annotations plus the 100%-covered schema carry safety and parameter detail. The remaining gap is that an agent gets no sense of what an entry contains or how the default week-long window relates to `hours`.

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

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

Schema description coverage is 100%, so the baseline is 3. The phrase "last week" usefully corroborates the default window implied by the `hours` parameter (up to 168), but the description says nothing about `fresh`, the credits cost, or key requirements — all of which live only in 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 resource (live events transcribed by Helious) with concrete examples (Fed pressers, briefings) and states the return granularity (one entry per event). It is clearly not the same as rate-curve or calendar siblings. It stops short of explicitly distinguishing itself from get_feed, which could plausibly overlap.

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

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

"In the last week" implies a recency scope, but there is no explicit when-to-use, no when-not, and no named alternative among the 24 siblings. An agent must infer that this is for recent transcribed audio/video events rather than market data feeds.

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 cover safety (readOnly, idempotent, non-destructive, openWorld), so the description's value-add is the data-currency contract: prices reflect the account's tier, an hour delay otherwise, and a note instead of numbers with no key. That degraded-mode behavior is exactly the kind of thing an agent cannot infer from annotations. It doesn't mention pagination or point count, but for a fixed-length curve that's minor.

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 what the tool returns and its span, then the data-currency caveat. Nothing is padding, though the trailing 'and a note instead of numbers without one' is syntactically compressed enough to require a second 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-required-param read tool with full schema coverage and no output schema, the description gives the resource, its span, granularity, and freshness behavior — enough to call it correctly. What's absent is return shape detail (number of tenors, missing-data representation), a modest gap given no output schema exists.

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 `fresh` parameter's description already spells out the live view, 5-credit cost, free-where-already-live case, and no-op without a key. The description only restates the freshness/account-tier context at a higher level, adding framing but no semantics beyond the schema; 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 ('the whole US Treasury curve in one call') and bounds the scope concretely to 3M bill through 30Y bond with daily closes, which separates it from series-oriented siblings like get_series and get_yield_closes. It does not explicitly name or contrast with get_curve_history or get_rates_and_curve, which is why it stops short of 5.

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

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

Usage is implied by 'in one call' — the agent can infer this is the bulk/whole-curve option rather than a per-series call — but no when-to-use or when-not guidance is given. With three plausible siblings (get_curve_history, get_rates_and_curve, get_yield_closes) the missing routing rule is 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?

Annotations already cover readOnly, idempotent and openWorld, so the bar is lower, but the description adds genuinely useful behavior: figures are in billions of dollars, the data is published statistics available on every tier, and history depth varies by plan. It omits latency/lag behavior and return shape, which are only partly covered by the 'fresh' schema field.

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?

Dense and front-loaded, with the content inventory first and operational notes trailing. It is a single sprawling sentence with several parentheticals, which costs a little readability but wastes no words.

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 it does so by listing the data blocks returned (gross/net, bills/notes/bonds, cash balance, quarterly rollup, refunding schedule) plus units and tier availability. Minor gaps remain around response structure and how measures keys map to blocks.

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. The description restates what the schema already says ('measures filters by key, history adds the monthly series') and adds only the unit context (billions) rather than new parameter semantics such as valid measure key families beyond the schema example.

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 concrete resource (monthly US Treasury borrowing) and enumerates its components: marketable debt gross/net split into bills, notes and bonds, the Treasury's cash balance at the Fed, a quarterly rollup, and the refunding schedule. That enumeration distinguishes it in content from yield-oriented siblings like get_treasury_curve, though no sibling is named 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?

Usage is only implied: 'measures filters by key, history adds the monthly series' explains how to narrow output, and the tier note says it always answers, but nothing says when to pick this over get_treasury_curve, get_auctions, or get_rates_and_curve. An agent must infer the boundary from the content list alone.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, so the safety profile is covered. The description adds one useful non-obvious fact — 'numbers follow the connected account' — indicating results are account-scoped, but it says nothing about the freshness/lag behavior that the schema's 'fresh' parameter reveals (the hour-behind default), nor about return shape.

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, zero padding, with the subject ('Implied volatility board') front-loaded and the contents enumerated second. Nothing repeated from the title or annotations.

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 does sketch the payload (gauge list, percentile, latest plus history), which is what an agent needs to judge relevance. Missing only minor return details such as row/field shape and default limits, which the absence of an output schema leaves 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?

Schema description coverage is 100%, so all three parameters are already documented in the schema, including the credit cost and lag for 'fresh' and the plan-dependent depth for 'since'. The description's 'Newest reading plus past boards' lightly frames the paging model but adds no syntax or defaults beyond the schema, so baseline 3 applies.

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

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

Names a specific resource ('implied volatility board') and enumerates its contents (VIX and other vol gauges, one-year percentile, newest reading plus past boards). The topic specificity cleanly separates it from topic-specific siblings like get_fx_board, get_rates_and_curve, and get_market_context 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?

There is no statement of when to use this board versus get_series, get_market_context, or the other board tools, and no prerequisites. The only usage-adjacent hint is 'Newest reading plus past boards,' which implies the since/limit window but never says so explicitly.

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 readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds genuinely new context beyond that: the ledger start boundary, the 'official' historical record fallback, and that availability is gated by the connected account — useful for an agent deciding whether a call will succeed.

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, purpose front-loaded, no filler. The middle sentence ("when since or before asks for them") is awkwardly worded and slightly obscures the fallback rule, costing a point.

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 should carry return semantics; it conveys that results are session-based closes plus a historical daily series, which is the essential shape. Pagination depth and row format remain unstated, but for a 4-parameter read tool with full schema coverage and strong annotations this is largely 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 coverage is 100%, so the baseline is 3 and the schema already documents fresh, limit, since and before including credit cost. The description adds some meaning by tying since/before to the historical 'official' record, but it does not explain paging interaction between limit and before.

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: official 17:00 New York Treasury yield closes per session, with a clear historical fallback to official daily yields back to 2000. It is distinguishable from curve siblings by the fixed 17:00 session framing, but it never names get_treasury_curve or get_curve_history to make the boundary explicit.

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?

"when since or before asks for them" implies a usage condition for the historical record, and "Availability follows the connected account" hints at a plan gate. However, there is no explicit when-to-use / when-not-to-use statement and no named alternative among the many rate/curve siblings, so the agent must 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?

Annotations already declare readOnly, idempotent, non-destructive, open-world, so the safety profile is covered. The description adds a genuinely non-structured behavioral fact — 'Draws no credit' — telling the agent this enumeration is free against any quota, which is exactly the kind of context annotations cannot express.

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 with the resource identity front-loaded and the downstream-use note second. The filler 'and so on' slightly dilutes the otherwise tight phrasing but does not harm selection.

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 parameterless, read-only catalog lookup with full annotation coverage, an agent has enough to select and invoke it: what it returns, why it matters (slugs), and that it costs nothing. No output schema exists, but the description states the key returned field, so nothing critical 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?

Zero parameters, so there is nothing for the description to disambiguate; baseline for a parameterless tool applies. The only semantic content needed is what the call returns (slugs), which the description does supply.

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 (every US economic series Helious tracks), illustrates it with concrete examples (CPI, payrolls, GDP), and states the payload value (each series' slug). It implicitly contrasts with get_series, the per-series fetch tool, though it never uses an explicit verb like 'list' — the enumeration intent is inferred from 'Every ... series ... with its slug.'

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?

'with its slug for get_series' establishes the intended two-step workflow: discover a slug here, then call get_series. It gives clear positive context but no explicit exclusions or when-not-to-use guidance (e.g., call get_series directly if you already know the slug).

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