US Treasury auction tails, the live curve regime, scored macro releases, and why rates moved.
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Average 4.2/5 across 19 of 20 tools scored. Lowest: 3.3/5.
Most tools map cleanly to a single market slice (auctions, FX, volatility, Fed, earnings, calendar) and each description names a distinct output. The only real risk is the cluster of Treasury-yield tools—get_rates_and_curve, get_treasury_curve, and get_yield_closes—which overlap enough that an agent might pick the wrong one, though their specific angles are stated.
Nineteen tools follow the same get_noun pattern, and the single list_series exception is a conventional list operation. No style mixing or vague verbs.
At 20 tools the surface is heavier than ideal, and the four curve/yield-related tools could be consolidated. That said, the count is justified by the breadth of market data categories and every tool appears to add a distinct data slice.
Coverage is strong for the stated US macro/rates/FX/equities domain: auctions, calendar, data series, earnings, Fed policy, boards, and market context are all present, and list_series feeds get_series. Gaps are minor—e.g., no general equity quote beyond the NASDAQ-100 and no dedicated commodity board, though context covers commodities broadly.
get_access_infoYour plan and how to get moreAWhat 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.
get_auctionsTreasury auction results and tailsAUS 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. Reopenings of a tenor are included. |
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: data 'measured by Helious at the close', the tail definition, comparison to twelve-auction average, and the desk's verdict. It does not provide return format details, but the safety profile is already covered by 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 front-loaded with the tool's purpose and uses three dense, purposeful sentences. The Helious exclusivity claim is slightly promotional but does not materially hurt clarity or invocation guidance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description usefully enumerates the returned concepts (high yield, tail, bid-to-cover, bidder types, verdict) and explains why the tail matters. It omits only minor details like default result count or exact response shape, but is sufficient for an agent to select and invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the tenor parameter already includes examples ('10-year-note', '30-year-bond', '26-week-bill', plain forms, classes). The description reinforces tenor usage and aligns it with a use case, but does not add substantial new parameter semantics 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 states the tool returns 'US Treasury auction results' with specific fields (high yield, tail, bid-to-cover, bidder participation, desk verdict) and explicitly scopes it to use cases like 'how did the last 10-year auction go'. It clearly differentiates from siblings such as get_treasury_curve and get_yield_closes by focusing on auction results and tails.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives concrete when-to-use guidance ('Pass tenor to ask about one part of the curve... which is what you want for how did the last 10-year auction go'). It does not explicitly name alternatives or exclusions, but the use case is clear enough in context of sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_correlationsCross-asset correlationsACross-asset correlation matrix (stocks, bonds, dollar, gold, oil) over 30 to 120 day windows. Newest reading plus past boards.
| 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/openWorld/idempotent and non-destructive, so the description only needs to add behavioral context. It adds that output includes the newest reading plus past boards and the window range, but it does not clarify exactly what 'past boards' contains, return shape, or pagination behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core concept, no filler. The second sentence adds the historical-board output detail without 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 read-only tool with two optional parameters and rich annotations, the description is mostly complete: asset universe, window, and output notion are stated. It would be improved by explaining what 'past boards' are or how the correlation windows are represented, but the absence of an output schema makes this a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema covers both parameters with descriptions (100% coverage), so the description adds little parameter-specific meaning. `limit` and `since` are already explained; the description's mention of 30–120 day windows does not elaborate on the 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?
Description clearly identifies the tool's resource (cross-asset correlation matrix) and scope (stocks, bonds, dollar, gold, oil; 30–120 day windows). It lacks an explicit verb like 'returns' but the tool name supplies 'get', and the content distinguishes it from sibling market-data tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use it—whenever cross-asset correlations over rolling 30–120 day windows are needed—and names the asset universe. However, it gives no explicit when-not-to-use guidance or comparison with sibling tools such as get_series or get_market_context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_curve_historyCurve regime flipsAPast 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.
get_earningsMega-cap earnings dates and EPSAUS 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.
get_economic_calendarEconomic calendarAEconomic 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.
get_fed_rosterThe FOMC rosterAWho 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.
get_feedThe Helious feedAThe 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 (30 days free, 2 years paid). 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 mark readOnly and non-destructive, and the description adds behavioral details: plan-based depth (30 days free vs 2 years paid) and a 60-minute delay without a paid key. It also clarifies the helious_read plain-English annotation. No contradictions 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 four sentences and covers content, access tiers, filtering, and data delay without padding. Every sentence adds distinct value, and it is front-loaded with the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For an aggregation feed with no output schema, the description addresses content, filtering, plan-based depth, and delay. It could improve by noting ordering/pagination or mentioning limit, but overall it is reasonably 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?
All three parameters are documented in the schema (100% coverage), and the description adds contextual meaning: q filters by word and categories narrows to lanes. The limit parameter is self-explanatory. The additional context raises this above baseline 3.
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 posts Helious publishes, listing specific content types (scored releases, auction results, board updates, daily brief, live squawk lines). It goes beyond the tool name and differentiates from more specific sibling endpoints.
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 as the aggregator feed for Helious posts and explains how to filter via q and categories. However, it does not explicitly compare to alternatives or state when not to use it, so it earns 4 rather than 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_fx_boardFX momentum boardAFX momentum scorecard: seven major currencies scored against the basket. Newest reading plus past boards.
| 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 read-only, idempotent, and open-world behavior, lowering the bar. The description adds value by noting the tool returns 'newest reading plus past boards', which clarifies that multiple time snapshots may be included. It does not contradict 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, front-loaded sentence that immediately identifies the tool's purpose and scope. Every word contributes meaning, with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description should clarify the return format. It mentions 'scorecard' and 'past boards' but does not detail the structure (e.g., fields, ordering, pagination). For a simple read-only tool with two optional params, it is adequate but not exhaustive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents 'limit' and 'since'. The description adds no parameter-specific meaning beyond the schema, so 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 states the tool provides an 'FX momentum scorecard' for 'seven major currencies scored against the basket', and mentions both newest and historical readings. This is specific and differentiates from sibling tools like get_correlations or get_vol_board, which focus on other market 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 usage for FX momentum data but does not explicitly state when to choose this tool over alternatives, nor does it provide exclusions or prerequisites. It relies on the user's domain knowledge to infer applicability.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_hormuz_transitsStrait of Hormuz transitsAShips 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.
get_market_contextWhy the market is movingASTART 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.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the read-only, idempotent annotations, the description richly discloses behavior: it returns the whole cross-asset board, scored economic releases, the desk's session characterization (event-driven, flow-driven, or quiet), supporting evidence, and current regimes. This meaningfully exceeds what annotations alone provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with 'START HERE' and uses dense, purposeful language. Every clause adds useful context—scope, included content, interpretation value, and efficiency—without repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter aggregate tool with no output schema, the description is highly complete: it enumerates the asset classes, the economic releases, the causal read, and the regime context returned. The agent can confidently select and invoke the tool without additional clarification.
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 value by clarifying that a single call aggregates all market context without requiring any inputs, which aligns with the empty input 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 states the tool's purpose: answering 'why is the market doing this' questions by providing a cross-asset overview, scored economic releases, and the desk's causal read. It explicitly distinguishes itself from the individual board tools, positioning itself as the higher-level, aggregating 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 explicit when-to-use guidance ('START HERE for any why-is-the-market-doing-this question') and recommends using it before the individual board tools. It does not name specific sibling alternatives or state when not to use it, but the intended sequencing is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_nasdaq100NASDAQ-100 boardAThe 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. Live with a paid key; one hour behind without.
| 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 declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds valuable behavioral context: 'Live with a paid key; one hour behind without' and the sorting 'ranked best to worst on the session'. It does not contradict 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?
Two sentences, front-loaded with the primary purpose, then the parameter usage, then the data freshness. Every sentence adds value with no redundancy. 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?
Given no output schema, the description adequately explains what the tool returns (price, change, sector for the board; price, move, rank for a symbol). It also covers the limit parameter indirectly via schema and notes the live/delayed distinction. For a list/query tool with this complexity, the description is 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% since both parameters have descriptions. The description adds meaning beyond the schema by explaining the symbol parameter's behavior (e.g., 'you get its price, its move on the session and where it ranks'). Limit's meaning is already clear in the schema, but the description doesn't add extra nuance. Baseline 3, but the symbol elaboration lifts it to 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns the NASDAQ-100 ranked best to worst on the session with price, change, and sector for each stock. It also explains the symbol parameter for querying individual companies, which distinguishes it from other board tools like get_fx_board 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 description provides clear guidance on when to pass a symbol versus leaving it empty, and notes the difference between live and delayed data. However, it does not explicitly contrast this tool with siblings like get_market_context, so while usage context is clear, exclusions/alternatives are not addressed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_rate_oddsFed rate cut and hike oddsAThe 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.
get_rates_and_curveTreasury yields and the curve regimeAUS Treasury yields, the 2s10s and other spreads, and the curve regime (bull or bear, steepener or flattener) with the time it flipped. Live with a paid key; one hour behind without.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, open-world, idempotent, and non-destructive behavior. The description adds valuable context beyond those annotations by revealing data freshness (live with paid key, one-hour delay otherwise) and naming the specific regime states, with no contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, front-loaded with the core content and followed by a concise latency caveat. 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?
With no parameters and no output schema, the description still enumerates the key return values (yields, spreads, regime, flip time) and provides a freshness caveat. This is sufficient for a simple read-only data tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there are no parameter semantics to document. The baseline of 4 applies because the description does not need to compensate for schema gaps.
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 directly states the tool provides US Treasury yields, 2s10s/other spreads, and curve regime with flip time. This clearly identifies the resource and scope and distinguishes it from siblings like get_treasury_curve and get_yield_closes by emphasizing the regime component.
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 explicit when-to-use guidance or alternatives. The latency note implies current-data usage, but it does not explain when to prefer this tool over related siblings such as get_curve_history or get_treasury_curve.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_seriesOne economic series in depthBOne 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.
get_squawk_sessionsTranscribed live eventsALive 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.
get_treasury_curveThe whole Treasury curveAThe whole US Treasury curve in one call, 3M bill to 30Y bond: live points on paid tiers, the same curve one hour behind on free tiers, daily closes always included.
| 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, and the description adds behavioral context about data freshness (live vs. delayed) and the inclusion of daily closes, fully disclosing what to expect from the tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, compact sentence that conveys all necessary information without any fluff or redundancy, making it 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?
With no parameters and a simple output (the full curve), the description fully covers what the tool returns and the conditions (tier-based freshness), making it complete for a user to decide whether to call it.
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 no parameters in the schema, so baseline is 4. The description does not need to explain parameters, and it adds no additional parameter-related context, but this is appropriate given zero 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 clearly states the tool returns the entire US Treasury curve (from 3M to 30Y) in one call, distinguishing it from other get_* tools by specifying the complete range and the 'one call' aspect.
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 provides explicit guidance on when to use it by mentioning tier-based differences (live vs. one-hour delayed on free tiers) and that daily closes are always included, which helps users decide based on their subscription level.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_vol_boardVolatility boardAImplied volatility board: VIX and the other vol gauges with their one-year percentile. Newest reading plus past boards.
| 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?
With annotations already declaring readOnlyHint, openWorldHint, idempotentHint, and destructiveHint false, the description adds value by clarifying this returns the newest reading plus past boards, implying historical context. It doesn't contradict annotations, and the extra context about 'past boards' enriches the behavioral model beyond what annotations provide.
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 pithy sentences, front-loading the core purpose and then adding a scope note. Every phrase earns its place; 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 read-only data-retrieval tool with strong annotations and full schema coverage, the description is nearly complete. It could have explained how 'since' and 'limit' affect each other or what happens without parameters, but it's sufficient for an agent to invoke correctly in most cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema documents both parameters ('limit' and 'since'). The description's mention of 'one-year percentile' and 'newest reading plus past boards' adds context that these parameters influence historical depth, providing modest added meaning. However, it doesn't explain how 'limit' and 'since' interplay, so there's room for more.
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 with VIX and other vol gauges, including a one-year percentile. It effectively distinguishes it from siblings like get_fx_board or get_rates_and_curve by being specific about the vol-gauge universe.
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 context—when you need a snapshot of vol gauges—but doesn't explicitly state when to choose this over alternative tools, such as get_fx_board. It's clear from context but lacks explicit exclusionary or comparative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_yield_closesOfficial 17:00 Treasury closesAOfficial 17:00 New York Treasury yield closes per session, as Helious recorded them.
| 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, and non-destructive behavior. The description adds minimal behavioral detail beyond mentioning the source ('as Helious recorded them') and 'per session', which hints at data organization but does not disclose error handling, pagination, or other operational aspects.
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 that front-loads the essential purpose and key details. It contains no redundant or extraneous information, making it efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description adequately conveys what data is returned (Treasury yield closes at 17:00 New York) and its source, which is sufficient for a simple read-only tool. It does not specify return format, but given the absence of an output schema and the straightforward nature of the operation, the description is reasonably 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 fully describes both parameters (limit, since) with clear descriptions, achieving 100% coverage. The tool description adds no additional parameter-level detail, so it remains at the baseline of 3.
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 retrieves official 17:00 New York Treasury yield closes per session, specifying the data type (yield closes), time (17:00), location (New York), and source (Helious). This distinguishes it from sibling tools like get_curve_history or get_rates_and_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 implies a specific use case (official closing yields) but does not explicitly state when to prefer this tool over alternatives. It lacks comparisons or usage guidance, though the purpose is clear enough for basic selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_seriesEconomic series Helious tracksAEvery 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.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
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
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!
