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

Annotations already establish readOnlyHint, idempotentHint, and destructiveHint, but the description adds meaningful context beyond them: 'does not upload anything', which addresses a privacy/security concern not captured in the annotations. This goes beyond the structured metadata without contradicting it.

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 three sentences long and front-loads the core purpose in the first sentence. The alias list is slightly redundant with the main verb phrase but earns its place as an intent-matching aid, and the privacy note is concise.

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 simple read-only lookup tool, the description plus annotations cover safety and scope well: formats, read-only behavior, no uploads, and closed-world semantics are all present. However, the meaning of 'recent' is unexplained, result ordering is unspecified, and there is no output schema to help the agent understand the response shape.

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 provides names, types, and numeric constraints but no parameter descriptions, so schema coverage is effectively low. The description mentions a 'project directory' and file formats but never explains the semantics of maxDepth, maxResults, or rootDirectory, leaving the agent to infer their meaning from the parameter names alone.

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 ('Find'), a concrete resource ('recent local 3D print files'), and a scoped location ('in a project directory'). It further sharpens the purpose by enumerating supported formats (STL/STEP/3MF/OBJ/ZIP) and alias intents, leaving no ambiguity about what the tool does.

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 alias intents list ('find generated model', 'locate printable file', 'scan project for...') gives an agent concrete query phrasings that should trigger this tool, which is useful usage guidance. However, it does not explicitly state when not to use it or name alternatives, so the guidance is implicit rather than complete.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral context by specifying what types of information are returned (file types, materials, etc.) and explicitly stating the tool does not calculate instant pricing, which prevents a common misconception.

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 long and front-loads the core purpose, then adds the usage timing, a list of content areas, and a crucial exclusion. Every sentence earns its place with no fluff or repetition.

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 zero-parameter read-only tool with annotations and an output schema, the description is complete. It tells the agent when to use the tool, what it will find, and what it will not do. Nothing essential is missing.

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 tool has zero parameters and schema coverage is 100%, so there is no parameter ambiguity. The description appropriately compensates by explaining the purpose and scope of the data returned, making it clear what the agent will receive when invoking the tool.

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 clearly states the tool reads public requirements for a PrintYourDuck manual custom 3D printing quote request. It lists specific content areas (file types, material options, confirmations, restrictions, private-upload flow) and distinguishes it from instant pricing tools. This is a specific verb+resource combination that clearly differentiates it from siblings like get_quote_status.

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 explicitly says 'Use this before submitting local files' and enumerates what to check, providing clear when-to-use context. While it doesn't name alternative tools, the timing guidance and the negative statement 'Does not calculate instant pricing' help an agent decide when not to use it.

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

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

Annotations already declare the tool as read-only, open-world, idempotent, and non-destructive. The description adds meaningful behavioral context by stating it is 'public-safe' and does not expose private file keys, payment URLs, supplier details, or sensitive operational data, which goes beyond the annotation hints.

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 core action, inputs, and privacy boundary are stated directly and front-loaded, making it easy for an agent to grasp the tool's purpose quickly.

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 the tool's low complexity—two required parameters, a read-only operation, and an output schema—the description covers the essential calling context well. The only notable omission is explicit guidance on when to choose this tool over sibling tools, but that is already addressed in the usage guidelines dimension.

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?

With 0% schema description coverage, the description must carry the semantic burden, and it does identify both parameters: 'quote request ID' and 'matching customer email'. It adds a useful matching constraint not evident from the property names alone, but it provides no additional format, source, or behavior details beyond what the schema already encodes.

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 ('Look up'), a clear resource ('PrintYourDuck quote status'), and the required inputs ('quote request ID and matching customer email'). It also distinguishes itself from sibling tools by focusing on status lookup rather than requirements gathering, recent files, or file submission.

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 implies the tool should be used when a user has a quote request ID and matching customer email and wants to check status. However, it does not explicitly state when to prefer this tool over its siblings or provide any exclusions or alternative routing guidance.

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

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

It discloses meaningful behaviors beyond the annotations: the upload is private, no payment is collected, no instant price is returned, and explicit confirmations and user approval are required. This adds real context for the agent about side effects and user expectations.

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 three tight sentences, front-loaded with the primary action and followed by essential constraints. Every sentence earns its place; there is no filler or repetition of schema details.

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?

The description provides a good high-level summary and the presence of an output schema helps cover return values, but for a 15-parameter submission tool with 0% schema coverage it leaves parameter-level guidance implicit. It also does not connect to the post-submission workflow such as using get_quote_status, making it only minimally complete.

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 needed to compensate but only mentions 'explicit confirmations' generally. It does not explain filePath, name, email, country, materialPreference, quantity, submissionId, desiredDeadline, or the individual confirmation fields. Parameter names provide some inference, so it is not a complete miss, but the coverage is inadequate for 15 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 clearly states a specific action: upload a selected local 3D file and submit it for manual PrintYourDuck quote review. It distinguishes this from siblings by emphasizing 'manual quote review' and 'no instant price', making the tool's role obvious.

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: use this tool when a user has selected a local 3D file and wants a manual quote, and it requires explicit confirmations and user approval. It does not explicitly name sibling alternatives or state when not to use it, but the intended usage is clear.

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