fxapi Exchange Rates MCP Server

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

Annotations contain only a title, so the description carries the behavioral burden, and it does substantial work: the 1830-day maximum span, how the first and last partial periods are cut, and how daily rates are converted to base_currency before averaging. It stops short of explicitly declaring read-only behavior, error conditions, 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 definition is front-loaded with the core computation, then the accounting rationale, then constraints; no sentence is filler. Two compact paragraphs cover method, purpose, and edge-case behavior 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 7-parameter tool with no output schema, the description explains the averaging model, the currency conversion order, and the partial-period rule, and it names date_from/date_to/days as the fields that describe each period. It could say more about the response shape per currency, but the essentials an agent needs before calling are present.

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 already 100%, so 3 is the baseline, but the description goes further by explaining that period groups days into month/quarter/year/total and by giving a worked example of base_currency averaging (mean of daily EUR/GBP rates). The date_from/date_to span limit adds meaning beyond the schema's format strings.

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: averages daily rates per calendar month/quarter/year/total and reports each period's low and high. The computation is described precisely enough to distinguish it from getLatest or getHistorical, but no sibling is named explicitly, so the differentiation is implicit rather than stated.

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 IFRS/US GAAP sentence supplies a real use context (translating income and expenses), so the agent can infer when averaging is appropriate. However, it never names an alternative such as getHistorical for daily rates or getOhlc for open/close values, and gives no 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?

With only a title annotation, the description carries the burden well: it states the plan prerequisite ('Requires a plan that includes the convert endpoint'), the intraday-plan requirement and resulting 403/422 behavior, the request cost of batch mode, and the incompatibility of rounding/locale with `shape=compact`. It does not explicitly confirm the operation is side-effect free, but for a conversion tool this is largely self-evident.

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 and the plan requirement, then organized into one paragraph per concern (batch, intraday, shop-price rounding/formatting). Dense but every sentence carries information; minor redundancy since some details also appear in the schema descriptions.

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 14-parameter tool with no output schema and no annotations, the description covers the important interactions: value/values exclusivity, date vs datetime, shape=compact exclusions, and the extra response fields produced by rounding and locale. It stops short of a full response-shape description, but the added-field conventions (`rounded`, `formatted`, `meta.values`) go a long way.

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 baseline is 3, but the description adds genuine value beyond the schema: the mutual exclusion of `value` and `values`, the one-request cost of batch conversion, the response reshaping (`data` as a list, `meta.values` replacing `meta.value`), and the fact that `rounded`/`formatted` are added fields while `value` stays exact. These are cross-parameter interactions the schema does not express.

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 ('Converts a value from the base currency into all (or a filtered set of) currencies') plus the time dimension (today or historical date). An agent can immediately tell this is a value-conversion tool, distinct from rate-lookup siblings like getLatest or getRate.

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 clear conditions for parameter choices ('Send `values` instead of `value` to convert up to 100 amounts') and notes `datetime` behaves 'like /v1/rate', which hints at the sibling relationship. However, it never explicitly says when to use getConvert versus getRate, getLatest, or getHistorical, so routing between siblings is left to inference.

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 contain only a title, so the description carries the full disclosure burden. 'Returns metadata' implies a safe read, but it never mentions that as_html flips the response into an HTML table rather than JSON, nor any auth or rate-limit behavior — a material output-shape surprise left undisclosed.

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 zero filler: the return value comes first and the optional filtering qualifier second. Nothing could be trimmed 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 and a rich input schema, the description is adequate for a simple read tool but omits the HTML response mode that changes the return type entirely, and gives no signal about the sibling tools it replaces in a conversion workflow.

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 all three parameters are already documented, including the enum values and the comma-separated array form. The description restates the code/type filtering but adds nothing on syntax or defaults, 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 ('Returns metadata for all supported currencies') and adds scope ('all supported'). The resource is distinct from the rate-oriented siblings (getLatest, getConvert, getRate), so an agent can separate it without opening the schema, though no sibling is named explicitly.

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 'optionally filtered by code or type' implies when to pass filters, but there is no explicit guidance on when to call this versus the rate tools, no prerequisites, and no note that omitting filters returns the full catalogue (that detail lives only in the schema).

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 only a title annotation, the description carries real disclosure value: end-of-day semantics, valid date window, and the precise condition under which `high`/`low`/`average` come back null (>1830 day span or no data). It does not cover error behavior, default currency set, or throttling, so it falls short of fully self-sufficient.

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 short paragraphs, front-loaded with the returned values, then constraints and response-shape caveats. Every sentence is doing work; only 'The CSV keeps its columns' is terse to the point of being cryptic.

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?

