Server Quality Checklist

Tool Scores

• list_applicationsA
  3.7/5.0
  Behavior3/5

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

  ReadOnlyHint annotation already covers safety. Description adds filter defaults but not other behaviors like pagination or rate limits.

  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?

  Two sentences plus two examples, no wasted words. Front-loaded with core action.

  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?

  Covers filtering well but omits pagination behavior despite a limit parameter. No output schema, so return format is assumed.

  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?

  With 40% schema coverage, description explains view enum, free-text search, and provides examples, compensating for missing schema descriptions.

  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?

  Clearly states 'List job applications' and enumerates filters. Lacks explicit sibling differentiation but is unambiguous.

  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?

  Provides filter context and examples, but does not specify when to use this tool over siblings like get_due or get_planned.

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

• update_applicationA
  4.1/5.0
  Behavior4/5

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

  Annotations indicate readOnlyHint=false and destructiveHint=false, so the description adds value by stating that status changes are automatically logged to the timeline. This is a behavioral trait beyond the annotations. No contradictions.

  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 plus an inline example. It is front-loaded with the core action, concise, and every part adds value without waste.

  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?

  Given 19 parameters and moderate schema coverage, the description is adequate but minimal. It lacks explanation of partial updates, error conditions, or return values. The example provides some context but does not fully cover the tool's complexity.

  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 68%, with many parameters already described in the schema. The description provides a helpful example but does not add new semantic information for individual parameters beyond what the schema already offers.

  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 clearly states 'Update fields of an application' with explicit verb and resource. It distinguishes from siblings like add_application, list_applications, and get_application via the context of modifying an existing application.

  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?

  Description provides a direct hint: 'get the id from list_applications' indicating prerequisite. It also notes automatic timeline logging for status changes. However, it does not explicitly specify when not to use this tool or mention alternatives for related actions like adding notes.

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

• get_applicationA
  4.2/5.0
  Behavior4/5

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

  Annotations declare readOnlyHint=true, which the description aligns with. The description adds behavioral context: returns all fields, contacts, timeline events, and an analysis flag. It also hints at related operations (fetch via dashboard, attach_analysis) but does not contradict 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 a single, information-dense sentence that efficiently communicates the tool's purpose and key data inclusions. No wasted words; essential details are front-loaded.

  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 simple getter with one parameter, the description covers the return content adequately. It provides actionable context (e.g., analysis attachment hint). Missing error/edge cases but sufficient for typical use.

  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 (id, uuid) is implied by context ('one application') but not explicitly described. Since schema coverage is 0%, the description should add meaning, but it only indirectly indicates identification. It does not explain format or constraints beyond 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 clearly states the tool retrieves full detail of one application, specifying included data: fields, contacts, recent timeline events, and analysis attachment status. It distinguishes from sibling tools like list_applications (list vs single) and get_planned (different resource).

  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 use when detailed view of a single application is needed. It mentions alternatives for further actions (e.g., 'fetch it via the dashboard or attach_analysis to replace'), but does not explicitly state when not to use this tool or compare directly to siblings.

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

• get_dueA
  4.2/5.0
  Behavior3/5

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

  The annotations already provide readOnlyHint=true, so the safety profile is known. The description adds behavioral context by specifying it returns applications with due or overdue next_action_due. No additional details like authentication or rate limits, but sufficient for this simple read tool.

  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?

  Two sentences with no wasted words. The key information is front-loaded: what the tool returns and when to call it. Excellent conciseness.

  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 no output schema, the description adequately specifies the output (applications with due/overdue next_action_due). It doesn't detail return format or pagination, but for a simple filter tool, this is sufficient.

  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?

  No parameters exist, and schema description coverage is 100%. With 0 parameters, the description does not need to add parameter information, so baseline 4 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 uses specific verb ('get') and resource ('due actions') and clearly states it retrieves applications with next_action_due today or overdue. It distinguishes from sibling tools by giving a concrete use case, e.g., not listing all applications or planned actions.

  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 explicitly states when to call: when the user asks 'what should I do today?' about their job search. It provides clear context for usage, though it does not explicitly mention when not to use or list alternatives.

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

• add_applicationA
  4.4/5.0
  Behavior4/5

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

  Describes return behavior: 'Returns the created application and possible-duplicate warnings'. Discloses duplicate detection and user instruction. Annotations have readOnlyHint=false and destructiveHint=false, which align with a create operation. No contradictions.

  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 extremely concise: two sentences plus an example. It is front-loaded with the core purpose and immediately provides usage clarity. Every sentence is informative with no 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?

  For a complex tool with 19 parameters and no output schema, the description covers the key behaviors (two input modes, duplicate warnings). It might lack guidance on parameter combinations, but it is sufficiently complete for an AI to use correctly.

  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?

  With 74% schema coverage, the description adds value by providing an example for the raw parameter and clarifying that company and role are required in structured mode. It doesn't re-describe all parameters, but the schema already covers them adequately.

  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: 'Track a new job application.' It explains both usage modes (raw line or structured fields) and distinguishes from sibling tools like list_applications and update_application by being a create operation.

  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 guidance on when to use raw vs structured fields: 'Pass either a single raw line... or structured fields'. Also instructs on handling duplicates: 'if duplicates are listed, tell the user instead of creating again'. Missing explicit when-not-to-use, but covers common scenarios well.

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

