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

The description discloses the two-step behavior (fetch resume then send message), which is useful context beyond the tool name. However, with no annotations, it does not mention whether the operation is read-only, how history is handled, or any limitations.

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 concise sentences with no wasted words, front-loaded with the primary action.

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 covers the core function and workflow. It does not explain the use of the optional history parameter, but the schema covers it. With no output schema, the description sufficiently conveys the tool's role.

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 descriptions for all three parameters (resumeId, message, history) with 100% coverage. The tool description adds no additional parameter-specific meaning beyond the schema.

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's purpose: chatting about a resume, with the specific behavior of fetching resume content first. This distinguishes it from sibling tools like get_resume or tailor_resume.

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 usage for resume-related chat but does not explicitly contrast with alternatives or state when not to use it. No exclusions are mentioned.

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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It indicates cloning creates a new resume, but does not mention whether the original is modified, whether the clone is a deep copy, what the return value is, or any permission/error requirements. This is minimal behavioral information for a mutation tool.

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 a single compact sentence with no filler. It is front-loaded with the action ('Clone') and immediately conveys the purpose and key distinction. Every word is necessary.

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 tool is simple and has clear parameters, but with no annotations or output schema, the description should convey return values or side effects. It does not explain what the clone operation returns (e.g., new resume ID) or whether it fully copies content, which leaves an agent uncertain about the outcome. This is comparable to the update_drive example, which also scored 2 for completeness.

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. The schema already describes 'resumeId' as the source and 'title' as the new title. The description's mention of 'existing resume' and 'new title' adds little beyond the schema, so it does not significantly enhance parameter understanding.

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 uses a specific verb ('Clone') and resource ('resume') with the outcome ('with a new title'), clearly distinguishing this from siblings like create_resume, update_resume, and import_resume. It precisely states what the tool does in a single concise sentence.

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 is for creating a copy of an existing resume with a new title, but it does not explicitly state when to use it over alternatives such as create_resume or import_resume. No exclusions or alternative guidance is provided, so the usage context is only implied.

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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It only states 'Create a new resume' without detailing side effects, required permissions, or whether it overwrites existing data. This is insufficient for a mutation tool, as it doesn't clarify what happens upon creation or any constraints.

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 a single sentence with no filler, but it is under-specified and essentially restates the tool name. While concise, it fails to provide useful information, making it more of a tautology than a helpful description.

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 three parameters, no annotations, and no output schema, the description is incomplete. It doesn't explain the resmarkup format, default behavior for templateId, or how this differs from similar tools. The agent would need additional context to fully understand the tool's functionality.

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%, with each parameter (title, rawContent, templateId) having a description. The tool description adds no meaning beyond the schema, which already documents the parameters. Baseline of 3 applies when schema does the heavy lifting.

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 'Create a new resume' clearly states the action (create) and resource (resume), making the tool's purpose unambiguous. However, it doesn't distinguish itself from siblings like clone_resume or import_resume, which could also result in a new resume. The verb+resource is specific enough for a basic understanding.

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 no guidance on when to use this tool versus alternatives like import_resume or clone_resume. It simply states the action without any context or exclusions, leaving the agent to infer the appropriate use case.

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?

With no annotations, the description carries the full burden of disclosing behavioral traits. It only states 'delete' without mentioning irreversibility, side effects on associated data, or permission requirements. This is a significant transparency gap for a destructive operation.

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 a single, front-loaded sentence with no filler. It earns its place by stating exactly what the tool does.

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 tool is simple with one parameter and no output schema. The description is adequate for basic invocation but lacks context about expected outcomes (e.g., success confirmation) or any irreversible consequences, leaving some ambiguity for the agent.

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% (resumeId has a description). The tool description adds no additional meaning beyond the schema, so the baseline of 3 is appropriate.

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 'Delete a resume by ID' clearly states the action (delete), the resource (resume), and the scope (by ID). It distinguishes itself from sibling tools like update_resume and clone_resume by being explicitly destructive.

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 guidance is provided on when to use this tool versus alternatives. The description does not mention prerequisites, exclusions, or when deleting is appropriate vs. updating/cloning. The use case is implied but not explicit.

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?

