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

Annotations already state readOnlyHint, openWorldHint=false and idempotentHint, so the safety profile is covered. The description adds genuinely useful non-schema context: the exchange coverage set and a pricing/quota model (first 25 calls per day free, then $0.001 per call via x402). It does not explain how a single call returns the multiple advertised result types (does one call return all of them, or is behavior driven by which optional parameters are supplied), which is the key behavioral question for this 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?

The exchange list and capability set are front-loaded and the pricing note is properly deferred to the end. The main weakness is that the capability enumeration is one long run-on series of clauses, which reads as a feature dump rather than a structured statement of what one call returns.

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?

An output schema exists, so return-value documentation is not required here, and the description covers scope, exchanges, cost, and use cases. Given a 4-parameter read-only tool, the remaining gaps are how the optional parameters select different result flavors and how it relates to the holiday/business-day siblings.

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 75%, above the threshold where the schema does the heavy lifting, so 3 is the baseline. The description contributes no parameter-level meaning: it does not clarify the distinction between `at` and `date`, what `list_year` adds beyond the base response, or that `exchange` accepts either MIC or common ticker forms (that detail lives only in the schema). The capability list loosely maps to parameters but adds no syntax or defaults.

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 the resource (stock exchange calendar) and enumerates concrete capabilities: open/closed status now, today's session with early closes and lunch break, next open/close, holidays, previous/next trading day, and T+1/T+2 settlement. It also names the covered exchanges (NYSE/Nasdaq, LSE, JPX). It stops short of differentiating itself from siblings such as public_holidays or business_day, which overlap on the holiday-and-trading-day ground.

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?

'Use for trading agents, order timing and settlement' gives a usage context but no explicit when-not guidance or pointers to alternative tools. An agent cannot tell from this text whether to use market_calendar or the sibling public_holidays/business_day for a holiday lookup, which is the main routing decision it faces.

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