Score Resume

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

Despite the readOnlyHint annotation, the description transparently discloses a key behavioral side effect: it uses the user's credits. It also mentions the need for a connected account, which is an authorization requirement. This adds valuable context beyond the annotations and makes side effects clear to the user.

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 concise and well-structured: the first sentence states the core purpose, the second summarizes outputs, and the third handles the optional parameter usage. It is front-loaded and free of redundant 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?

Given the tool's simplicity (2 parameters, no output schema), the description is contextually complete. It covers what the tool does, what it returns, when to use the optional parameter, and prerequisites. No critical information is missing for a basic understanding of how to invoke and interpret results.

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?

Both parameters (resume_text and job_description) are fully described in the schema with clear explanations of their content and optionality. The tool description reinforces the role of job_description, providing complete semantic coverage for the parameter set.

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 primary function: scoring a resume for ATS compatibility. It details the specific outputs (overall score, section scores, keyword matches/misses, rewrite suggestions), which effectively distinguishes it from sibling tools like optimize_resume or analyze_job_description. The mention of optional job_description further clarifies two distinct usage modes.

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 concrete usage guidance by explaining when to include job_description (to score against a posting) and when to omit it (for a general readiness score). It also notes the prerequisite of a connected account. However, it does not explicitly compare this tool to alternatives like optimize_resume, leaving some ambiguity about when to choose scoring over optimization or analysis.

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