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

Annotations already declare readOnlyHint=true and openWorldHint=true, covering the safety profile and external-data nature. The description adds genuinely useful context beyond that: the return payload contents (holiday name, local+UTC hours, half days, lunch breaks, pre/after-market, live status, next open/close, adjacent trading days), error handling (HTTP 400 on bad input, no charge), and pricing (0.002 USDC per successful call via x402). What it omits is data freshness/latency and whether calendars are cached, which matters for a live-status tool.

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 trigger condition, then coverage, then return contents, then error/pricing terms — a logical order with no filler sentences. It is dense to the point of being a run-on list, but every clause 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 no output schema, the description compensates by enumerating the response fields an agent will receive, and it adds the pricing and error-handling contract that annotations do not cover. For a two-parameter read-only lookup tool, nothing material 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%, with both parameters fully documented (YYYY-MM-DD format with today-in-exchange-timezone default, MIC codes plus common-name fallback and the free exchange list endpoint), so the schema already does the heavy lifting. The description reinforces exchange breadth and the 'official calendars only' constraint but adds no syntax or format detail beyond what the schema provides.

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+resource: determines whether a stock exchange trades on a given day, with a default of today. It also names the exchange coverage (28 exchanges incl. NYSE, Nasdaq, LSE, Xetra, Tokyo, HKEX) and the output contents, so the function is unambiguous. It does not differentiate itself from the similarly named siblings (trading_calendar, business_day, market_status), which keeps it from 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?

Gives a clear usage context ('before scheduling orders, reports or alerts') and clarifies the default behavior when no date is supplied. It stops short of explicit when-not-to-use guidance or naming an alternative sibling tool for calendar-listing or business-day-counting needs.

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