MacroDataAPI

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

Annotations declare readOnlyHint=false and idempotentHint=false, but the description adds the most important behavior an agent needs: the key is 'Returned once', so it must be captured immediately and cannot be re-fetched. Naming the required X-API-Key header is also actionable context beyond the annotations; rate limits or how the email is used go unstated.

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

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

Two sentences, the one-time-return constraint and the header requirement each earning their place, with the value proposition front-loaded. No filler.

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

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

For a single-parameter tool with no output schema, the description covers what is produced (a key), how it is delivered (once), and how to use it (X-API-Key header). Only privacy/purpose-of-email and any issuance limits are left implicit.

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

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

Schema description coverage is 100% and the sole parameter's schema text already explains whose email to supply ('your human's real email, else your own agent mailbox'). The description adds nothing about the email parameter itself, so the baseline 3 applies.

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

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

States a specific verb and resource ('Create a ... API key') plus the crucial qualifier 'FREE ... (no signup)', which no sibling tool offers. It doesn't explicitly contrast itself with the read-only macro_* siblings, but the create-vs-read distinction 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?

'no signup' and 'add it to the server's X-API-Key header' clearly frame the situation in which this tool is the right entry point for the otherwise-keyed macro_* tools. It stops short of explicitly saying 'call this first if you have no key' or naming prerequisites/exclusions.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds useful behavioral context by disclosing that no API key is needed and by indicating the kind of content returned: offers, prices, and first calls.

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 with no wasted words. It front-loads the core purpose and appends the important auth constraint.

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, read-only discovery tool with annotations already covering safety, the description gives enough context to invoke it correctly. It could be slightly more explicit about the return content, but no output schema exists and the description adequately describes what the agent will get.

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?

This tool takes no parameters, so there are no parameter semantics to explain. The baseline for zero parameters 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?

The description clearly states that this tool provides server capabilities, prices, and first-call guidance. It is specific enough to distinguish a discovery/onboarding tool from the macro-data siblings, though it does not explicitly name an alternative or state the return shape.

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

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

The phrase 'the first calls to make' and 'No key needed' signal that this is an onboarding/discovery tool to use before authenticated calls. It gives clear context for use but does not explicitly say when not to use it or name alternatives.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds one useful behavioral fact — that each entry includes the series it updates — but says nothing about ordering, limits, or how publisher filtering changes the result.

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 compact sentence with the scope front-loaded and no filler. It is efficient, though the brevity comes at the cost of the missing publisher and usage context.

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

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

For a two-parameter read-only tool with annotations covering safety and no output schema, the description is roughly adequate: it says what is returned at a high level. It falls short on the optional publisher filter and on how the tool relates to its sibling release/history tools.

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

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

Schema description coverage is 0%, so the description must carry parameter meaning. 'Next N days' does explain the days parameter, but the publisher parameter (optional, defaults to null) is never mentioned, and the 1-90 range and defaults are left entirely to the raw schema titles.

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

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

The description names a specific resource ('scheduled data releases') and its scope ('the next N days'), which an agent can immediately map to a forward-looking economic calendar. It does not, however, explicitly distinguish itself from sibling macro_latest_releases or macro_latest, leaving the forward-vs-actual distinction for the agent to infer.

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

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

There is no statement of when to use this tool versus macro_latest_releases or macro_history, no exclusions, and no prerequisites. The forward-looking calendar intent is only implied by the phrase 'next N days'.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds useful context about Pro access and point-in-time semantics via as_of, but it does not disclose return format, pagination, or rate-limit behavior.

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

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

The description is two short sentences with the core purpose front-loaded and no wasted text. It is appropriately sized for a simple history 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?

The core operation and point-in-time behavior are clear, and annotations cover read-only/closed-world safety. However, with no output schema and only partial parameter documentation, the description leaves gaps around return values, pagination, and how start and limit interact.

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

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

Schema coverage is only 50%, and the description only adds point-in-time meaning for as_of, largely overlapping the schema description. It does not clarify start semantics or the limit parameter, which has no schema description at all.

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 and operation as retrieving series history, and adds the Pro qualifier. It does not explicitly distinguish this from siblings like macro_latest or macro_vintages, so it is clear but lacks sibling differentiation.

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 what as_of does but does not say when to use this tool instead of alternatives such as macro_latest, macro_vintages, or macro_search_series. There is no explicit when-to-use or when-not-to-use guidance.

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

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

Annotations already declare this is a read-only, non-open-world operation, so the safety profile is covered. The description adds useful output context by enumerating the fields returned (previous value, changes, release time, next release), but it does not describe authentication needs, error behavior, or rate limits.

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

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

The description is a single tightly packed sentence with zero filler. It front-loads the core resource and then lists the returned data fields, making it easy to scan.

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 one-parameter read-only tool, the description is almost complete: it identifies the resource, names the required input indirectly, and enumerates return contents even though there is no output schema. It stops short of explaining how to discover valid series IDs or what happens on invalid input, which keeps it from a 5.

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

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

Schema description coverage is 100%, and the single parameter series_id already includes concrete examples. The description only implies that a series identifier is required via 'of a series' and adds no syntax, format, or validation detail beyond the schema. 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 resource and scope: the latest print for a single series, including previous value, changes, release timing, and next release. It is distinguishable from macro_history by the word 'latest', but it does not explicitly name or differentiate itself from close siblings like macro_latest_releases.

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 when the latest observation for one series is needed, but it gives no explicit guidance on when to choose this over macro_latest_releases, macro_history, or macro_search_series. There are no stated exclusions, prerequisites, or alternative-routing instructions.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds that results include headline values, but it does not explain ordering, freshness, limit behavior, or what 'observed' releases means.

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 definition is a single short sentence with no wasted text, and the key scope is front-loaded. It is perhaps too sparse for the tool's role, but it is not verbose.

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

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

