Server Quality Checklist

Tool Scores

• generate_burnout_reportA
  4.2/5.0
  Behavior4/5

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

  Annotations declare readOnlyHint=true and openWorldHint=true. Description adds critical behavioral context beyond annotations: specific pricing/auth requirement (29€/month Starter tier, 403 error) and output structure details (action plans split by timeframe, resource recommendations). No contradictions with 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 with zero waste: Sentence 1 states purpose and output contents; Sentence 2 states auth constraint; Sentence 3 distinguishes from sibling. Front-loaded with action verb. No redundant repetition of schema or annotation information.

  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 complex nested schema (4 params with nested objects, enums) and no output schema, description adequately explains return value structure (analysis types, action plan categories) and critical auth constraints. Missing only minor details like explicit mention of JSON/HTML format differences handled by 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 description coverage is 100%, so baseline is 3. Description references 'dimension-by-dimension' which loosely maps to the responses array structure, but does not add specific parameter guidance, syntax help, or examples beyond what the comprehensive 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?

  Specific verb 'Generate' + resource 'burnout assessment report' + scope details (dimension-by-dimension analysis, action plans immediate/short-term/long-term, resource recommendations). Explicitly distinguishes from sibling analyze_burnout by stating it is 'More detailed' and lists specific additions (interpretations, status per dimension, structured action plan).

  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 prerequisite warning (Starter tier required, 403 error for Free tier). Names sibling tool analyze_burnout for comparison ('More detailed than analyze_burnout'). Implicitly guides selection by contrasting depth, though does not explicitly prescribe 'Use this when...' scenarios.

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

• quick_burnout_checkA
  4.2/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true (safe read operation) and openWorldHint=true (external API call). Description adds value by disclosing the wrapper pattern ('internally calls analyze_burnout with sensible defaults'), helping agents avoid redundant calls. However, lacks details on output format or what constitutes 'sensible defaults'.

  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 zero waste: first defines the tool (simplified screening), second specifies use contexts (chatbots/triage), third explains implementation (wrapper with defaults). Information is front-loaded and every sentence earns its place.

  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 100% schema coverage, presence of annotations, and the tool's nature as a simplified wrapper, the description adequately covers intent and delegation pattern. Minor gap: no mention of return value format (though no output schema exists to guide this).

  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%, establishing a baseline of 3. Description adds conceptual value by grouping the three required parameters as '3 scores (one per dimension),' providing semantic coherence that individual schema descriptions lack. Also hints at the optional parameters' purpose (profession, hours) through the use-case examples.

  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 states specific action ('simplified burnout screening') and resource (burnout/risk assessment). It clearly distinguishes from sibling 'analyze_burnout' by positioning itself as the lightweight alternative ('just 3 scores') and explicitly noting it wraps the other 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 clear contexts for use ('quick assessments in conversations, chatbots, or triage') and explains relationship to sibling ('internally calls analyze_burnout'). Would be 5 if it explicitly stated 'use analyze_burnout instead for detailed analysis' rather than implying it.

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

• get_stresszero_api_keyA
  4.4/5.0
  Behavior4/5

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

  Adds critical context beyond annotations: rate limit '500 calls/month,' irrevocability 'key is returned once and cannot be retrieved later,' and prerequisite 'Requires a valid email address.' Aligns with idempotentHint=false (creates new resource each time) and destructiveHint=false.

  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?

  Four sentences with zero waste: (1) purpose+constraints, (2) usage context, (3) critical behavioral warning, (4) prerequisites. Well front-loaded and appropriately sized for a 2-parameter mutation tool.

  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?

  Lacks output schema but description compensates by stating the key is 'returned once.' Covers rate limiting, retrieval constraints, and authentication requirements. Missing only minor details like error cases for duplicate emails.

  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 100% coverage so baseline is 3. Description adds validation emphasis ('valid email address') and implicitly contextualizes project_name via 'help users get started.' Elevates slightly above baseline by highlighting the required nature of email beyond just schema constraints.

  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?

  Specific verb 'Create' + resource 'StressZero API key' with clear scope (500 calls/month). Distinguishes from burnout analysis siblings (analyze_burnout, etc.) by focusing on API provisioning vs. burnout assessment.

  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 when to use: 'help users get started with the API.' Lacks explicit 'when not to use' or named alternatives, though differentiation from siblings is obvious from the domain shift (API keys vs burnout analysis).

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

• analyze_burnoutA
  4.5/5.0
  Behavior4/5

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

  Annotations indicate readOnlyHint=true, and the description adds valuable behavioral context including specific return values (0-100 score, risk levels, urgency rating), rate limits, and tier availability. No contradiction with 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 efficiently structured sentences: purpose first, then requirements, then operational constraints. No redundant information; every sentence adds actionable detail not duplicated in the title or schema.

  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?

  Despite no output schema, the description comprehensively documents return values. Given the complex nested input structure (4 parameters with enums and nested objects), it adequately covers operational constraints and prerequisites.

  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 100% schema coverage (baseline 3), the description reinforces critical constraints ('3-20 response items', 'at least the 3 dimensions') that help agents understand how to properly populate the complex nested 'responses' array parameter.

  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 verbs ('Score burnout risk') and identifies the resource (3 dimensions: physical, emotional, effectiveness). It distinguishes from sibling tools like 'quick_burnout_check' and 'generate_burnout_report' by emphasizing detailed multi-dimensional scoring with specific output metrics.

  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 clear prerequisites ('Requires 3-20 response items covering at least the 3 dimensions') and rate limit context ('Free tier: 500 calls/month'). However, it lacks explicit guidance on when to choose this over 'quick_burnout_check' or 'generate_burnout_report'.

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