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

Annotations already declare read-only, idempotent, non-destructive, closed-world behavior, so the safety profile is covered. The description adds useful behavior: the period defaults to the current filing season and results are ordered by market cap with both aggregate counts and lists. It still says nothing about pagination, how limit interacts with the returned list, or result shape beyond 'counts and lists'.

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 sentence packs purpose, default, output content, and sort order efficiently, and the example questions are placed last as supporting cues. The leading '[국내 주식 + 채권 MCP FinQuest]' tag is boilerplate that consumes front-loaded space without adding decision value.

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 five optional parameters, no output schema, and annotations covering safety, the description does the needed work of describing what comes back (deadline, days remaining, per-status counts and market-cap-ordered lists). Gaps are minor: it never explains how market filtering or limit truncation affect those lists, which an agent might need when constructing a query.

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 60%, and the schema already documents period format/default and the meaning of the status enum. The description reinforces the default quarter and the three status semantics but adds nothing for limit, market, or min_mcap, leaving roughly half the parameters to the schema alone. Baseline 3 is appropriate given the description contributes only modest extra meaning.

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 a concrete resource and scope: per-quarter statutory filing deadlines, days remaining, and counts/lists of December-fiscal-year companies split into filed / preliminary-only / pending, sorted by market cap. That is far more specific than the bare name 'earnings_calendar'. It does not, however, explicitly separate itself from close siblings such as earnings_season, earnings, or filing, so full sibling differentiation is missing.

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?

Three concrete user-question phrasings ('companies that haven't reported', 'companies that filed preliminary results this quarter', 'when is the earnings deadline') give clear triggering context. There is no explicit when-not guidance or named alternative tool for adjacent needs like raw earnings data or disclosure listings, so it stops 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.