Server Quality Checklist

Tool Scores

• add_interested_companyB
  3.3/5.0
  Behavior2/5

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

  No annotations are provided, yet the description fails to disclose critical behavioral aspects such as whether this creates a persistent record, how it handles duplicates, or what permissions are required. It only states high-level intent without explaining side effects, idempotency, or success conditions that an agent needs to invoke the tool properly.

  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, efficiently constructed sentence that front-loads the verb and contains zero redundant words. It delivers the core purpose immediately without unnecessary filler or tautology.

  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?

  While the description adequately covers the tool's purpose and leverages complete schema documentation, it lacks behavioral details expected for a mutation tool given the absence of annotations and output schema. It omits information about return values, error states, or the persistence model that would help an agent understand the full operation 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?

  With 100% schema description coverage, the parameter names and types are self-documenting; the description adds minimal semantic value beyond implying the domain context for 'rolesOfInterest'. It meets the baseline expectation but does not elucidate parameter relationships, validation constraints, or format requirements beyond what the schema already provides.

  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 action ('Add') and object ('a company'), with specific scope indicating this is for Chen's job search interests. It effectively distinguishes this from sibling tools like `add_learning` through the distinct resource type and domain context, though it could specify what system the company is being added to.

  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 context ('interested in applying to or working with') suggesting job search tracking scenarios. However, it lacks explicit guidance on when to prefer this over `get_context` or `update_preference`, and does not address prerequisites such as whether the company already exists.

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

• update_preferenceA
  3.7/5.0
  Behavior2/5

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

  No annotations provided, so description carries full burden. States operation occurs 'in Chen's context' but fails to disclose mutation semantics (create vs. overwrite), persistence behavior, or side effects. The JSON parsing behavior mentioned in schema parameter description is not reinforced in main description.

  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 zero redundancy. First sentence establishes purpose; second establishes trigger condition with examples. Perfectly front-loaded and appropriately sized for tool 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?

  With no annotations and no output schema, description covers basic operation adequately but omits persistence model, overwrite behavior, and relationship to get_context sibling (which presumably reads these preferences). Adequate for simple key-value tool but has gaps.

  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%, establishing baseline of 3. Description adds domain context through examples (resume format, communication style) but does not add syntax guidance or value constraints beyond what's in the schema. The dot-notation schema hint exists only in parameter description, not main 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?

  Clear specific verb ('Update') + resource ('preference in Chen's context'). Explicitly distinguishes from sibling tools: add_interested_company and add_learning focus on adding specific entities, while get_context retrieves data; this tool specifically handles user preference updates.

  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: 'Use when Chen expresses a new preference' with concrete examples (resume format, communication style, tool choice). Lacks explicit 'when not to use' or named alternative tools, though the scope is narrow enough to be clear.

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

• get_contextA
  3.9/5.0
  Behavior3/5

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

  No annotations provided, so description carries full burden. Expands 'context' into concrete data categories but omits data source, freshness, return format structure, and cache behavior. Justifies a 3 by defining what constitutes 'context' beyond the tool name.

  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, zero waste. First sentence defines scope with enumeration; second gives usage triggers. Front-loaded with action and resource. Every clause earns its place.

  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?

  Simple read tool with one optional parameter. Without output schema or annotations, description adequately covers return categories but lacks return structure and data provenance. Sufficient for the complexity level but 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 coverage is 100% with clear enum documentation. Description lists the section values ('experience', 'skills', etc.) in prose but doesn't explicitly reference the 'section' parameter or explain filtering syntax. Baseline 3 appropriate given schema does heavy lifting.

  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?

  Uses specific verb 'Get' with explicit resource 'Chen's full personal context'. Enumerates specific components (experience, skills, resume preferences, learnings, interested companies) that distinguish this read operation from write-oriented siblings (add_interested_company, add_learning, update_preference).

  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 guidance ('when starting a new project' and 'when you need to understand Chen's background'). Lacks explicit when-not-to-use or named alternatives, but clear positive guidance earns a 4.

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

• add_learningA
  4/5.0
  Behavior3/5

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

  With no annotations, description carries full burden. 'Remember something for future use' implies persistence and retrieval capability, establishing this as a memory tool. However, lacks details on idempotency, storage limits, conflict resolution, or return value confirmation.

  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 zero waste. First sentence establishes purpose immediately; second provides usage contexts. Every word 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?

  Appropriate for a 3-parameter tool with no output schema. Covers purpose, usage semantics, and parameter intent. Could be improved by noting persistence guarantees or what constitutes a successful operation, but adequate for the complexity level.

  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%, establishing baseline 3. Description contextualizes content as 'learning' or 'approach' and mentions 'project' which aligns with source parameter semantics. Does not add syntax details or validation 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?

  Specific verb 'Add' with clear resource 'learning, pattern, or insight to Chen's context'. Distinguishes from sibling get_context (add vs retrieve), update_preference (learnings vs preferences), and add_interested_company (learnings vs companies) by scope and resource type.

  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 positive usage scenarios: 'when Chen adopts a new approach,' 'learns something from a project,' or 'asks to remember something.' Lacks explicit 'when not to use' or named alternatives, but clear contextual boundaries are established.

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