read_element_evidence

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

Beyond the annotations, the description discloses meaningful behavior: orientation is not guaranteed, no external API is called, padding is bounded to 0–0.1, and it explains the returned evidence ID, region, and view_rotation_ccw plus a recovery path. It does not, however, reconcile why a 'read_' tool carries readOnlyHint=false and idempotentHint=false, leaving that annotation profile unexplained.

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 purpose is front-loaded in the first clause, which is good, but the rest is a run-on packing limitations, return values, and a recovery procedure into one dense paragraph without clear separation. Little is pure waste, but the lack of structure hurts scanability.

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 usefully enumerates return fields (evidence ID, original-page region, view_rotation_ccw) and describes the inversion-recovery workflow, covering what an agent needs to chain into read_evidence. The main gap is the undocumented required parameters, but overall it is sufficient for a tool of this complexity.

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%, so the description must compensate for all three parameters. It only adds meaning for padding ('0–0.1边距'), while the two required parameters job_id and element_index receive no description in either the schema or the text. Partial compensation only.

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 states a specific verb and resource: cropping an image by OCR element coordinates and rotating it per the upstream report's page orientation. It also names the sibling read_evidence as the fallback, so an agent can distinguish this from the whole-page read tool. The phrasing is dense and clause-heavy, which slightly blunts immediate comprehension.

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?

It gives explicit when-not conditions ('仅支持未变形、未跨页合并、页码与角度有效的结果') and routes to the alternative read_evidence for those cases. It adds a second conditional branch for inverted views, telling the agent to pass the returned document_id and region as-is to read_evidence without re-rotating. Both the alternative tool and the selecting conditions are named, leaving nothing to inference.

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