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

Annotations only declare readOnlyHint and openWorldHint; the description goes substantially further by defining the three evidence labels and what each means epistemically, stating sort order (newest first), disclosing that exact-pair route launches are split into a separate announced_routes field, naming the geographic coverage, and noting the call is free. That is meaningful behavioral context an agent cannot get from the annotations alone.

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

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

The core purpose and the region/coverage scope are front-loaded, and the evidence-label taxonomy is compactly expressed. The single dense paragraph is long but nearly every clause carries information; a short bulleted split of the three labels would have improved scannability slightly.

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 does the work of explaining what each returned event contains (source link, evidence label) and that route launches arrive in a separate announced_routes collection, and it discloses ordering and cost. What is missing is a sense of result size/pagination behavior beyond the limit parameter, which would matter for an agent planning follow-up calls.

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 defines days, kind, pair, limit and currency including ranges and defaults. The description adds only marginal semantic value beyond that, most notably the clarification that a pair matches either currency or the exact corridor, plus the ordering guarantee relevant to limit; otherwise it defers 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 resource (dated corridor news) and precise scope (a currency pair or a single currency), then enumerates the event taxonomy: route launches/exits, licence grants/revocations, central-bank rule changes, devaluations, limit changes, outages. This clearly separates it from rate- or cost-oriented siblings like get_corridor_rates, price_routes and swapeazi_corridor_registry.

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 news/event feed rather than the pricing or routing tools, and the note that exact-pair route launches appear separately as announced_routes and 'never as payment options' steers interpretation of results. However, no sibling is named as an alternative and there is no explicit 'use this when...' or 'do not use for...' guidance.

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