There is no output schema, so the description should carry more of the burden for explaining return structure and behavior. It mentions 'headline values' but does not say how releases are ordered, whether one or many series are returned, or what limit controls.

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

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

Schema description coverage is 0% and the description does not mention the single limit parameter at all. The parameter name and schema constraints make its meaning partly inferable, but the description adds no semantic context for how limit affects the returned releases.

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 resource and scope: most recent releases, with headline values. It is clear enough to tell the tool is a read/list operation over recent macro releases, but it lacks an explicit verb and does not distinguish itself from close siblings like macro_latest or macro_history.

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 guidance on when to use this tool versus alternatives such as macro_latest, macro_history, or macro_vintages. The phrase 'most recent' weakly implies a recency use case, but no alternatives or exclusions are named.

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

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

The readOnlyHint and openWorldHint=false annotations already establish this as a safe, closed-domain read, so the description only needs additive context. It does add what the response contains (current rate, last decision date, next meeting), which is valuable given there is no output schema, but says nothing about freshness, rate limits, or coverage of banks/meetings.

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 ten-word sentence that front-loads the resource and then the payload, with zero filler. It is perhaps overly terse given the two parameters, but nothing is wasted.

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

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

With no output schema, the description usefully sketches the return shape, and the annotations cover the safety profile. It remains incomplete for a two-parameter tool: the history parameter's meaning and the multi-bank behavior are left entirely to schema inference, which the agent cannot fully do since history is undocumented.

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

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

Schema coverage is only 50%: the bank parameter is documented in the schema with allowed values and an omit-for-all default, but the history parameter (integer 0-50, default 0) has no description anywhere. The tool description never mentions either parameter, so it does not compensate for the gap — in particular, an agent cannot tell that history requests past decisions.

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

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

The description names a specific resource (policy rates) and enumerates the returned fields (last decision date, next meeting), which separates it from snapshot siblings like macro_latest and macro_yield_curve. It does not explicitly name or contrast those siblings, so it stops short of a 5.

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

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

"Current" implies a snapshot use case and the schema notes bank can be omitted for all, so the intended usage is inferable. However, there is no explicit when-to-use statement and no alternative tool (e.g., macro_yield_curve for curve data, macro_history for series depth) is referenced.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds value by enumerating the returned fields, which the agent would otherwise have no way to know since there is no output schema. It omits result-count limits or pagination behavior, keeping it short of a 5.

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

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

A single sentence, front-loaded with the action and the resource, then the returned fields. Zero filler and nothing buried.

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 four optional filters all documented in the schema, this is nearly sufficient, and the description compensates for the missing output schema by naming the returned fields. The remaining gap is routing guidance versus macro_history/macro_latest/macro_calendar.

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%: each of the four optional filters has an example or allowed-value list in the schema. The description mentions no parameters at all, so it adds nothing beyond the schema, which is the baseline-3 case.

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

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

States a specific verb ("Search") and resource ("the series catalog") plus the fields returned (ids, units, frequency, latest period, next release). That distinguishes it from data-fetching siblings like macro_history and macro_latest, though it never explicitly frames itself as the discovery step before those calls.

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

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

Usage is only implied: searching a catalog suggests you run this to find series ids before pulling data elsewhere. There is no explicit when-to-use, no when-not-to-use, and no named alternative among the nine siblings.

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

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

Annotations already establish readOnlyHint=true and openWorldHint=false. The description adds useful context that this is a Pro feature and that results include both initial and revised values with vintage dates, but it does not explain entitlement failures, ordering, 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?

The description is a single front-loaded sentence with no wasted words. It communicates the core value and scope immediately.

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

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

For a two-parameter read-only tool without an output schema, the description is mostly complete: it names the input concept and describes the returned revisions with vintage dates. Minor gaps remain around result ordering and error cases for non-Pro access.

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 50%: period has an example format, while series_id has no schema description. The description clarifies the conceptual roles of series_id and period by saying 'one period of a series', but it does not add format or identifier details 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 states the resource and scope: every revision of one period of a series, including initial print and later vintage values. It is specific enough to distinguish this from a simple latest/history lookup, though it does not explicitly name sibling 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 phrase 'one period of a series' implies the tool is for vintage/revision retrieval, but there is no explicit guidance on when to choose this over macro_history or macro_latest, nor any stated exclusions or prerequisites beyond the '(Pro)' marker.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds genuine value by disclosing the payload shape (previous session, change per tenor, 2s10s spread), which matters since no output schema exists. It says nothing about defaults, data source, or what happens when 'country' is unsupported and 'history' is non-zero.

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 tightly packed sentence with the most important content (what the curve contains) front-loaded and zero filler. It is a fragment rather than a sentence, but nothing is wasted.

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

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

With no output schema, the description competently covers the return payload, which is the main gap it needed to fill. However, for a 3-parameter tool with a wide-range 'history' argument and a country selector, leaving all parameter behavior unexplained means an agent cannot confidently configure a call.

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

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

Schema coverage is only 33%: 'date' has a format hint, but 'country' (default 'us') and especially 'history' (0-250) are undocumented in both schema and description. The most consequential open question — whether 'history' returns N days of curves — is left entirely unaddressed despite being the obvious intent.

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

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

Names a specific resource (daily par yield curve) and enumerates what it returns: previous session values, per-tenor change, and the 2s10s spread. That distinguishes it from macro_policy_rates and macro_latest_releases in domain terms, though it never explicitly routes against those siblings.

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

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

There is no statement of when to use this versus macro_policy_rates, macro_history, or macro_latest, and no prerequisites or exclusions. The agent must infer from the name alone that this is the curve-specific source.

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