With no annotations, the description carries the full burden of behavioral disclosure, but it only states 'Use AI' without explaining outcomes, limitations, non-determinism, or any side effects. It does not mention that results may vary, that it is a generative operation, or what it returns, leaving significant behavioral ambiguity.

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 a single sentence with no wasted words. It is front-loaded with the action ('Use AI to enhance or rewrite') and immediately specifies the resource ('resume text'), making it highly concise and well-structured.

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 tool has no output schema, so the description should clarify what the tool returns, but it does not. It also lacks usage guidance, behavioral notes, and does not explain how the 'resumeContext' parameter influences the enhancement. Given the tool's complexity and missing annotations, the description is not complete enough.

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. The description does not add any parameter-level meaning beyond what the schema already provides, but it does align with the selectedText field. No additional semantic value is contributed, so the baseline score is appropriate.

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 verb 'enhance or rewrite' and the resource 'resume text', making the purpose specific and understandable. However, it does not distinguish from sibling tools like 'tailor_resume' which may overlap in functionality, so it lacks sibling differentiation.

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 enhancing or rewriting resume text, but it provides no explicit guidance on when to use this tool versus alternatives like chat_with_resume or tailor_resume. There are no exclusion criteria or alternative recommendations, so it only achieves 'implied usage'.

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?

No annotations are provided, so the description carries the full burden. It discloses the return encoding (base64 PDF), but does not mention whether the operation is read-only, what side effects occur, or how errors are surfaced. The core behavior is somewhat clear, but safety and error behavior are omitted.

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 concise sentences with no redundant information. The description is front-loaded with the primary action and immediately provides the return format, making it easy to scan.

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 one-parameter export tool with no output schema, the description covers the essential purpose and return value. It lacks guidance on error conditions and when to use it over alternative tools, but is otherwise sufficient for the tool's simplicity.

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 schema already fully describes the only parameter (resumeId) with 100% coverage. The description adds no additional meaning about the parameter, such as expected format or source. Baseline 3 is appropriate since the schema handles the parameter documentation.

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 uses a specific verb ('Export') with a clear resource ('a resume') and output format ('as a PDF'). It additionally states the return type (base64-encoded string), which distinguishes it from siblings like get_resume or list_resumes.

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?

Usage is implied: use this when a PDF version of a resume is needed. However, there is no explicit guidance about when not to use it or which alternative tools to consider (e.g., get_resume for structured data). No exclusions or prerequisites are stated.

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?

No annotations are provided, so the description carries the full burden. It discloses that the result includes full raw content, which is helpful. However, it does not mention any potential error behavior, read-only nature, or other side effects, though for a simple get operation these may be implicitly understood.

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 a single sentence, concise and front-loaded, with no wasted words. It immediately conveys what the tool does and what it returns.

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 get-by-ID tool with no output schema, the description adequately hints at the return value ('full raw content'). It could be complete, but the lack of any mention of error handling or relationship to other list/get tools leaves a small gap.

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 has 100% coverage with a clear description for resumeId ('The resume ID'). The tool description adds nothing beyond the schema, so the baseline of 3 is appropriate as the schema already fully documents the parameter.

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 gets a single resume by ID and returns its full raw content. It uses a specific verb ('Get') and resource ('resume'), and distinguishes itself from siblings like list_resumes by emphasizing the full content retrieval.

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 usage (when you have a resume ID and need the full content), but does not explicitly state when to use it over alternatives or provide exclusions. With sibling tools like list_resumes and export_pdf, more explicit guidance would be beneficial.

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?

With no annotations provided, the description carries the transparency burden. It discloses the key encoding requirement ('File content must be base64-encoded') and the conversion behavior, but it does not mention whether this creates a new record, overwrites existing data, or what the return value is.

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 short sentences with no filler. It front-loads the main action and formats, then adds the essential base64 constraint. Every word contributes utility.

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 two-parameter import tool with no output schema and no annotations, the description covers the input requirements, supported formats, encoding, and conversion target. It doesn't explain return values or side effects, but the tool's low complexity makes this a minor gap.

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. The description adds value beyond the schema by listing accepted file types (PDF, DOCX, TXT, MD) and explicitly naming the output format (resmarkup), tying both parameters into a meaningful operational context.

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 names a specific verb ('Import'), a specific resource ('resume file'), and the conversion target ('resmarkup format'). It also lists supported file extensions, clearly distinguishing this tool from siblings like create_resume or update_resume.

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 clearly implies when to use this tool: when a resume exists as a file in PDF, DOCX, TXT, or MD format. It does not explicitly mention alternatives or when not to use it, but the import vs. create/update distinction is reasonably clear from the tool name and description.

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?

