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

The description discloses meaningful behavior beyond the sparse annotations: it fills values with provenance ('marked with where it came from') and confidence, and it refuses to set industry classification. But 'fills in the values' is ambiguous about whether the tool persists changes directly or returns them for confirmation, and there is no mention of permissions, reversibility, or side effects. Given the annotations only contain destructiveHint=false and openWorldHint=false, the description does not fully carry the behavioral burden.

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 two sentences with no filler. The first sentence front-loads the action and resource, then explains the output quality signals; the second sentence adds a crucial limitation. Every clause earns its place.

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?

Given there is an output schema, the description need not explain return values. It covers the document types, the extraction-and-fill action, provenance/confidence, and the industry-classification limitation. The main gap is not clarifying whether the filled values are persisted immediately or require a subsequent confirmation step (suggested by sibling banking_confirm_extracted_value), but this is minor for a simple two-parameter tool.

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 100%, so the baseline is 3 even though the description provides no parameter-specific information. Both parameters are documented only as 'UUID value wrapper,' which is minimally helpful, but their names (applicationId, documentId) make their roles self-evident. The description adds no further semantic meaning to the parameters.

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 ('Reads ... and fills in'), a clear resource ('uploaded document on a banking application'), and enumerates the accepted document types ('Certificate of Incorporation or an IRS EIN letter'). It also explicitly states a non-goal ('It never sets the industry classification'), which distinguishes it from closely related tools like banking_suggest_industry_code.

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 gives clear context on what this tool is for and includes an important exclusion: 'It never sets the industry classification: no document states it.' However, it does not explicitly name alternative tools (e.g., banking_confirm_extracted_value or banking_suggest_industry_code) or state exactly when to prefer this tool over those siblings.

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