UK Data: Federal Reserve decisions

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

Annotations already declare readOnly, idempotent, non-destructive and openWorld, so the safety profile is covered. The description does add real behavior beyond them: reverse-chronological ordering, per-item type labels, titles-and-links-only (no full text), and a 1-credit cost. It does not say how far back 'recent items' reaches or whether a limit cap truncates silently.

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

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

Front-loaded with the resource and content types, and the return-shape sentence earns its place by telling the agent no full text comes back. The audience sentence ('For news and briefing agents...') and the trailing parenthetical cost note are slightly padded but not wasteful.

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 correctly does the work of describing the return: titles, dates, type labels, links, newest first. The remaining gap is the undefined 'recent items' window, which matters because the caller cannot otherwise tell how far back the feed goes before needing since.

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

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

Schema description coverage is 100%, so both limit (1-100, default 10) and since (YYYY-MM-DD) are already documented; that sets the baseline at 3. The description adds only the ordering ('newest first') and implies date scoping, without clarifying how limit and since interact or whether since changes the default 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?

Uses a specific verb and resource: it lists the Board's monetary policy press releases and enumerates the covered content types (FOMC statements, minutes, projections, discount rate minutes). It implicitly separates itself from news_search by framing the output as the official list, but it never names a sibling — notably fomc_minutes_latest, which overlaps on minutes.

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?

'For news and briefing agents that need the official list rather than news coverage' gives an implied audience and a soft contrast with a news source, but it never states when to prefer the dedicated fomc_minutes_latest or fomc_meeting_dates tools over this one. Usage must be inferred from the caller's own context.

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

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

Annotations already declare read-only, idempotent, non-destructive and open-world, so the safety profile is covered. On top of that the description discloses provenance (New York Fed), cost (1 credit), the exact dimensions/breakdown of the returned data, and interpretive context for the headline figure — genuinely additive rather than restated annotation.

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

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

Front-loaded with what the tool returns, then scope exclusions, then interpretation, then cost — every clause carries information. Despite being a fairly dense sentence chain there is no filler and nothing repeated from the schema or annotations.

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

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

No output schema exists, but the description compensates by enumerating the result fields (submitted/accepted amounts, collateral split, offering rate) and the source. For a single-optional-parameter read tool with full annotations, nothing an agent needs before calling is missing.

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

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

Schema description coverage is 100%, so the single parameter (last_n, 1-50, default 5) is already fully documented in structured data. The description adds no further constraint or semantics for it, so the baseline 3 applies.

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

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

Names a specific resource (Fed Standing Repo Facility operations results) and states exactly what the payload contains: submitted vs. accepted amounts, split by collateral type, with the offering rate. It also explicitly carves out what it is not (forward schedule, reverse repo), so an agent can distinguish it from adjacent tools at a glance.

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

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

Gives a real when-to-use signal — 'take-up is the headline sign of month- and quarter-end funding stress' — and explicit when-not-to-use exclusions for the forward schedule and reverse repo. It stops short of naming the sibling tools, so the agent must map 'its own tool' to a concrete name itself.

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

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

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the description's added value is in the operational constraints it discloses: the feed source, the recent-items-only window, the absence of transcript text, and the 1-credit cost. It doesn't specify how 'recent' is bounded or whether results are paginated, which keeps it off 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?

Front-loaded with the core purpose, then a compact field list, then scoping caveats and cost. 'Tracks Fedspeak at its source' is light marketing flavor that adds little, though it does hint at provenance; otherwise every clause carries 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?

With no output schema, the description usefully enumerates return fields and discloses the credit cost, source feed, and scope limits. Remaining gaps are the recency window definition and result-volume behavior, which are relevant for a 'latest'-style feed with up to 100 results.

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

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

Schema description coverage is 100%, with the speaker parameter already documented as a surname example (Waller) and limit documented as 1-100 default 10. The description confirms speaker filtering is optional and by surname, but adds no new meaning and never mentions the limit parameter beyond the schema, so baseline 3 applies.

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

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

States a specific verb and resource ('Latest speeches by Federal Reserve Board members ... from the Board's speeches feed') and enumerates the returned fields (speaker, title, date, venue, link). The scope qualifier 'Board members only (not Reserve Bank presidents)' separates it cleanly from related Fed tools like fomc_minutes_latest or fed_monetary_policy_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?

Explicit exclusions are given ('Board members only', 'recent items only', 'no transcript text'), which tells the agent when this tool is NOT appropriate. What is missing is a named alternative for those excluded cases (e.g., where to go for Reserve Bank president speeches or full transcripts), so routing is implied rather than explicit.

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 read-only, idempotent, non-destructive behavior, so the bar is lower; the description still adds real context by naming the data source, the year window served, the flags applied to results, and a 1-credit cost. It does not describe result ordering or exact field shape, but that is minor given the annotation coverage.

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

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

Front-loaded with purpose and scope, then coverage limits and cost. The audience sentence ('For traders, journalists and planners scheduling around Fed days') is the weakest line and could be cut, but the rest is dense and earns its space.

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 one-parameter read tool with no output schema, the description supplies source, scope, result flags, coverage limits and cost — everything needed to call it correctly. Only the precise return structure (e.g., whether dates come as a flat list or per-meeting records) is 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 coverage is 100% and the single optional year parameter is documented with a default, so baseline would be 3. The description adds meaning beyond the schema by constraining the acceptable values to the years the calendar page actually lists (recent and next year), warning the agent off older years.

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: FOMC meeting dates for a given year, pulled from the Board's official calendar page. It also names what is annotated in the result (SEP/dot-plot meetings, notation votes, tentative dates), which separates it cleanly from siblings like fomc_minutes_latest or fed_monetary_policy_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?

Gives clear coverage boundaries: the calendar page lists only recent and next year, and older years live on the Board's historical pages, so an agent knows when this tool will not serve the request. It states an audience (traders, journalists, planners) rather than naming the sibling tools to use instead, so it stops short of explicit alternative routing.

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

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

With annotations present, the bar is lower, and the description still contributes real context: it discloses the return shape ('the link, not a summary'), the coverage limitation ('only covers releases still in the feed' – so stale meetings vanish), and the credit cost. It does not say what happens when a requested meeting is no longer in the feed, which is the one notable gap.

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

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

Three short sentences, front-loaded with what the tool returns, then the use case, then the caveat and cost. Nothing is redundant; the parenthetical cost note is compact and 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 single-optional-parameter read tool with no output schema, the description carries the return-value burden well (link, meeting, release date) and flags the feed-coverage limit. Only the empty/absent-meeting behavior is left unspecified, which is a minor omission for a tool this simple.

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?

Annotations (readOnly, idempotent, openWorld, not destructive) already establish the safety profile, and the description adds genuinely useful behavior: link-only return, feed-limited coverage, and a 1-credit cost. Schema coverage is 100% and the single optional 'meeting' parameter with its YYYY-MM format and latest-default is fully documented there, so the description adds little about parameters beyond confirming that the latest is the default 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?

Specific verb and resource: it names the feed (the Board's monetary policy feed), the payload (meeting covered, release date, link), and explicitly draws a boundary by saying it 'Returns the link, not a summary of the minutes.' It stops short of naming the sibling it is not (e.g. fed_monetary_policy_releases for older releases or fomc_meeting_dates for the calendar), so differentiation is only partial.

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

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

Gives a real usage scenario ('are the Fed minutes out?' three weeks after each meeting) and a scope limit ('only covers releases still in the feed'), which implies when to reach elsewhere. It never explicitly says what to use for historical minutes or for the meeting calendar, so the guidance is implied rather than stated.

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