With no annotations provided, the description carries the full burden. It indicates authentication and the 'all' scope, but does not disclose other behaviors like return format, pagination, or read-only nature beyond what 'list' implies. This is minimal but adequate for a simple read operation.

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 a single concise sentence with no wasted words. It fully states the purpose without redundancy.

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 simplicity of a parameterless list operation and no output schema, the description is mostly complete. It covers the core action and scope, though it could mention return format or pagination behavior, which is not critical for correct invocation.

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, so the schema provides no property details. The baseline for 0 params is 4; the description does not need to explain 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 uses the specific verb 'List' with the resource 'resumes' and scope 'for the authenticated user'. It clearly distinguishes from siblings like get_resume (which implies a single resource) by explicitly stating 'all resumes'.

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 context by specifying the scope ('for the authenticated user') but does not explicitly state when to use this tool versus alternatives such as get_resume for a single resume. Usage is implied rather than directly guided.

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?

With no annotations, the description carries full responsibility for behavioral disclosure. It states the operation is a list and implies read-only behavior, but it does not describe return format, pagination, or any side effects. For a simple list tool this is minimal but acceptable.

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 a single sentence with no filler words. It is appropriately sized for a zero-parameter tool and front-loads the action and resource efficiently.

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 (no parameters, no output schema, no annotations), the description is largely complete for the agent's basic needs. It conveys the essential purpose, though it does not explicitly specify the return value structure, which would be expected without an output schema.

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?

There are zero parameters, so the baseline is 4. The description adds nothing beyond the empty schema, but since no parameters exist, there is nothing to explain. The description's mention of 'all available' aligns with the no-filter semantics.

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 uses a specific verb 'List' with a clear resource 'all available resume templates', which precisely defines the scope and distinguishes it from sibling tools like list_resumes. The resource is clearly different, so there is no ambiguity.

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 is for listing templates, but it does not explicitly say when to use this tool versus alternatives or provide any exclusions. No comparison is made with sibling tools, so the agent must infer usage from context.

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?

With no annotations, the description carries the full burden. It discloses that the operation clones (implying a non-destructive copy) and uses AI for tailoring. However, it does not mention side effects like creating a new resume resource, whether the original is modified, or the asynchronous nature of AI processing. This is a moderate disclosure typical for a tool without annotations.

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 a single, front-loaded sentence with no unnecessary words. It efficiently communicates the core action and object, earning a perfect score for conciseness.

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?

Without an output schema, the description should clarify the result of the operation (e.g., a new resume ID or the tailored resume content). It implies cloning but does not explicitly state the return value or whether the original is untouched. This gap makes it adequate but not fully 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 coverage is 100%, so parameters are well-documented. The description adds context by linking resumeId and jobDescription, but does not provide additional syntax or format details beyond what the schema already states. Baseline 3 is appropriate when schema does the heavy lifting.

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 action ('Clone a resume and use AI to tailor it') and the target resource (resume for a specific job description). It distinguishes from siblings like clone_resume (which only clones) and enhance_text (which enhances generic text) by specifying the tailoring purpose.

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 clear context: use when you need to tailor a resume for a specific job posting. It does not explicitly mention alternatives or exclusions, but the purpose is self-evident given the sibling tools. A brief note on when to use clone_resume instead would have made it perfect.

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?

No annotations are provided, and the description simply says 'update an existing resume' without disclosing behavioral traits. It does not state whether it's a partial update, what side effects occur, or any permissions needed.

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 a single sentence and front-loaded, but it is under-specified. It communicates the basic purpose but does not include any additional useful context, so it falls short of being genuinely 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 an update tool with 4 parameters, no output schema, and no annotations, the description is inadequate. It fails to explain whether missing optional fields are preserved or replaced, what the response looks like, or any behavioral nuances.

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% for all four parameters, so the schema already documents parameter semantics. The description adds no extra meaning beyond what the schema provides, warranting the baseline score.

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?

Specific verb 'update' with target 'existing resume' clearly states the tool's function. It distinguishes from siblings like create_resume, delete_resume, clone_resume, and tailor_resume.

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 no guidance on when to use this tool versus alternatives such as create_resume or tailor_resume. No context about typical use cases or prerequisites is provided.

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