Server Quality Checklist

Tool Scores

• aiapplyd_generate_cover_letterA
  4/5.0
  Behavior4/5

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

  Beyond the annotations (readOnlyHint false, destructiveHint false), the description discloses that the tool reads the saved resume, generates a letter, returns it, and saves it to the account. It also mentions the paid-plan prerequisite. This goes beyond the annotations by explicitly stating the write side-effect (saving) and the dependency on an existing resume, providing meaningful transparency about the tool's behavior.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is concise and well-structured. It leads with the primary action and context, then covers quality attributes, the return value, the save behavior, and the prerequisite—all in three sentences with no redundancy or unnecessary detail. The information is efficiently packed and front-loaded, making it easy for an agent to parse the core purpose quickly.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The description covers the essential aspects: purpose, input (resume from account), output (returned letter), side effect (saving), and a key constraint (paid plan). It does not mention output format, error handling, or specific edge cases, but for a straightforward cover-letter generator, the provided context is sufficient for an agent to understand when and how to use it. The inclusion of the saved-resume dependency and the paid-plan requirement adds practical completeness.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema already provides full descriptions for both parameters (company_name and job_description), achieving 100% coverage. The tool description does not add any additional semantic detail beyond what the schema specifies—it references 'a specific job' but does not elaborate on parameter meanings, constraints, or interdependencies. Since schema coverage is high, the baseline of 3 applies, and the description adds no incremental value for parameter understanding.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's primary action—writing a cover letter for a specific job—and specifies the source (resume on the user's account), the style (own voice, no clichés), and the output (returns the letter). It also notes the side effect of saving, making the purpose unmistakable and distinct from sibling tools like resume optimization or interview question generation.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies when to use the tool (when a cover letter for a job is needed) but does not explicitly contrast it with alternatives or provide conditional guidance. Sibling tools such as optimize_resume or generate_interview_questions are not referenced, so users must infer the appropriate choice from the stated purpose. The paid-plan requirement is mentioned, which is useful context, but it does not constitute usage guidance relative to other tools.

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

• aiapplyd_translate_resumeA
  4/5.0
  Behavior4/5

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

  The description goes beyond the annotations by explicitly explaining that the tool creates a new resume, leaves the original unchanged, and requires a connected AI Applyd account. It does not cover every failure mode or output detail, but it transparently describes the main side effects and prerequisite.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is three concise sentences with the action and outcome up front. It includes necessary side-effect and prerequisite information without any filler or redundant wording.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a one-parameter tool with no output schema, the description covers the prerequisite, the side effect, and the intended use context. It leaves only minor ambiguity about which resume is used if the user has multiple resumes on their account, but it is otherwise complete enough for invocation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The only parameter, target_language, is fully covered by the schema with an example and length constraints. The description does not add any additional parameter-specific constraints or clarification beyond what the schema already provides, so the baseline score of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the verb (translate), the resource (the resume saved on the user's AI Applyd account), and the outcome (saves a translation as a new resume while leaving the original unchanged). This clearly differentiates it from sibling tools like score, optimize, cover letter generation, and auto apply.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description communicates when the tool is useful by mentioning it is for sending resumes to employers in another language, but it does not explicitly name alternative tools or state when not to use this tool. The usage is strongly implied by the translation focus, but not explicitly contrasted with siblings.

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

• aiapplyd_analyze_job_descriptionA
  4.3/5.0
  Behavior4/5

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

  Annotations already mark the tool as read-only and non-destructive. The description adds meaningful behavioral context by noting that it requires a connected AI Applyd account and consumes the user's AI credits, and it summarizes what analysis outputs to expect. There is no contradiction with the annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is three sentences with no filler: the first states the core value, the second gives the call timing, and the third states the prerequisites. Every sentence earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a single-parameter tool with full schema coverage and safety annotations, the description covers purpose, expected output categories, usage timing, and prerequisites. The absence of an output schema is mitigated by explicitly naming what the extraction returns.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% and the sole parameter, job_description, already has a clear description in the schema: 'Full text of the job description.' The tool description reinforces the general use case but adds no new parameter-level detail beyond what the schema already provides.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb, 'extract,' and defines the resource as a job posting, then lists concrete output categories: ATS keywords, must-have versus nice-to-have requirements, seniority signals, and red flags. This clearly distinguishes it from sibling tools like aiapplyd_score_resume or aiapplyd_generate_cover_letter.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description explicitly says to call this before tailoring a resume, which gives a clear actionable trigger. It does not explicitly mention when not to use it or name alternative tools, but the stated context is sufficient for correct use.

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

• aiapplyd_generate_interview_questionsA
  4.3/5.0
  Behavior4/5

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

  The readOnlyHint and destructiveHint annotations already indicate no side effects, and the description adds the important authentication requirement of a connected AI Applyd account. It does not contradict the annotations and provides additional behavioral context beyond them.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, well-structured sentence that lists the key outputs efficiently. It includes the necessary authentication caveat without unnecessary verbosity, making it easy to parse.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given no output schema, the description provides a thorough list of what the tool will generate, covering all major aspects of interview prep. It also notes the account requirement and the optional job description, making it complete for an agent to decide to invoke it.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema already covers all three parameters with clear descriptions. The description adds semantic value by linking job_description to 'STAR scenarios drawn from the posting', clarifying how that optional parameter influences the output.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's purpose as producing interview preparation for a specific role and company. It lists the specific outputs (company insights, questions, STAR scenarios, talking points, etc.), making it distinct from sibling tools like cover letter generation or resume scoring.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies when to use the tool (when interview preparation is needed for a role and company) and states the prerequisite of a connected AI Applyd account. However, it does not explicitly contrast with alternative tools or state when not to use it, leaving some inference to the agent.

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

• aiapplyd_optimize_resumeA
  4.3/5.0
  Behavior3/5

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

  The description adds a behavioral prerequisite ('Requires a connected AI Applyd account') and outlines the output (rewritten resume, score, summary) beyond the annotations. However, it does not disclose any side effects (e.g., whether it modifies stored data), relying on annotations for readOnly and destructive hints.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is concise, using three sentences to cover purpose, output, parameter usage, and account requirement. There is no redundant or irrelevant information.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The description fully covers what the tool does, its parameters, and its output. It even mentions the account requirement. Given the simplicity of the tool and no output schema, this is complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% for both parameters, but the description adds extra context for 'job_description' by explaining the tailoring vs. general use case, which goes beyond the schema's description.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action (rewrite), the resource (resume), and the goal (pass ATS screening). It also distinguishes itself from siblings by mentioning it returns a rewritten resume, score, and summary, and how it can be tailored with a job description.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It provides explicit guidance on when to include the optional 'job_description' parameter (to tailor) versus omit it (for general optimization). It does not explicitly name alternatives like 'aiapplyd_score_resume', but the parameter usage guidance is clear.

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

• aiapplyd_search_jobsA
  4.3/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, and the description adds concrete context: it never changes which roles AI Applyd hunts for, requires a connected account, and spells out the match fields returned. This goes beyond the structured hints without contradicting them.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Three sentences with no filler: purpose and filters first, then return contents, then safety/alternative/requirement. Every sentence carries useful signal.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Although there is no output schema, the description lists the match fields (score, company, location, salary, skills, application URL), covers the prerequisite, and clarifies the read-only boundary. Nothing an agent needs to invoke or interpret the result is missing.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% and each parameter already has a clear description. The tool description only echoes the filter dimensions (title, location, remote preference), so it adds no significant semantic detail beyond the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description names the specific action ('Return'), the resource ('user's AI-curated job matches'), and the filtering dimensions (title, location, remote preference). It also distinguishes itself from aiapplyd_update_job_preferences, so an agent can tell it apart from its sibling.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It states the read-only scope, explicitly routes preference changes to aiapplyd_update_job_preferences, and notes the connected-account prerequisite. It doesn't enumerate all when-not-to-use cases versus the broader sibling list, but for a search tool the key alternative is addressed.

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

• aiapplyd_auto_applyA
  4.4/5.0
  Behavior5/5

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

  Beyond annotations, the description adds crucial behavioral context: it may submit directly or route to a review queue depending on account settings, it rewrites the resume and cover letter, it works across 15 named ATS platforms, and it requires a paid plan. This gives the agent a clear picture of side effects and constraints beyond the destructiveHint annotation.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is front-loaded with the core action and then adds relevant scope, platform coverage, review behavior, and prerequisites. The ATS platform list is long but informative; every major claim earns its place. Slightly dense, but not redundant or padded.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a tool with one required parameter and no output schema, the description covers what the tool does, the exact prerequisite (paid plan), the behavioral outcome (submission vs review queue), and the supported environments (15 ATS platforms). An agent has enough information to decide whether to invoke it and what to expect, even without a return-value specification.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100% and the single job_url parameter is already fully documented. The description adds context about applying to 'ONE specific job posting' but does not add parameter-level syntax or format details beyond what the schema already provides, which matches the baseline for high schema coverage.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with a specific verb and resource: 'Apply to ONE specific job posting end to end.' It clearly describes the full workflow (rewrite resume/cover letter, complete and submit the form) and distinguishes itself from related sub-step tools like generate_cover_letter or optimize_resume by noting it submits on the employer's own hiring system, not a job board.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies when to use it: whenever a user provides a single job URL and wants an actual application submitted, rather than just a resume score, optimization, or cover letter. It also sets a prerequisite ('Requires a paid plan') and scope ('ONE specific job posting'), though it does not explicitly name sibling alternatives or state 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.

• aiapplyd_build_pdfA
  4.5/5.0
  Behavior5/5

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

  Annotations provide only a basic safety profile, so the description adds useful behavior: the resume stays editable, downloads as a PDF, defaults to private, and make_public exposes contact details to anyone with the link. The paid-plan prerequisite is also disclosed. There is no contradiction with the annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Three sentences carry the core action, output, template choices, privacy default, share-link caveat, and plan requirement with no wasted words. The most important function is front-loaded.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  With no output schema, the description still explains the deliverable (PDF download), the editable state, and the key constraints (paid plan, privacy, explicit opt-in for public sharing). Combined with the fully documented input schema, an agent has everything needed to invoke the tool correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, and each parameter already has a detailed description, so the baseline is 3. The tool description mostly restates the template enum and public-link behavior already present in the schema, adding only minor framing like 'raw text' for resume_text.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with a specific action ('Build a formatted, ATS-clean resume') and identifies the resource (raw text in the AI Applyd resume builder), the editable state, and the PDF output. It clearly distinguishes this from siblings like aiapplyd_optimize_resume or aiapplyd_score_resume, which concern content improvement or scoring rather than PDF generation.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It gives clear invocation context: use raw resume text, choose a template, default to private, and honor the paid-plan requirement. It also provides a strong conditional rule: only set make_public to true if the user explicitly asks for a shareable public link. It does not explicitly name when-not-to-use or alternatives, so it stops short of a 5.

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

• aiapplyd_update_job_preferencesA
  4.7/5.0
  Behavior5/5

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

  The description adds meaningful behavioral detail beyond the annotations: the operation REPLACES saved lists, re-runs discovery immediately, and requires a connected account. These details align with destructiveHint=true and idempotentHint=true and help the agent anticipate side effects.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is front-loaded with the primary action, followed by the critical replacement warning, the invocation condition, and the prerequisite. Every sentence carries useful information and there is no filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a 3-parameter tool with no output schema, the description covers what the tool does, its side effects, when to call it, and what is required before calling it. This is sufficient for an agent to select and invoke it correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  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 prose description repeats the 'pass the complete list, not just an addition' warning, which reinforces the schema, but it does not add meaning beyond what the parameter descriptions already state.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states a specific action ('Set the roles and locations'), names the resource (job preferences), and distinguishes this tool from siblings like search_jobs or auto_apply by emphasizing it changes saved preferences and re-runs discovery. The 'REPLACES' warning makes the scope unmistakable.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives an explicit invocation condition: 'Only call this when the user explicitly asks to change what they are looking for.' This also implies when not to call it, which is strong guidance. There are no direct sibling alternatives for updating preferences, so not naming an alternative is acceptable.

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

• aiapplyd_score_resumeA
  4.8/5.0
  Behavior5/5

  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.

  Conciseness5/5

  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.

  Completeness5/5

  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.

  Parameters5/5

  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.

  Purpose5/5

  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.

  Usage Guidelines4/5

  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.