Six parameters, no output schema and no behavioral annotations, so the description must explain returns — and it does at a conceptual level (per-currency end rates, absolute and percent change, plus high/low/average aggregates with their null rule). It stops short of giving field names or the exact JSON/CSV shape, which an agent composing a downstream parse would still want.

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 baseline is 3, but the description genuinely adds semantics the schema lacks: the values are taken at the *close* of each date, both are UTC days, and the span cap of 1830 days governs the aggregate fields. It adds nothing about `type`, `format` or `base_currency`, which the schema already documents thoroughly.

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 first sentence names a specific verb-and-result ('Returns ... its rate at the end of `date_from` and of `date_to` and how much it changed ... in absolute terms and in percent'), which is materially different from siblings like getLatest or getHistorical. It never explicitly contrasts itself with nearby tools such as getRange or getAverage, so an agent must infer the boundary.

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 implicit: the description supplies hard constraints (UTC days back to 1999-01-01, newest allowed is yesterday, date_to on or after date_from) but never says when to pick this over getRange, getHistorical or getAverage. There are no exclusions or alternative-routing sentences.

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 carry only a title, so the description does the work: it discloses the 1999 data floor, the one-day-past constraint, that multi-date responses are keyed by date, that results are returned oldest first, and that each date costs one request (visible via X-Cost). Auth requirements and error behavior are not covered, keeping it below 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?

Two tight paragraphs with the core purpose front-loaded and the multi-date/cost caveat immediately after. The parenthetical '(see X-Cost)' and the /v1/latest cross-reference are efficient pointers rather than padding, though the second sentence is dense enough to require a re-read.

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 9-parameter, zero-required tool with no output schema, the description covers the essential call-shaping concerns: which date parameter to use, how the response is structured in each mode, and the cost implication. It stops short of describing the single-date response envelope (base currency, date key, rates map), which an agent without an output schema might want.

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

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

Schema description coverage is 100%, so the baseline is 3, and the description goes beyond it by explaining the response-shape consequence of using `dates` (data keyed by date), the per-date billing cost, and by pointing at `/v1/latest` for the shared shape/precision/inverse/format=csv semantics instead of re-documenting them. The mutual exclusivity of `date`/`dates` is repeated from the schema but the added behavioral framing is genuinely new information.

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 first sentence gives a specific verb and resource (returns exchange rates) plus a scope (a specific date), and the second sentence adds the coverage window back to 1999. It does not, however, distinguish itself from the many sibling time-series tools (getRange, getOhlc, getAverage, getFluctuation), so an agent must still infer the boundary cases.

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?

Useful constraints are stated: the date must be at least one day in the past, and `dates` should be sent instead of `date` for up to 31 days in one call. But the guidance is about parameter choice within the tool, not when to pick this tool over siblings like getRange or getLatest; the only sibling reference is '/v1/latest' for shared optional representations, which is about output format rather than tool selection.

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 carry only a title, so the description bears the behavioral burden. It usefully discloses that the update interval depends on the subscription plan (daily to minutely), but says nothing about authentication, rate limits, or that the operation is read-only beyond the verb 'Returns'.

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 tight paragraphs: the purpose and update-interval caveat come first, then an options summary. The second paragraph is dense but each clause maps to a real parameter, so little 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 eight optional parameters and no output schema, the description does not explain the response envelope (e.g., rates map, meta timestamps) that an agent would need to interpret results. The per-option explanations partially compensate, but the return structure is left 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 description coverage is 100%, so the schema already documents all eight parameters thoroughly. The description adds a compact narrative of shape, precision, inverse, include, and format but no syntax or constraints beyond what the schema provides, and it omits type and currencies entirely — 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?