• add_noteA
  4.4/5.0
  Behavior3/5

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

  Annotations already indicate readOnlyHint=false (mutation) and destructiveHint=false (not destructive). The description adds 'append' which clarifies it is additive, but does not elaborate on side effects or permissions. With annotations covering safety profile, description provides adequate but minimal extra behavioral context.

  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?

  Two sentences plus a code example. Front-loaded with purpose and usage. Every word adds value, no redundancy. Example is concise and instructive.

  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, clear annotations), the description covers all needed aspects: purpose, usage context, parameter details, and an example. No gaps remain for an agent to select and invoke correctly.

  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 has 0% description coverage (no property descriptions), so the description carries full burden. It explicitly mentions both parameters (application_id and text) and describes text as 'free-text note' and 'multiline markdown is fine'. The example shows expected values and format, adding substantial meaning 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 clearly states the tool's purpose: 'Append a free-text note to an application timeline' with specific examples of note types (recruiter call summaries, interview instructions). This distinguishes it from sibling tools like add_application or log_interview.

  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 explicit context on when to use the tool (recruiter call summaries, interview instructions, pasted messages) and includes a concrete example. It does not explicitly state when not to use it or list alternatives, but the provided context is sufficient.

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

• log_interviewA
  4.4/5.0
  Behavior4/5

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

  Annotations indicate non-readonly and non-destructive. Description adds side-effect context: 'keeps the application's next-interview date in sync.' No contradiction. Lacks details on authentication or rate limits but sufficient for a simple creation tool.

  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?

  Two focused sentences plus example. Front-loaded with action and constraint. Every sentence adds value: purpose, fields, side effect, example. No 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?

  Covers inputs, behavior, and side effect. No output schema, but description adequate. Could mention max limit enforcement or error cases, but overall complete for a mutation tool.

  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?

  Input schema has 83% description coverage. Description adds meaning by enumerating fields (scheduled_at, status, attendees, links, recap) and providing an example. Clarifies 'status' enum and 'profile link' optionality, supplementing 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?

  Description uses specific verb 'Log' and resource 'interview for an application', includes max limit (10 per application), lists key fields, and provides a concrete example. Clearly distinguishes from siblings like 'add_note' or 'attach_analysis'.

  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?

  States clear purpose and constraint ('max 10 per application'). While no explicit 'when not to use' or alternatives, the context signals show distinct sibling tools, and the description implies when to invoke (recording an interview). Could be improved with 'use this instead of...' but still clear.

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

• attach_analysisA
  4.6/5.0
  Behavior5/5

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

  Disclosures destructive behavior (replaces previous), size limit (100KB), and user-facing purpose (dashboard). Complements annotations (destructiveHint=true) without contradiction.

  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?

  Multiple sentences each adding value (size limit, replacement behavior, usage context). Example is helpful but slightly extends length; overall efficient.

  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?

  Fully covers all key aspects for a two-parameter tool: purpose, replacement semantics, size constraints, and end-user consumption, needing no further clarification.

  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 has minimal description for 'markdown'; description adds context that it is 'company analysis (research you produced)' and provides a concrete example, compensating for low 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?

  Clear verb ('Attach') + resource ('company analysis') + destination ('to an application'). Distinguishes from sibling 'attach_file' by specifying markdown analysis content.

  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?

  Explicitly states 'Single document per application - a new call REPLACES the previous one', providing clear usage context. Lacks explicit mention of when not to use, but context is strong.

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

• attach_fileA
  4.6/5.0
  Behavior5/5

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

  Annotations indicate destructiveHint=true; the description confirms and expands: 'a new call REPLACES the previous one'. Adds details on max size (~5 MB), allowed formats (pdf/doc/docx/txt/md), and MIME inference. No contradictions.

  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 paragraph, front-loaded with action and purpose, followed by key details and a clear example. Every sentence adds value. No filler.

  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 5 params and no output schema, the description covers purpose, usage, behavior, constraints, and an example. Does not mention error conditions, but for a file attachment tool it is sufficiently 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 40% (descriptions for mime and data_base64). Description adds value by stating file size limit, allowed formats, and replacement behavior per (application, kind). Kind enum is enriched with natural language definitions. Example provides context for all parameters.

  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: 'Attach or replace a file on an application'. It specifies the resource (application), file types (CV or cover letter), and the effect. The tool is distinct from sibling tools like add_application or attach_analysis.

  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?

  States when to call: 'whenever you generate a tailored CV or cover letter'. Explains replacement semantics and file constraints. However, no explicit mention of when NOT to use or alternatives like attach_analysis. Good but not exhaustive.

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

• get_plannedA
  4.7/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true; description adds context that it returns interviews with time, attendees, meeting links, and actions due, which is useful. No contradictions or missing behavioral traits.

  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?

  Two sentences plus an example, front-loaded with key information, no wasted words.

  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 adequately describes what is returned (interviews, actions due) and range options. It also distinguishes from get_due, making it contextually 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% with enum and description, but the description reinforces the parameter through natural language ('today, tomorrow, or the next seven days') and provides an example, adding clarity 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 clearly states the tool shows scheduled interviews and actions due for specific ranges, using specific verbs like 'shows' and 'is scheduled'. It distinguishes itself from sibling tool get_due by noting that get_due only knows action deadlines.

  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?

  Explicitly tells when to use it: when user asks about plans, day/week looks, or before proposing a time. Also provides a contrast with get_due and gives an example usage.

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