US Treasury auction tails, the live curve regime, scored macro releases, and why rates moved.
Scored across 24 tools
Most tools have clearly distinct purposes and the descriptions carefully separate the many rate/curve and Fed-related endpoints. A few names like get_rates_and_curve, get_treasury_curve, and get_yield_closes could still cause mis-selection without reading the descriptions closely.
All tool names follow a consistent snake_case verb_noun pattern, with get_ overwhelmingly dominant and list_series a sensible enumeration verb. There are no mixed naming conventions or vague generic verbs.
At 24 tools, the server sits in the borderline/heavy range. Each tool does map to a distinct data product, but the rate and curve surface especially could be consolidated, making the set feel larger than necessary.
The server covers a broad and coherent read-only market intelligence domain: rates, Fed, inflation, employment, economic calendar, FX, volatility, equities, and event digests. Minor gaps like limited global equity detail and no full historical market data for individual stocks keep it from being fully complete.
What your current tier can do, the full plan ladder, and the exact steps to tell your user when you need more: make a free account, get a key, or subscribe.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and non-destructive behavior. The description adds useful context about the content returned and the actionable steps it provides, which goes beyond the annotations without contradicting them.
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, well-structured sentence that front-loads the core value and uses a colon to enumerate the specific content. Every phrase earns its place with no 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?
For a simple, parameterless informational tool with strong annotations, the description is complete enough to guide an agent. It explains what the tool covers and the user actions it supports, though it does not describe the exact response format.
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 has zero parameters and the schema coverage is effectively 100%, so the description does not need to explain parameters. The baseline of 4 applies because there is nothing for the description to add semantically.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states what the tool provides: current tier capabilities, the full plan ladder, and exact steps for account creation, key acquisition, or subscription. This distinguishes it sharply from the sibling data-retrieval tools like get_auctions or get_fx_board.
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 implies when to use this tool: when the user needs more access or wants to understand plan limitations. It gives concrete user-facing steps but does not explicitly name alternatives or state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
US Treasury auction results, measured by Helious at the close: the high yield, the tail against the when-issued yield, bid-to-cover against the tenor's twelve-auction average, who bought (indirect, direct, dealer), and the desk's strong, in line or weak verdict. Pass tenor to ask about one part of the curve, like 10-year-note or 30-year-bond, which is what you want for 'how did the last 10-year auction go'. The tail is the number that answers whether an auction was good or bad, and Helious is the only free source that publishes it.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Most auctions to return. | |
| tenor | No | One tenor, like 10-year-note, 30-year-bond or 26-week-bill. Plain forms work too: '10y', '30 year'. Or a whole class: bills, notes, bonds, tips, frn. Or a curve SEGMENT, which is usually what 'the front end / belly / long end of the curve' means: front (bills plus the 2- and 3-year notes), belly (the 5-, 7- and 10-year), long (the 20- and 30-year). Reopenings of a tenor are included. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the call read-only, idempotent, open-world, and non-destructive; the description adds useful behavioral context that is not in the annotations, such as results being measured at the close, the tail being measured against when-issued yield, and bid-to-cover being compared to a twelve-auction average. It stops short of describing result ordering or default limits, but the safety profile is well covered.
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 only three sentences, front-loads the output contents, and then gives usage guidance. It loses a point because the claim that Helious is the only free source publishing tails is promotional and irrelevant to selecting or invoking the 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?
Since there is no output schema, the description compensates by listing the returned metrics, defining the critical tail concept, and explaining the verdict scale. It is sufficient for the stated use case, though minor operational details like default limit and ordering are absent.
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 schema already documents limit and offers a rich tenor explanation with examples, classes, and segments; the description's tenor mention reinforces that guidance but adds no new parameter-level 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?
The description clearly identifies the resource as US Treasury auction results and enumerates the specific returned metrics: high yield, tail versus when-issued, bid-to-cover versus the twelve-auction average, buyer categories, and a strong/in-line/weak verdict. It is distinguishable from sibling curve and rate tools by content, though it never explicitly names an alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives a concrete query trigger: pass a tenor when the user asks how the last 10-year or 30-year auction went, and explains that the tail is the good/bad signal. It does not name sibling tools or state when not to use this tool, so it falls just short of fully explicit routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Cross-asset correlation matrix (stocks, bonds, dollar, gold, oil) over 30 to 120 day windows. Newest reading plus past boards. Market data: answers with numbers on Pro and Ultimate.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Most rows to return. | |
| since | No | Oldest date to include, like 2026-06-01. How far back you can go depends on your plan. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, openWorld, and non-destructive behavior. The description adds meaningful context: it returns both the newest reading and past boards, and it notes that answers with numbers depend on Pro/Ultimate access. No contradiction with 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?
The description is compact and front-loaded: three short sentences cover asset classes, time windows, output format, and access constraints. It is efficient and easy to scan without 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 read-only tool with two optional parameters and no output schema, the description covers the essential context: assets, windows, output type, and plan requirements. Minor gaps such as exact row format and default limit are partially mitigated by the annotations and 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 both limit and since well explained in the schema. The description does not add extra parameter-level meaning beyond what the schema already provides, so 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?
The description clearly identifies the tool's function: it returns a cross-asset correlation matrix for stocks, bonds, dollar, gold, and oil over 30–120 day windows. It distinguishes itself from most siblings by specifying assets and lookback, though it does not explicitly name an alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied—when you need cross-asset correlations, this is the tool—but no explicit when-to-use or when-not-to-use guidance is given relative to siblings like get_market_context. The only added guidance is a plan restriction note.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Past curve regime changes: every flip with its time, what it flipped from, and how the session closed.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Most rows to return. | |
| since | No | Oldest date to include, like 2026-06-01. How far back you can go depends on your plan. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, covering safety. The description adds return content details but does not disclose behaviors like pagination limits or potential truncation due to the 'limit' parameter, which is a minor gap. 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?
A single, information-dense sentence delivers the core purpose and output details without any fluff. Front-loaded with the subject and highly efficient.
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 read-only list tool with no output schema, the description adequately explains the return shape (flips, time, from-state, session close). However, it omits the effect of the 'limit' parameter on 'every flip' and the plan-dependent date range, though the latter is in the schema. Given good annotations and schema, this is mostly 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?
Both 'limit' and 'since' are fully described in the schema (100% coverage). The description adds no extra parameter context, so it meets the baseline but does not enhance understanding beyond what the schema offers.
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 it returns 'Past curve regime changes' with specific details (time, from-state, session close), making it distinct from siblings like get_treasury_curve or get_rates_and_curve. The verb 'get history' is specific and the resource is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving historical curve regime flip data, which is clear context. However, it does not explicitly exclude alternatives or reference sibling tools, so it falls short of a 5 but fits 'clear context, no exclusions'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The desk's read of FULL central bank documents, not headlines: FOMC minutes and Fed/ECB speeches read end to end. Each digest carries a summary, what is genuinely new versus what the market already knew, key findings with their market consequence, a hawkish/dovish committee lean, and quotes verified word for word against the source document. Minutes carry no bond or equity direction on purpose: they describe a meeting about three weeks earlier, so the desk states the lean and declines the market call. Delayed 60 minutes without a paid key.
| Name | Required | Description | Default |
|---|---|---|---|
| kind | No | minutes, speech, or all (default). | |
| limit | No | Most digests to return. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnly, idempotent, non-destructive), the description discloses key behaviors: the 60-minute delay for free users, the deliberate omission of market direction in minutes, and the verification of quotes against source. These add significant context that annotations do not convey.
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 detailed but not bloated. It front-loads the main purpose and then lists digest contents and caveats in a logical sequence. Each sentence serves a purpose, though a slightly shorter version could retain clarity. Strong structure overall.
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 no output schema, the description adequately explains what each digest contains (summary, novelty, market impact, lean, quotes). It also notes the delay and minute-specific caveat. This is sufficient for an agent to decide whether to call the tool, though it does not detail pagination or exact format.
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% for both parameters (kind, limit), with clear descriptions. The tool description does not add additional parameter-specific meaning beyond what the schema already provides, though it implicitly echoes the 'kind' values. Baseline 3 applies because schema covers it fully.
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 the tool provides digests of FOMC minutes and Fed/ECB speeches, read end to end, with specific components (summary, new vs. known, market consequence, lean, verified quotes). It distinguishes itself from sibling market-data tools by focusing on document digests rather than numeric data.
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 implies use for those needing detailed central bank document analysis rather than headlines, and points out a limitation for minutes (no market direction). However, it does not explicitly state when to use this tool versus alternatives, and does not name any sibling tools as alternatives or complementarities.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
US mega-cap earnings: when a company reports, whether that date is confirmed or still an estimate, whether it prints before the open or after the close, the consensus EPS, and once it lands the reported EPS with the beat or miss. Pass symbol for one name, like AAPL. This is the tool for any question about a company's earnings date or EPS.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Most rows to return. | |
| symbol | No | One or more tickers, comma separated, like AAPL or AAPL,MSFT. Empty returns every name tracked. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true and destructiveHint=false, so the agent knows the operation is safe. The description adds meaningful behavioral context by explaining that dates can be 'confirmed or still estimate', that print timing is indicated, and that EPS data can be consensus or reported with a beat/miss.
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 one substantial sentence plus two short instructive sentences, and it is front-loaded with the core purpose. It is reasonably concise and each sentence contributes meaningful information without unnecessary 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?
There is no output schema, but the description enumerates the expected return content: report date, confirmation status, pre/post timing, consensus EPS, and reported EPS with reward. The description is adequate for a relatively simple two-parameter read-only tool with no nested structures.
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 input schema already provides full coverage of both parameters (symbol and limit), including example formats for symbol. The description adds no meaningful parameter detail beyond the schema's descriptions, 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 clearly identifies the tool as providing US mega-cap earnings dates and EPS, specifying the exact data fields covered: report date, confirmed/estimated status, pre/post market timing, consensus EPS, and reported EPS with beat/miss. This clearly distinguishes it from sibling market-data tools and makes the purpose obvious.
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 explicitly states this is 'the tool for any question about a company's earnings date or EPS' and gives a concrete usage example ('Pass symbol for one name, like AAPL'). It does not explicitly mention alternatives or when not to use it, but the usage context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Economic releases with forecasts, prior values and the actual once it prints, plus Fed speakers and auction times. Defaults to yesterday through the next 7 days; widen days_back and days_ahead to see more, or filter to one country like US, EU, GB or JP.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Most events to return. Default 100. | |
| country | No | Two-letter country or bloc, like US, EU, GB, JP. Empty means everywhere. | |
| days_back | No | How many days of already-printed events to include. Default 1, up to 90. | |
| days_ahead | No | How many days ahead to include. Default 7, up to 365. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations (readOnlyHint: true, destructiveHint: false) already signal a safe read operation. The description adds behavioral context by revealing the default time window and that the actual value appears 'once it prints', implying the data is dynamic over time. It also mentions the ability to widen the range or filter by country, which are useful behavioral details not conveyed by annotations alone.
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 two sentences, front-loaded with the core purpose in the first sentence and usage details in the second. Every phrase adds informational value—no repetition, fluff, or redundant content. It is compact yet comprehensive for its scope.
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 calendar tool with all parameters documented and no output schema, the description sufficiently covers the key aspects: what data is returned (forecasts, prior, actual, Fed speakers, auction times), default behavior, and filtering options. It does not detail response format or pagination, but given the simple nature and the annotations covering safety, the description is adequately 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 each parameter has a description. The description adds value by explaining the interaction of days_back and days_ahead ('Defaults to yesterday through the next 7 days; widen ...') and clarifying the country parameter ('filter to one country'). This reinforces the schema's meaning and provides usage context beyond the raw parameter definitions.
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 the tool returns 'Economic releases with forecasts, prior values and the actual once it prints, plus Fed speakers and auction times.' This is specific about the resource (economic calendar) and its contents, distinguishing it from siblings like get_auctions (auction details) and get_fed_roster (Fed membership). It also notes the default date range and filtering options, enriching purpose clarity.
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 practical usage hints ('Defaults to yesterday through the next 7 days; widen days_back and days_ahead to see more, or filter to one country') but does not explicitly state when to use this tool over alternatives. It does not mention when not to use it or point to sibling tools for other needs. While purpose is clear, guidance on selection is implicit, not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Who is on the FOMC: governors and presidents, who votes this year, their lean, and their upcoming speeches.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only and idempotent behavior. The description adds useful context about the content scope (including lean and upcoming speeches), which helps the agent set expectations, though it does not add extra behavioral constraints beyond 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?
The description is a single, efficient sentence that front-loads the key content and avoids any redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless read-only tool with no output schema, the description sufficiently covers what the agent will get (member list, votes, lean, speeches). No further details are necessary.
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 has zero parameters and an empty schema (100% schema description coverage). The baseline for a zero-parameter tool is 4, and the description does not need to add parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states what the tool provides: FOMC members (governors and presidents), voting status, lean, and upcoming speeches. This distinguishes it from sibling tools focused on market data, auctions, rates, etc.
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 context is clear—this is for FOMC roster information—and sibling tool names provide implicit differentiation. However, there is no explicit statement of when to use this tool versus alternatives or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The posts Helious publishes: scored releases, auction results, board updates, the daily brief and live squawk lines. Posts carry helious_read, the desk's plain-English line on why it matters. Depth follows your plan (1 day keyless, 7 days free, 12-24 months paid, 10 years Ultimate). Optional q filters by word; categories narrows to chosen lanes. Delayed 60 minutes without a paid key.
| Name | Required | Description | Default |
|---|---|---|---|
| q | No | Filter word. | |
| limit | No | Most items to return. | |
| categories | No | Comma-separated lanes, like release,auction. Empty means all. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already signal read-only, idempotent, non-destructive behavior. The description adds meaningful context beyond those annotations: data depth depends on the user's plan, and posts are delayed by 60 minutes without a paid key. It also notes what the posts carry, which gives the agent a better sense of the feed's content.
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 compact and front-loaded. The first sentence establishes the tool's purpose, and the following sentences provide filtering, depth, and delay details without unnecessary verbiage. Every sentence contributes to correct selection and use.
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 three-parameter, no-output-schema feed tool, the description is mostly complete: it covers the feed's contents, filtering, availability, delay, and item-level explanation. It does not mention ordering or pagination, but that is a relatively minor gap for a read-only feed.
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?
All three parameters already have schema descriptions, so the baseline is 3. The description mentions q and categories, but adds only minor meaning beyond the schema, and it does not describe the limit parameter. This is adequate but not additive.
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 identifies the tool as the feed of posts Helious publishes and enumerates the content types: scored releases, auction results, board updates, daily brief, and squawk lines. It is specific about the resource, but it does not explicitly differentiate the feed from closely related sibling tools 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?
The description gives useful usage context: optional q and categories filtering, plan-dependent data depth, and a 60-minute delay without a paid key. However, it does not explicitly say when to prefer this tool over a sibling tool or which tools to use for narrower, topic-specific data.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
FX momentum scorecard: seven major currencies scored against the basket. Newest reading plus past boards. Market data: answers with numbers on Pro and Ultimate.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Most rows to return. | |
| since | No | Oldest date to include, like 2026-06-01. How far back you can go depends on your plan. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, idempotent, non-destructive behavior. The description adds useful context beyond those annotations: it returns numeric market data on Pro and Ultimate plans, and it includes both the newest reading and historical boards. This helps the agent set expectations around plan restrictions and data availability.
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 short and front-loaded with the core purpose. The last sentence, "Market data: answers with numbers on Pro and Ultimate," is a bit awkward but still captures plan-gated numeric output in a compact way.
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 read-only endpoint with two optional, well-documented parameters, this description is reasonably complete. It covers the content of the scorecard, the ability to view past boards, and a plan-related restriction. It does not enumerate return columns or explicitly handle sibling-tool confusion, but those are not critical gaps for invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the `limit` and `since` parameters are already documented in the schema. The description reinforces that historical boards are available but does not add meaningful detail about how `limit` or `since` should be formatted or how they interact.
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 identifies the resource: an FX momentum board/scorecard with seven major currencies scored against a basket, plus current and historical boards. It is more specific than just restating the tool name, but it does not explicitly differentiate it from sibling tools like get_correlations or get_vol_board.
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 intended use case is implied by the description: an FX momentum scorecard with current and past readings. However, there is no explicit statement about when to choose this versus other market-data siblings, and no "use X instead" guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Ships through the Strait of Hormuz per day, split tanker and cargo, measured by Helious from live ship tracking.
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | How many days back. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, and non-destructive behavior, so the description is not burdened with safety disclosure. It adds valuable context about the data source (Helious live ship tracking) and the segmentation (tanker/cargo) beyond the annotations. This extra detail helps the agent understand what the tool actually returns, though it does not describe pagination or output format.
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 front-loads the core purpose ('ships through the Strait of Hormuz per day') followed by supporting details. Every phrase contributes meaning, with no fluff or repetition. It is highly concise and well-structured.
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 retrieval tool with one optional parameter and no output schema, the description provides sufficient context: daily resolution, segmentation, and data source. It does not describe the exact return format, but given the simplicity and annotations, the agent can infer the likely shape. Slight gap is that it doesn't clarify whether the result is a time series or single aggregate, but this is 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?
The input schema fully documents the single 'days' parameter as 'How many days back,' achieving 100% coverage. The description adds no additional meaning about how the parameter behaves (e.g., defaults, allowed range, or interaction with the daily data). Therefore, the description does not enhance the schema's parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as providing daily ship transits through the Strait of Hormuz, segmented by tanker and cargo. This is specific and distinguishes it from sibling tools, which focus on other market data. The mention of 'Helious' and 'live ship tracking' adds provenance without ambiguity.
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 implies usage when Hormuz transit data is needed, but provides no explicit guidance on when to use this tool versus alternatives. It does not mention situations where other tools would be more appropriate, nor does it list alternatives. The 'per day' phrasing hints at temporal resolution but not at selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Every US inflation measure on one axis: headline and core CPI and PCE, supercore, the trimmed means, the median, the sticky and flexible splits, the CPI components, and what markets expect next. Each one comes back with its year-over-year reading plus 1, 3 and 6-month annualised, so you never have to annualise anything yourself. Also says which parts of the basket are driving the headline rate. measures filters by key, history adds the monthly series. Published statistics, so it answers on every tier.
| Name | Required | Description | Default |
|---|---|---|---|
| window | No | Months of history to include when history is true. | |
| history | No | Add the full monthly series per measure. | |
| measures | No | Comma-separated keys to return, such as core_cpi,core_pce. Omit for all of them. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, idempotent, non-destructive behavior. The description adds valuable behavioral context beyond that: it returns year-over-year plus 1/3/6-month annualized readings, identifies basket drivers, and notes that published statistics answer on every data tier. No contradictions with 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?
The description is dense but each sentence contributes: it enumerates scope, explains return calculations, mentions basket-driver attribution, and maps the key parameters. It is a bit lengthy, but the front-loaded scope line helps an agent quickly recognize relevance.
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 there is no output schema, the description does a good job explaining what will come back: measure list, YoY plus annualized horizons, and driver attribution. It could be more explicit about response shape and supported measure keys, but the tool has zero required parameters, so an agent can successfully call it with no arguments.
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 description restates the `measures` filter and `history` series behavior but does not meaningfully extend what the schema already provides; it gives no additional detail about `window` or valid measure keys beyond the schema examples.
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 identifies the specific resource: all US inflation measures, with an explicit enumeration of measure families (CPI, PCE, trimmed means, median, sticky/flexible, CPI components, market expectations). This clearly distinguishes it from the sibling market/rates tools, and the return behavior is implied with 'Each one comes back 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?
It clearly implies when to use the tool: whenever an agent needs US inflation data across many measures, especially when annualized rates or basket-driver attribution would otherwise require manual calculation. It does not explicitly name alternatives or state when not to use it, but the context is strong.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Every US employment measure on one axis: total nonfarm payrolls split into private and government, the ten private sectors, federal, state and local government, ADP's own private count by sector, initial and continuing jobless claims, and JOLTS openings, hires, quits and layoffs including openings by sector. Each comes back with its monthly change plus 3, 6 and 12-month windows, in THOUSANDS of jobs. Also says which sectors drove the headline, and those parts sum to it exactly. Percentages such as the unemployment and quits rates ride in standing. measures filters by key, history adds the monthly series. Published statistics, so it answers on every tier.
| Name | Required | Description | Default |
|---|---|---|---|
| window | No | Months of history to include when history is true. | |
| history | No | Add the full monthly series per measure. | |
| measures | No | Comma-separated keys to return, such as payrolls,edhealth,openings. Omit for all. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Even with readOnlyHint and idempotentHint annotations, the description adds impactful behavioral details: units in thousands, 3/6/12-month windows, exact summation of sector contributions, separation of percentages into 'standing', and behavior of 'measures' and 'history' flags. No contradiction with 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?
The description is dense but every sentence adds technical value, explaining contents, return structure, units, and filtering. It is front-loaded with the resource scope, though the single run-on paragraph could be structured with clearer separation between output behavior and parameter behavior.
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 full burden of explaining return values. It covers units, time windows, the 'standing' field for percentages, the exact-sum property, and parameter effects. The 'answers on every tier' note covers access context. Nothing essential 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 description coverage is 100%, so the baseline is 3. The description repeats parameter behavior ('measures' filters by key, 'history' adds series) without adding new meaning beyond the schema, though it provides a few example keys and ties output fields to parameters.
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 uses a specific resource focus ('Every US employment measure') and enumerates the exact contents, which clearly distinguishes it from sibling tools like get_inflation or get_earnings. It is immediately obvious this is the go-to tool for US employment and jobs data.
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?
Clear context is provided about what data is returned, so an agent can infer when this tool is appropriate. However, it does not explicitly name alternatives or state when not to use it, stopping short of a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
START HERE for any 'why is the market doing this' question. One call gives the whole cross-asset board (equities, the Treasury curve, FX, volatility, commodities), every scored economic release behind it, and the Helious desk's read on what is actually driving the session: whether it is event-driven, flow-driven or quiet, the evidence that read rests on, and the regime yields and stocks have actually been trading in. Use this before the individual board tools: it saves five calls, and it characterises the session rather than leaving you to guess a cause. Market data: answers with numbers on Pro and Ultimate.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already mark this as a safe, read-only, idempotent operation, so the bar for extra value is lower. The description adds meaningful behavioral context beyond annotations: it covers session characterization, event/flow/quiet classifications, evidence-based reasoning, and the data-tier caveat about Pro and Ultimate. There is no contradiction and no hidden side effects implied.
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 opens with a strong 'START HERE' hook and every subsequent sentence earns its place by adding scope, evidence basis, or a data-access caveat. Some wording is slightly lengthy, but it is structured to front-load the key decision and then elaborate on return 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 needs to convey what the agent will get back, and it does thoroughly: asset classes, economic releases, desk sentiment, supporting evidence, and trading regimes. The guidance about when to use it and what it returns is complete enough for correct selection and 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?
There are zero parameters, and the schema description coverage is 100%, so there is nothing for the description to add about parameter meanings. The baseline for a no-parameter tool is 4, and the description reinforces that the tool uses no arguments by framing it as a single omnibus call.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb-resource pairing: 'START HERE for any why-is-the-market-doing-this question' and lists the aggregated content (cross-asset board, scored releases, desk read). It clearly distinguishes itself from the sibling board tools by calling itself the whole-board summary and positioning them as 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?
It explicitly tells the agent when to use it ('any why is the market doing this question' and 'Use this before the individual board tools'), and names the alternative class of tools to switch to for narrower data. The guidance that it saves five calls further informs selection behavior.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The NASDAQ-100 ranked best to worst on the session: price, change and sector for every stock. Pass symbol to ask about ONE company instead, like AAPL or NVDA, and you get its price, its move on the session and where it ranks on the board today. Equities are market data: live on Pro and Ultimate, upgrade steps instead of numbers below.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Most stocks to return. | |
| symbol | No | One or more NASDAQ-100 tickers, comma separated, like AAPL or AAPL,MSFT. Empty returns the whole ranked board. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool as readOnly and idempotent, so the description does not need to repeat that. It adds meaningful behavior: the ordering semantics ('best to worst'), what each board entry includes, and that live data requires Pro/Ultimate. The 'upgrade steps instead of numbers below' detail is genuinely useful for interpreting placeholder responses.
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, each earning its place: first defines the board content, second defines the symbol-filtered behavior, third explains data freshness and access tier. Information is front-loaded and there is no padding or repetition of schema details.
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/filter tool with full schema descriptions and rich annotations, the description covers the essential outputs, ordering, filtering, and access-tier nuance. While a structured output schema is missing, the prose is enough for an agent to call it correctly. Minor gaps such as the interaction with limit are already handled by 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?
The input schema already documents both parameters 100%, including that symbol supports comma-separated tickers and empty returns the full board. The description's prose reinforces the symbol parameter and adds examples, but does not significantly extend or clarify beyond the schema. The phrase 'ONE company' is slightly narrower than the schema's 'one or more' but the schema resolves that difference.
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 action and resource: it returns the NASDAQ-100 ranked best to worst, with price, change, and sector for each stock. It distinguishes itself from the sibling board tools (fx_board, vol_board) via the NASDAQ-100 qualifier and adds filtering to a single company. No ambiguity remains about what the tool does.
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 clearly explains two usage modes: no symbol returns the whole ranked board, and passing a symbol returns a single company's price, session move, and rank. It also conveys access-tier behavior by noting data is live on Pro/Ultimate. It does not explicitly name alternatives for exclusion, but the two modes provide clear practical guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The odds of a Federal Reserve rate cut or hike at each remaining FOMC meeting, priced from fed funds futures. THIS IS THE TOOL for 'what are the odds of a cut in September', 'is the Fed cutting', 'what is priced in for the next meeting' or 'how many cuts this year'. Gives the probability per meeting, the implied effective rate after each one, and the total move priced across the whole path. Computed by Helious from settlement prices against the effective fed funds rate, not the target midpoint.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnly and non-destructive. The description adds context about how the data is computed (from settlement prices against effective fed funds rate) and what is included, though it doesn't mention any potential side effects, which aligns with readOnly.
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 somewhat redundant, repeating 'priced from fed funds futures' and 'effective fed funds rate' in similar phrasing. It could be more concise without losing meaning.
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 adequately explains the return value: probability per meeting, implied effective rate after each, and total move across the path. This is sufficient for a no-parameter 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 has zero parameters, so the baseline is 4. The description adds no parameter details, but none are needed.
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 the tool provides Fed rate cut/hike odds for FOMC meetings, derived from fed funds futures. It distinguishes itself from sibling tools like get_rates_and_curve by specifying the odds/probability focus.
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 states 'THIS IS THE TOOL for' and provides concrete example queries (e.g., 'what are the odds of a cut in September'), which gives clear guidance on when to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
What the market is paying for US interest rates up to four years out. Two strips, kept apart because they are DIFFERENT RATES: sr3 is sixteen quarterly 3-month SOFR futures grouped into the whites, reds, greens and blues a rates desk quotes, and ff is forty-eight monthly 30-day fed funds contracts. Every contract carries its implied rate now and the rate the SAME contract carried six and twelve months ago, so the gap is the market changing its mind rather than a different instrument. Rates are percent. These are traded prices and not forecasts. Do not compare the two lanes contract by contract: SOFR is secured and the fed funds effective rate is not, and an SR3 month spans the quarter between two IMM dates while a fed funds month is a calendar month.
| Name | Required | Description | Default |
|---|---|---|---|
| lane | No | sr3 for the quarterly SOFR strip, ff for the monthly fed funds strip. Omit for both. | |
| history | No | Add each contract's own daily settlement run. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, and non-destructive behavior. The description goes beyond this by explaining that historical rates come from the SAME contract, that the two strips are fundamentally different rate benchmarks, and that results are percentages. This prevents real misinterpretation and adds value beyond 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?
The description leads with the core answer—'What the market is paying for US interest rates'—and each sentence contributes useful either interpretative or structural detail. It is a bit dense, especially the strip-composition details, but no sentence is pure filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description carries the burden of explaining return content, and it does so by stating each contract's current and historical rates. It covers the important pitfalls—percent units, traded-versus-forecast status, lane comparability—and is generally complete for a read-only data tool, though it does not explicitly describe how the `history` parameter changes the returned shape.
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 parameters are already documented. The description adds practical meaning by elaborating the lane values (16 quarterly SOFR contracts vs 48 monthly fed funds contracts) and framing history as same-contract rates six and twelve months ago. This gives the boolean `history` parameter concrete semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies a specific resource: US interest-rate futures strips out to four years, with two lanes (`sr3` and `ff`) and their contract structures. It does not use an explicit action verb like 'get' or contrast itself against a sibling tool, so it does not fully reach the top of the scale, but the resource and scope are clear.
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 strong within-tool usage guidance: these are traded prices, not forecasts, and the two lanes should not be compared contract by contract. However, it does not state when to prefer this tool over nearby siblings such as get_rates_and_curve or get_treasury_curve, so the choice-when-to-use case is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
US Treasury yields, the 2s10s and other spreads, and the curve regime (bull or bear, steepener or flattener) with the time it flipped. Prices are live on Pro and Ultimate, one hour behind on Starter, and answer with upgrade steps on the free tiers.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish read-only, idempotent, non-destructive behavior. The description adds useful non-obvious behavioral details: prices are live on Pro/Ultimate, delayed on Starter, and free tiers receive upgrade steps instead of the full answer.
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, front-loaded sentences cover both data content and access-tier behavior without redundancy or boilerplate. Every phrase adds practical information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless read-only tool, this description is largely complete: it names the data, the included spreads, the regime regime, and the pricing tiers. The main omission is the exact return shape, but no output schema exists and the content is reasonably covered.
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 has zero parameters, so the description carries no parameter burden. It does, however, set expectations about the data returned, including yields, spreads, and curve-regime timing.
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 identifies the resource: US Treasury yields, spreads like 2s10s, and the curve regime with the time it flipped. This makes the tool meaningful relative to many siblings, though it does not explicitly distinguish itself from the closely related 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 no guidance about when to use this tool versus the many get_* siblings. There is no mention of alternatives or exclusion criteria, so an agent must infer selection from naming and content alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
One economic data series: the latest print, the forecast, the surprise in standard deviations, and the history.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | No | Series slug from list_series, like cpi or nonfarm-payrolls. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover safety (readOnly, idempotent). The description adds output content details but does not disclose potential errors, edge cases, or performance characteristics. Beyond the annotations, it offers limited additional behavioral context.
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, concise sentence with no redundant information. It efficiently conveys the core purpose without unnecessary detail.
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 gives a general idea of the return (latest print, forecast, surprise, history) but lacks specifics on format, units, or time range. It is adequate for a simple tool but could be more 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?
The input schema already provides a clear description of the 'slug' parameter, including examples. The tool description does not add further meaning to the parameter, so it remains at 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?
The description clearly states the tool returns a single economic data series with the latest print, forecast, surprise, and history. It differentiates from siblings by focusing on one series, but could be more explicit about its unique role.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool versus alternatives like list_series or other get_* tools. It only mentions 'one economic data series' without guidance on selection criteria or prerequisites, though the parameter description hints at using list_series for slugs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Live events Helious transcribed in the last week (Fed pressers, briefings), one entry per event.
| Name | Required | Description | Default |
|---|---|---|---|
| hours | No | How many hours back, up to 168. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds useful scope details ('last week', 'one entry per event') but does not disclose response format, timezone handling, or event detail fields.
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 concise sentence states the resource, scope, and output granularity immediately. There is no filler or redundant restating 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?
This is a simple read-only tool with one optional parameter, rich annotations, and clear scope. The description covers the time window and result granularity; absence of output schema is partially mitigated by the straightforward nature of the tool, though return field details would improve completeness.
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 single optional 'hours' parameter is fully described in the schema (integer up to 168), so schema coverage is 100%. The description adds no extra semantic meaning or default behavior, which is acceptable given the schema already provides the necessary detail.
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 identifies the tool as retrieving live events transcribed by Helious, specifically Fed pressers and briefings, with one entry per event. It states the resource and scope, though it does not explicitly differentiate from sibling tools like get_fed_roster or get_market_context.
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 implies use for recent transcribed live events within the last week, which gives clear context for when to call this tool. It does not mention exclusions or alternatives, but for this narrow read-only tool the context is sufficiently clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The whole US Treasury curve in one call, 3M bill to 30Y bond with daily closes: live points on Pro and Ultimate, one hour behind on Starter, upgrade steps instead of numbers on the free tiers.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnly, idempotent, and non-destructive behavior. The description adds useful behavioral context beyond annotations: daily closes, live versus delayed data based on subscription level, and the free-tier limitation where 'upgrade steps' appear instead of numbers. No contradiction with 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?
A single dense sentence that front-loads the core purpose, then compactly conveys scope (maturity range), frequency (daily closes), and tier-dependent behavior. Every clause provides useful information; no wasted 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?
For a zero-parameter tool with no output schema, the description explains what is returned (the whole curve), the covered maturities, and plan-based delivery nuances. It does not describe the exact output shape, but for a simple curve snapshot the missing detail is minor given the clear core purpose.
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 has zero parameters and an empty input schema, so the schema fully covers parameter concerns. The description does not need to add parameter semantics, and the no-parameter baseline of 4 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 identifies a specific resource (the entire US Treasury curve, 3M bill to 30Y bond) and implies the action of fetching it in one call. It is clear and distinct from generic curve tools, though it does not explicitly name a sibling to differentiate itself.
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 explains the data freshness tiers (live vs one-hour delayed vs free-tier placeholders) but does not clarify when to choose this tool over siblings like get_curve_history, get_rates_and_curve, or get_yield_closes. No explicit 'when to use' or 'when not to use' guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Implied volatility board: VIX and the other vol gauges with their one-year percentile. Newest reading plus past boards. Market data: answers with numbers on Pro and Ultimate.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Most rows to return. | |
| since | No | Oldest date to include, like 2026-06-01. How far back you can go depends on your plan. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnlyHint, idempotentHint, non-destructive), so the description only needs to add behavioral context. It adds the Pro/Ultimate access note and the fact that the tool returns both current and historical boards, but it does not describe pagination behavior, default limits, or what happens when history is unavailable.
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 short and front-loads the most important content in the first sentence. The final 'Market data: answers with numbers on Pro and Ultimate' clause is a little terse, but it carries useful access-tier information rather than being pure 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 simple read-only, parameter-free card tool, the schema and annotations cover a large part of invocation. The description names the returned kind of content, but with no output schema it falls short of fully describing the shape of the returned absurdity, such as exact fields, row count limits, or how 'past boards' are included.
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 input schema already documents both parameters completely, so the baseline is 3 even though the description adds little parameter-specific meaning. The phrase 'newest reading plus past boards' loosely supports the since parameter, but the description provides no extra detail on limits or date ranges 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 clearly identifies the tool as an implied volatility board and gives concrete contents: VIX, other volatility gauges, one-year percentiles, and both current and historical boards. It is distinguishable from the sibling financial-market tools, though it does not explicitly name one or contrast itself with a specific 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?
The description does not state when to prefer this tool over siblings like get_market_context, get_fx_board, or get_treasury_curve. It implies the usage is 'when someone wants volatility readings,' but it gives no explicit or when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Official 17:00 New York Treasury yield closes per session, as Helious recorded them. Opens on Starter and above.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Most rows to return. | |
| since | No | Oldest date to include, like 2026-06-01. How far back you can go depends on your plan. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide the safety profile (read-only, idempotent, open-world, non-destructive), lowering the burden on the description. The description adds the origin of the data (Helious recordings), the official 17:00 New York session scope, and the Starter plan requirement, but it does not clarify ordering, pagination, or how 'per session' appears in results.
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 compact and readable, with two short sentences. It front-loads the core data definition and adds plan-level context, although the opening phrase partially repeats the title, which costs it the highest mark.
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 list tool with two optional parameters and strong annotations, the definition is fairly complete: it identifies the data source, the session time, and access plan. It lacks any statement about return shape or ordering, but the absence of an output schema is not critical here given the simple topic.
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%: both optional parameters (limit and since) are already documented in the schema with clear explanations. The description supplies no extra information about parameter semantics, so the baseline 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 Official 17:00 New York Treasury yield closes per session, as recorded by Helious. This is precise enough to be distinguished from sibling tools like get_treasury_curve or get_rates_and_curve, though it does not explicitly name an alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit statement of when to use this tool versus siblings, and no alternative is referenced. The intended use is implied by the title and description—getting official 17:00 closes—but the definition does not help the agent choose confidently among related market-data tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Every US economic data series Helious tracks (CPI, payrolls, GDP and so on) with its slug for get_series.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide read-only, open-world, idempotent, and non-destructive hints. The description adds a useful behavioral detail—that the returned slugs are intended for use with get_series—but it does not describe response format, ordering, pagination, or coverage guarantees beyond the 'every' claim.
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 compact sentence conveys purpose, scope, examples, and the relationship to get_series. Every phrase earns its place; no redundant filler or 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?
For a no-parameter, no-output-schema list tool, the description gives enough to understand what will be returned and how to use it. An explicit note about pagination or response limits would be a minor enhancement, but the presence of the open-world and idempotent hints reduces the need.
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 has zero parameters, so the schema already covers everything parameter-related. The description correctly omits parameter details because none exist; the baseline for 0-param tools is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description states a specific verb ('list') and resource ('every US economic data series Helios tracks'), with concrete examples. It clearly distinguishes from siblings by explaining it returns the catalog of series plus the slug, not the series data itself.
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 explicitly links the output to get_series (the slug is for get_series), which tells the agent this tool is for discovering available series before retrieving a specific one. It does not mention explicit exclusions or when not to use, but the workflow direction is clear and sufficient given the sibling set.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
get_rate_pathget_jobsget_inflationget_document_digestsget_auctions1 field changedInput schema / properties / tenor / descriptionPrevious value: -"One tenor, like 10-year-note, 30-year-bond or 26-week-bill. Plain forms work too: '10y', '30 year'. Or a whole class: bills, notes, bonds, tips, frn. Reopenings of a tenor are included."New value: +"One tenor, like 10-year-note, 30-year-bond or 26-week-bill. Plain forms work too: '10y', '30 year'. Or a whole class: bills, notes, bonds, tips, frn. Or a curve SEGMENT, which is usually what 'the front end / belly / long end of the curve' means: front (bills plus the 2- and 3-year notes), belly (the 5-, 7- and 10-year), long (the 20- and 30-year). Reopenings of a tenor are included."get_access_infoget_auctionsget_correlationsget_curve_historyget_earningsget_economic_calendarget_fed_rosterget_feedget_fx_boardget_hormuz_transitsget_market_contextget_nasdaq100get_rate_oddsget_rates_and_curveget_seriesget_squawk_sessionsget_treasury_curveget_vol_boardget_yield_closeslist_seriesClaiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity – fastest for official registry listings. For a namespace such as io.github.alice/server, link the matching GitHub user, then choose Claim with GitHub. An organization namespace such as io.github.acme/server also needs that organization to have installed the Glama AI GitHub App and approved its permissions, because GitHub discloses organization membership only to apps it has installed. Use HTTP or DNS when it has not.
HTTP challenge – works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at /.well-known/glama.json on the same origin as the connector, then choose Check HTTP challenge.
DNS challenge – works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
US macro & Treasury data — FRED series, yield curve, auctions, and a macro dashboard.
US macroeconomic data: inflation, jobs, GDP, energy, and Treasury yields
Point-in-time macro, central bank rates and sentiment, COT positioning, from official sources.
Live macro data for AI agents: regime, conditions, liquidity, with input provenance. No signup.
