Server Quality Checklist

Tool Scores

• career_toolC
  2.1/5.0
  Behavior2/5

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

  No annotations exist, so the description must disclose behavioral traits. It does not indicate if the tool reads or writes data, nor any side effects or 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.

  Conciseness3/5

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

  The description is short (one sentence), which is concise, but it lacks essential clarity. Conciseness is not beneficial when it sacrifices understanding.

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

  Completeness2/5

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

  Given the nested objects, lack of output schema, and no annotations, the description is incomplete. It does not explain return values, expected behavior, or how to use the tool effectively.

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

  Parameters2/5

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

  Schema description coverage is 0%, but the description only says 'Pass fields in career_transition_advice or career or top-level.' It does not explain what the parameters mean or how they affect output.

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

  Purpose2/5

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

  The description says 'Career transition / planning' but then adds 'same as career_transition_advice' without explaining what career_transition_advice is, creating confusion. It does not clearly state the tool's function or action.

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

  Usage Guidelines2/5

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

  No guidance on when to use this tool versus siblings (job_tool, resume_tool). The instruction about passing fields in different places is about parameter format, not tool selection.

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

• job_toolA
  3.8/5.0
  Behavior3/5

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

  No annotations exist, so the description carries full burden. It discloses behavioral traits such as the default action and required fields for different search modes (e.g., city/location always required, differences between job_title+city and company+city). However, it does not explicitly state whether the tool is read-only or mention rate limits, auth, or 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.

  Conciseness4/5

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

  The description is well-structured with clear instructions per action, but is somewhat lengthy. Each sentence earns its place, though minor redundancy exists (e.g., emphasizing default action twice). Overall, it's concise enough given the complexity.

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

  Completeness3/5

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

  For a tool with 5 parameters, nested objects, and no output schema, the description covers core usage but lacks details on refine_recommendations and parameters. It does not describe return values or expected output, which is a gap given the absence of an output schema.

  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 60%. The description adds significant meaning for the action enum and search_jobs object (e.g., required fields, mode differences). However, refine_recommendations and parameters lack any description beyond being objects, missing an opportunity to fully compensate for the coverage gaps.

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

  Purpose4/5

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

  The description clearly states the tool's default action is to find job listings via search, and explains three distinct actions (search, refine, detail). It instructs not to use any other tool for this purpose, but does not explicitly differentiate from sibling tools career_tool and resume_tool, leaving some ambiguity.

  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?

  Provides explicit guidance on when to use each action: search as default (or when starting), refine after prior results/feedback, and detail with a specific job_id. It also clarifies when to include resume_text/user_profile, demonstrating clear context for selection.

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

• resume_toolA
  4.4/5.0
  Behavior4/5

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

  Given no annotations, the description takes full burden and discloses key behaviors: different outputs for tailor vs generate, input requirements, template fallback behavior, and warnings like 'never invent URLs' or 'never return raw PDF/HTML/base64'. Does not cover auth or rate limits, but adequately describes core behavior.

  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 structured with clear sections (action, input, output) and is front-loaded with the main distinction. It is somewhat lengthy but every sentence adds necessary details; no obvious fluff.

  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?

  With 8 parameters, no output schema, and no annotations, the description covers the main aspects: actions, inputs, output examples, and template handling. Could include more on tailor output or error handling, but it is sufficient for a tool of this complexity.

  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?

  Schema coverage is 100%, yet the description adds significant value beyond schema descriptions. For example, it recommends specific template keys for different layouts, explains input precedence (json_resume over resume_text), and clarifies legacy aliases. This goes well beyond what the schema alone 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 it is for 'ALL resume-related actions' and distinguishes between two main use cases: tailor (text optimization) and generate (creation with templates/PDF). This is specific and actionable, covering the full scope of the tool.

  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?

  Provides explicit when-to-use guidelines for tailor vs generate, e.g., 'do NOT use tailor for those intents' and 'MANDATORY when the user asks for generate/create resume, ...'. However, it does not compare with sibling tools (career_tool, job_tool), though the description implies it covers all resume tasks.

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