Server Quality Checklist

Tool Scores

• extract_keywordsA
  4/5.0
  Behavior3/5

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

  No annotations are provided, so the description must cover behavioral traits. It states the extraction and grouping behavior, but does not disclose potential limitations (e.g., accuracy, length constraints) or describe the output format beyond grouping. The presence of an output schema partially compensates.

  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 conveys all necessary information without redundancy. It is front-loaded and concise.

  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?

  Given the tool's simplicity (1 parameter) and the existence of an output schema, the description is adequate. It could mention the output format or usage context more explicitly, but overall it covers the core functionality well.

  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%, so the baseline is 3. The description adds context about the output (grouping), but does not add any additional semantics for the input parameter beyond what the schema 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 clearly states the action (extract), the resource (keywords from a job posting), and the specific grouping into must-have and nice-to-have. It distinguishes itself from sibling tools like score_fit and tailor_resume by focusing on keyword extraction rather than scoring or tailoring.

  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 the tool (when keywords are needed from a job posting with grouping), but does not explicitly state when not to use it or provide alternatives. However, the context is clear enough for an AI agent to infer appropriate usage.

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

• score_fitA
  4.1/5.0
  Behavior3/5

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

  No annotations provided, so the description bears full burden. It discloses the outputs (score, recommendation, real/active judgment) but does not explicitly state behavioral aspects like idempotency, side effects, or required permissions. For a scoring tool, this is adequate but not comprehensive.

  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 two sentences: the first explains core functionality, the second provides usage guidance. Every sentence adds value with no redundancy or 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?

  Given that an output schema exists (even if not shown), the description sufficiently explains the two main outputs. For a simple scoring tool, this covers all essential aspects for an agent to use it correctly in context.

  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?

  Input schema has 100% coverage with descriptions for both parameters (resume and job_description). The description adds no extra meaning beyond the schema, so baseline score of 3 applies.

  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 scores resume-job fit on a 1-5 scale with a recommendation and separately judges posting authenticity. It explicitly contrasts with sibling tools by noting it's for triage before full tailoring.

  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 use it for triaging roles that deserve a full tailor, providing clear context. It does not explicitly mention when not to use it or name alternative tools, but the usage is well implied.

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

• tailor_resumeA
  4.1/5.0
  Behavior4/5

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

  No annotations exist, so the description bears full burden. It explicitly states key behavioral traits: 'without fabricating experience', 'truthful rewrites', 'honest gaps'. This assures the agent of ethical, non-destructive behavior. Could mention that it does not modify the original resume, but the return format implies no 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?

  Single sentence efficiently encapsulates purpose, ethical stance, and output list. Every phrase earns its place; no redundant words. Front-loaded with main action and constraint.

  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 2 parameters with full schema coverage, an output schema (so return values already documented), and moderate complexity, the description sufficiently covers the tool's role and behavior. It leaves no critical gaps for selection and 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?

  Schema description coverage is 100%, so baseline is 3. The description does not add extra meaning beyond the schema for `resume` and `job_description` parameters, but it contextualizes their role in the tailoring process. No additional format or constraint details are needed.

  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?

  Description uses specific verb 'Tailor' and resource 'resume to a specific job description', clearly stating the output components (fit score, matched/missing keywords, rewrites, gaps, cover note). It distinguishes from siblings like extract_keywords and score_fit by combining tailoring, scoring, and rewriting.

  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 usage when a resume and job description are available and one wants to tailor without fabrication, but it does not explicitly state when to use this tool over siblings like extract_keywords or score_fit, nor provide when-not or prerequisite conditions.

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

• pingA
  4.5/5.0
  Behavior5/5

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

  No annotations are provided, so the description fully carries the burden. It discloses the exact return value ('pong') and the effect of the optional message parameter (echoing it back). No hidden behavior or side effects are implied.

  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 consists of a single sentence that front-loads the core purpose ('Health check') and immediately follows with the output behavior. No extraneous words; every phrase 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?

  Given the tool's simplicity (one optional parameter, no output schema), the description provides all necessary information: it explains what the tool does, what it returns, and the role of the parameter. No gaps remain.

  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% for the single optional 'message' parameter. The description adds 'echoing an optional message', which reiterates the schema's 'Optional text to echo back' without adding new semantic detail. 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 'Health check' and specifies that it returns 'pong', echoing an optional message. This precisely defines its purpose and distinguishes it from sibling tools like extract_keywords, score_fit, 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.

  Usage Guidelines4/5

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

  The description explicitly states 'Health check', which implies when to use the tool (to verify service availability). While it doesn't mention when not to use it or list alternatives, the context is sufficient for a simple tool with clear intent.

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