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

The annotations already provide readOnlyHint=true, so the description doesn't need to restate that the tool is read-only. Adding value beyond the annotation, the description reveals the job state machine and expected durations, which helps the agent set user expectations and avoid leaving the operation hanging. It does not fully disclose details like typical response latency or pagination, but for a status-check tool, the added context is solid.

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 description is very concise: three short bullet-style sentences covering the state flow, the next step after completion, and the estimated time. It front-loads the core purpose and status values, then adds actionable guidance. Nothing is wasted, and the structure is easy to read even for an AI agent.

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 tool with one parameter and a read-only annotation, the description is fully sufficient. It tells the agent what the tool does, what the possible statuses are, what to do when the status is completed, and how long the operation might take. No returning schema or nested objects exist, so there is nothing missing in that regard. This is enough for correct invocation and follow-up action.

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?

The input schema fully covers the single parameter job_id with a clear description ('analyze_* で取得したジョブID'). Since schema description coverage is 100%, the description does not need to add parameter semantics. It does not provide any extra syntax or examples, but that is not necessary here — the baseline of 3 is appropriate given the high schema coverage.

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?

Title and description both clearly identify the tool's purpose: checking the current status of a detection job. The description explicitly enumerates possible status values (pending → processing → completed/failed), which makes the tool's scope unambiguous. It also contrasts well with its siblings (get_job_result fetches results, list_jobs lists jobs), helping an agent distinguish when to use this one.

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 provides explicit guidance: once the job reaches completed, the agent should call get_job_result instead. It also documents estimated processing times (about 30 minutes for ship detection, about 50 minutes for oil slick detection) and instructs the agent to inform the user about the wait time. This is actionable, context-rich usage guidance that tells the agent when and how to proceed.

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