The description states a specific verb and resource — 'Returns the latest exchange rates' — and names the base-currency scope plus the subscription-dependent update interval. It implicitly distinguishes itself from getHistorical and getRate via 'latest', but never explicitly differentiates against the ten 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?

Usage is only implied through the word 'latest' and the default USD behavior. There is no explicit guidance on when to pick this over getRate, getHistorical, or getConvert, and no prerequisites or exclusions stated.

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?

Only a title is provided as annotation, so the description carries the burden and does well: it discloses the matrix return shape (`data.EUR.USD` = price of 1 EUR in USD), that data is latest at the plan's update interval or a past-date close, and that formats produce different table shapes. It does not mention rate limits, error behavior for invalid codes, or response envelope details beyond the example.

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 tight sentences, front-loaded with the core purpose and followed by the return-shape example and format nuance. No filler, though the csv detail slightly overlaps what the schema already says.

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 matrix return shape and date/format behavior for a 4-parameter read tool. Minor gaps remain around error handling and envelope structure, but an agent has enough to invoke it correctly.

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 every parameter is well documented in the schema (date format, format enum behavior, precision range, currency list). The description adds little parameter meaning beyond reiterating the 2-25 currency bound and the csv row-per-base-currency behavior, 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: returns every cross rate between 2 to 25 currencies in one request, and explains the matrix orientation with `data.EUR.USD`. It is clearly a bulk cross-rate tool rather than a single-pair tool, though it never names the sibling tools (getRate, getConvert, getLatest) it should be chosen over.

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 implies when to use the tool ('Latest at your plan's update interval, or the close of a past `date`') and its 2-25 currency scope, which implicitly separates it from a single-pair lookup. However there is no explicit guidance on when to prefer this over getRate, getConvert, or getLatest, leaving the routing inference up 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?

Annotations carry only a title, so the description bears the full burden and does so: it explains how candles are constructed (open = prior close, high/low include open and close, gaps handled), that unfinished candles are omitted, and that the whole request costs one request regardless of currency/candle count. The plan-tier gating is disclosed up front rather than surfacing as an error.

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 plan gate, then bulleted interval constraints, then candle semantics, then output shapes — a sensible ordering. It is on the long side and the CSV/compact restatement partially duplicates the schema's own parameter descriptions, but every section carries information an agent needs.

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 8 parameters, plan-tier gating, and no output schema, the description fills the gap: it covers lookback limits, default interval, candle construction edge cases, omission of in-progress candles, request costing, and the exact return representations for default, compact and CSV.

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 baseline is 3, but the description adds real meaning: it tells the agent which finer rate series each interval is built from, that `day` is the default, that `datetime` is the candle start and `datetime_end` selects the candle it falls in, and it spells out the exact compact/CSV payload layouts including column order.

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?

Opens with a specific verb and resource: 'Returns open, high, low and close per hour or per day for 1 to 10 currencies, built from the stored rates.' That is clearly distinguishable from siblings like getHistorical, getRange or getFluctuation, which return different shapes of rate 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?

It gives concrete selection criteria between the two modes (hour needs 7-day windows and quarter-hourly plan; day needs 3-month/92-day windows and hourly plan) plus the plan requirement for the range endpoint, so the agent knows when the call will succeed. It stops short of naming sibling tools or stating when to prefer them (e.g. getHistorical for tick-level data), so it falls short of a 5.

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 only a title annotation, the description carries the full burden and does so well: it discloses subscription gating, hard span/look-back limits per accuracy, the special end-of-period behavior for `week`/`month`, and the shape of returned data. It stops short of describing error behavior when limits are exceeded or any rate limits, which is the remaining 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?

Purpose and dependency are front-loaded, then the accuracy limits are presented as a compact, scannable list where every bullet carries information an agent needs. The closing paragraph on orient/shape/precision leans on material the schema already states, so it is slightly redundant 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?

For a 10-parameter tool with no output schema, the description covers what an agent actually needs: required plan tier, legal value combinations of dates and accuracy, and what the response looks like in JSON, CSV, and currency-oriented forms. Nothing essential to a correct call is left unstated.

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 baseline is 3. The description does add genuine meaning for `accuracy` by attaching concrete span constraints that the schema's one-line entry lacks, and it restates the interactions among `format`, `orient`, `shape`, and `precision` — but those restatements largely duplicate the schema rather than extend it.

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 opens with a specific verb and resource ('Returns exchange rates for every interval between `datetime_start` and `datetime_end`'), which immediately separates it from point-in-time siblings like getLatest or getRate. It does not, however, differentiate itself from getHistorical, which plausibly also returns past rates, so an agent must still infer the boundary from the name alone.

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 per-accuracy span and look-back table is essentially a decision guide: it tells the agent when each `accuracy` value is legal, and the plan requirement ('medium and up') flags a precondition before calling. What is missing is any explicit statement of when to prefer this tool over getHistorical, getAverage, or getOhlc.

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 carry only a title, so the description does the heavy lifting and succeeds on several points: freshness is tied to the plan's update interval, intraday resolution is quantified (minutes for 7 days, hours for 3 months), and `format=text` is disclosed as emitting a bare number. It omits error behavior and any indication of what the rate's own timestamp looks like beyond the csv column list.

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-loads the core contract (one pair, one number, both directions) before the temporal modes. The spreadsheet formula example is longer than strictly necessary and repeats the endpoint URL a second time, but it is genuinely practical and clearly delimited.

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 six parameters, no output schema and only a title annotation, the description covers the essentials: return shape, freshness semantics, and temporal resolution limits. It could be stronger by stating what happens for unavailable pairs or historical dates outside plan coverage.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds real value for `datetime` by naming the interval it resolves to and the retention windows, but leaves `precision`, `format` details and the date/datetime exclusivity to 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 verb and resource ('Returns the rate of one pair as a single number') and clarifies directionality ('how many units of `to` one unit of `from` buys, and the inverse'). It does not explicitly distinguish itself from look-alike siblings such as getLatest, getConvert or getHistorical, which matters given that this tool subsumes latest/date/datetime modes.

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 selection logic among its own modes: latest by default, the close of a past `date`, or an intraday `datetime` within a stated window. It also flags the plan prerequisite ('`datetime` needs a plan with intraday updates'). It never names a sibling tool as the alternative for cases this tool does not cover, so the guidance stops short of full 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?

Annotations carry only a title, so the description does real work: it discloses that the call is quota- and rate-limit-exempt, which is a non-obvious behavioral trait an agent needs before deciding to poll it. It also names what comes back (usage figures, plan), though it stops short of format or reset-window details.

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, no filler. The return content is front-loaded and the exemption note follows as supporting detail, so an agent gets the essential fact first.

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-param tool with no output schema, the description covers what is returned at a useful level of abstraction (quota usage, grace quota, plan). It lacks any note on units, reset periods, or shape of the response, which is the only remaining 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?

Zero parameters, so there is nothing for the description to disambiguate; baseline 4 applies. Nothing in the description conflicts with the empty 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 verb and resource: returns current monthly and grace quota usage plus the account's plan. It is unambiguous and, given the all-currency siblings, an agent can immediately tell this is the only account-level tool in the set.

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 — an agent infers it should call this to check remaining quota or plan tier. There is no explicit when-to-use framing or named alternative, though the absence of any comparable sibling makes the routing decision trivial in practice.

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