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

Annotations fully cover safety (readOnlyHint=true, idempotentHint=true, destructiveHint=false, openWorldHint=false), so the description's burden is lighter, but it adds essentially nothing behavioral: no polling guidance for what is plainly a job-based async result, no statement about what happens if the job is incomplete or the ID is unknown.

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?

Two sentences where the first is duplicated verbatim, and the unique content (the operation ID and a pointer to describe_operation) is boilerplate rather than useful front-loaded context. Nothing is actively misleading, but the text is pure padding.

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?

No output schema exists, nested objects are present, and parameter semantics are undocumented. The description explains neither what an 'extract result' contains nor how to obtain a jobId, so an agent lacks the information needed to call this correctly or interpret its response.

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 0% across two parameters (a free-form query object and required params.jobId), and the description says nothing about either. The agent must infer the jobId format and where to obtain a valid jobId entirely from schema constraints (minLength 1, maxLength 2000), which carry no semantic 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 is a verbatim restatement of the title and name: 'GET /api/ai/extract/result/:jobId' repeated twice. It implies retrieval of an AI extraction result for a job, but it never says that in prose and never distinguishes this from the sibling endpoints get_ai_extract_progress_by_jobId and get_ai_extract_status_by_jobId.

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?

No when-to-use guidance is given. The only directive, 'describe_operation provides native request schemas,' routes the agent to another tool for schema information but does not say when this tool should be chosen over the status or progress variants.

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