add_resume

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 states that non-text files are converted to text for matching while the original is preserved, and that re-using a name overwrites the stored resume. These are non-obvious behaviors that directly affect how the agent should invoke the tool and what to expect.

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 well-structured with an introductory purpose line, a usage paragraph covering input options and file handling, and a concise Args list. Every sentence adds useful information; there is no redundancy or filler. It remains compact despite covering multiple behavioral 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?

For a three-parameter tool with no required fields and no annotations, the description provides all necessary context: what the tool does, how to pass input, file formats accepted, conversion behavior, and overwrite semantics. The presence of an output schema means the response format does not need to be described. This is complete for the tool's 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?

The input schema provides only types and defaults with no descriptions (0% schema description coverage). The description compensates fully by explaining each argument in the Args section: `name` is a label, `text` is full resume text, and `path` is the file path. It also clarifies that exactly one of `text` or `path` should be given, which is critical for correct invocation.

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 opening sentence 'Store a resume so it can be tailored against job listings' precisely states the action (store), the object (resume), and the intended purpose (tailoring). It clearly distinguishes this tool from siblings like list_resumes, get_resume, delete_resume, and tailor_resume by indicating that it is the storage/upload step.

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 usage context: it instructs to provide either `text` or `path`, enumerates accepted file formats, and explains that re-using a name replaces the existing resume. However, it does not explicitly mention when not to use this tool or name alternative tools for other operations (e.g., 'use tailor_resume to create a tailored version'), so it stops short of a full when/when-not guide.

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