worldgdp.org GDP nowcasts

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

No annotations are provided, so the description carries the full disclosure burden. It does usefully disclose output content (coverage plus contributions in percentage points), which is valuable given there is no output schema, but it says nothing about data vintage/freshness, units beyond 'pp', or whether the call is a pure read.

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 and return content front-loaded and no wasted words. It is terse to the point of under-specification, but that is a completeness issue rather than a structural one.

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 tool with no output schema, the description gives a partial picture of the return payload, which helps. However it omits the meaning/format of 'quarter', the required aggregate semantics, and any indication of data currency, so an agent could still invoke it incorrectly.

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 only loosely gestures at the 'aggregate' parameter via 'World or regional' — it never mentions the required aggregate argument explicitly or the optional 'quarter' parameter. The enum values and quarter format are left undocumented in both the schema and prose.

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 (GDP nowcast) and scope (world or regional aggregates) plus what the result contains (coverage, per-economy contributions in pp). The verb is implicit in the name 'get_aggregate', but the domain is unambiguous and it is distinguishable from an economy-level nowcast tool.

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 guidance on when to choose this over the sibling get_nowcast, nor on required inputs or time-scope behavior. The word 'aggregate' implies the difference, but that inference is left entirely to the agent.

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

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

No annotations are provided, so the description carries the full burden. It does disclose the return contents well (nowcast headline, uncertainty range, release countdown, component contributions), which is meaningful behavioral context, but it says nothing about data freshness, update cadence, latency, or whether the nowcast can be absent for some economies.

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

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

A single front-loaded sentence that names the core output first (headline % SAAR) before the supporting detail. No filler, no repetition of the tool name.

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

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

With no output schema and no annotations, the description usefully enumerates what comes back, which is the main thing an agent needs to judge relevance. It is nearly complete for a read-only data-fetch tool, though it omits any note on update frequency or missing-data behavior.

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%, covering economy codes, the days path length, and the quarter default, so the schema does the heavy lifting. The description's mention of 'recent daily path' loosely maps to the days parameter but adds no format, unit, or default detail beyond the schema.

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

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

States a specific resource (GDP nowcast), scope (one economy), and enumerates the exact contents returned (headline % SAAR, 70% range, days to release, daily path, contributions, driver releases). The phrase 'for one economy' implicitly contrasts with the sibling get_aggregate, making it distinguishable without opening the schema.

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

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

Usage is implied rather than stated: an agent can infer this is the single-economy nowcast versus get_aggregate for aggregated views, but the description never says when to prefer it over get_track_record, get_release_calendar, or get_aggregate, and gives no prerequisites or exclusions.

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

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

No annotations are provided, so the description carries the full burden and delivers very little. It implies a read-only lookup via the 'get_' name and hints at returned fields ('expected dates'), but says nothing about permissions, pagination, rate limits, or whether the calendar can be empty.

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

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

A single front-loaded sentence with no filler; the resource and its key attribute are stated immediately. It is arguably too terse rather than padded, but every word earns its place.

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

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

For a simple two-optional-parameter read tool with no output schema this is only minimally adequate: the agent learns what the tool returns but not the default window, the economy-filter behavior, or what an empty result means. The gaps are small but real.

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% — the economy enum has 'Omit for all economies' but the days parameter has no description, only constraints (default 14, min 1, max 60). The description mentions neither parameter, so it does not compensate for the undocumented default lookahead window.

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

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

The description names a specific resource ('data releases') and its temporal scope ('upcoming ... with expected dates'), which is enough to distinguish it from get_nowcast, get_aggregate, and get_track_record. It falls short of a 5 because it never explicitly contrasts itself with any sibling or states the operation verb (list/retrieve).

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

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

There is no when-to-use guidance at all: no mention of the default 14-day window, no indication of when to filter by economy, and no routing to or away from siblings such as list_economies. The only context is the implied tie to 'nowcasts'.

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

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

No annotations are provided, so the description carries the full burden. It discloses the returned content (grades, hit rates, RMSE, model version history) but says nothing about permissions, cost, latency, or whether the backtest data is heavy to fetch. Content coverage is good; behavioral coverage is thin.

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

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

A single dense sentence with the headline ('Accuracy grade') front-loaded and no filler. The metric jargon is heavy but every clause names real returned data.

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

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

With no output schema and no annotations, the description does the work of enumerating the return contents (grades, hit rates, backtest errors, version history), which is enough to know what you get. It omits usage context, which is the main gap.

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

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

Schema description coverage is 0% for the single 'economy' parameter, and the description only alludes to it via 'an economy's nowcast' without clarifying accepted values or format. The enum in the schema does the real work; the description adds almost no parameter meaning.

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

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

States a specific resource (an economy's nowcast track record vs official GDP) with concrete content: accuracy grade, model version history, backtest errors. This is clearly distinct from get_nowcast, but it does not explicitly name or contrast with its siblings, so it stops short of 5.

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

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

The description never says when to reach for this versus get_nowcast, get_aggregate, or get_release_calendar. Usage is only inferable from the content listed; no conditions or exclusions are given.

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

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

With no annotations, the description bears the full behavioral burden; it does disclose what each listed row carries (current-quarter GDP nowcast as % q/q SAAR, plus share of world GDP), which signals a read-only enumerating operation. It says nothing about ordering, completeness of the economy universe, or pagination, which are the traits an agent would still want.

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 front-loaded sentence with the resource first and the returned metrics second; no filler or hedging. Nothing could be removed without losing information.

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

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

No output schema exists, so the description must convey the return shape; it names two of the fields but not the identity fields (economy names/codes) or the structure of the aggregates. Adequate but thin for a listing endpoint whose return payload defines its usefulness.

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

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

The tool takes zero parameters, so the schema carries no parameter meaning to add to; baseline 4 applies. The description correctly implies no filtering is possible.

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 ('List') and resource ('modelled economies and aggregates') and even names the returned metrics (nowcast, share of world GDP). It does not, however, draw a boundary against siblings get_aggregate and get_nowcast, which clearly overlap in subject matter.

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 guidance on when to prefer this directory-style call over get_nowcast or get_aggregate, and no prerequisites or exclusions are stated. The agent must infer usage from the name alone.

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