Server Quality Checklist

Tool Scores

• advancedcontextA
  4.3/5.0
  Behavior4/5

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

  With no annotations provided, the description carries full burden and does well by detailing behavioral traits: it explains the tool's query-focused nature, lists 16 specialized operations with their purposes, describes return structures ('success' field plus operation-specific outputs), and covers status/priority/sequence handling. It doesn't mention rate limits or auth needs, but provides substantial operational context.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness2/5

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

  The description is excessively long (600+ words) with repetitive sections. While well-structured with headings, it repeats information across 'Key features', 'Operation details', and usage guidance. Many sentences don't earn their place (e.g., re-listing operation purposes multiple times). It's informative but not concise.

  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 complexity (16 operation types, varied parameters) and no annotations or output schema, the description provides exceptional completeness. It covers purpose, extensive usage guidelines, detailed parameter semantics, behavioral context, return information, and operational strategies. For a sophisticated tool with rich functionality, this description leaves no significant gaps.

  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?

  The description adds significant value beyond the 100% schema coverage. While the schema only defines 'type' (with enum) and 'params' as a generic object, the description extensively explains both parameters: it lists all 16 possible 'type' values (exceeding the schema's 13), provides detailed 'params' structures for each operation type (e.g., 'For "search": Object containing: query'), and includes default values and optional parameters not in the schema.

  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 purpose as 'exploring, analyzing, and retrieving complex information from the project management knowledge graph' with specific verbs and resource. However, it doesn't explicitly differentiate from sibling tools like 'buildcontext' or 'loadcontext' beyond its 'sophisticated query' focus, which prevents a perfect score.

  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?

  The description provides extensive, explicit guidance with dedicated 'When to use this tool' and 'You should' sections, listing 15+ specific scenarios (e.g., 'Retrieving a comprehensive view', 'Searching for specific project entities') and operational strategies (e.g., 'Start with broad queries', 'Combine multiple operations'). This offers clear context for when to use this tool.

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

• startsessionA
  4.4/5.0
  Behavior4/5

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

  With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes behavioral traits such as generating a unique session ID, retrieving recent sessions (up to 3), listing active projects, highlighting high-priority tasks (up to 10), and formatting information in a structured way. However, it lacks details on potential errors, performance characteristics, or rate limits, which slightly limits transparency.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness2/5

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

  The description is excessively long and verbose, with redundant sections (e.g., repeating status/priority information and workflow advice). While it is front-loaded with purpose and usage, many sentences (like detailed lists of return fields and extensive workflow instructions) do not earn their place, making it overly detailed and less concise than ideal for a tool description.

  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 complexity (project management session initialization) and the absence of annotations and output schema, the description provides comprehensive context. It details return information, status/priority handling, sequential task management, session workflow, and usage recommendations, making it complete enough for an agent to understand and invoke the tool effectively without structured output data.

  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?

  The input schema has 0 parameters with 100% coverage, so the baseline is 4. The description adds value by explicitly stating 'No parameters required - the tool automatically retrieves all relevant context,' which clarifies the parameterless nature and the tool's automatic context retrieval behavior, going 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 the tool's purpose as 'initializing a new project management session' and 'providing structured information about ongoing projects, tasks, deadlines, and overall project health.' It distinguishes itself from siblings like 'loadcontext' (for deeper exploration) and 'buildcontext' (for adding new elements), making the verb+resource+scope specific and differentiated.

  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?

  The description provides explicit guidance on when to use this tool, including a dedicated 'When to use this tool' section with 12 specific scenarios (e.g., 'Beginning a new project management session,' 'Getting oriented to your current project portfolio status'). It also contrasts with alternatives by mentioning integration with 'loadcontext' for deeper exploration and outlines a session workflow that positions 'startsession' as the initial step, clearly differentiating it from sibling tools.

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

• buildcontextA
  4.6/5.0
  Behavior4/5

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

  With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes key behaviors: it creates three types of elements (entities, relations, observations), validates against standards, handles batch creation, returns confirmation details, ensures data typing, and includes error handling with descriptive messages. It covers creation operations comprehensively but could mention rate limits or authentication needs.

  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 well-structured with sections like 'When to use', 'Key features', and 'Parameters explained', but it is overly verbose with repetitive lists (e.g., 14 entity types, 14 relation types). Some sentences could be condensed (e.g., the 'You should' section has redundant advice), reducing efficiency. It's front-loaded with purpose but includes unnecessary elaboration.

  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 complexity (2 parameters, no output schema, no annotations), the description is highly complete. It covers purpose, usage, behaviors, parameters, valid types, return information, error handling, and best practices. It provides all necessary context for an AI agent to select and invoke the tool correctly, despite the lack of structured annotations or output schema.

  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 description coverage is 100%, but the description adds significant value beyond the schema. It explains the 'type' parameter with its three enum values and details the 'data' parameter's structure for each type, including nested objects, optional fields, valid entity/relation types, and status/priority values. This compensates for the schema's lack of nested object details and enriches parameter understanding.

  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 as 'constructing and enhancing your project management knowledge graph by adding new project elements, relationships, and observations.' It specifies the verb ('constructing and enhancing'), resource ('project management knowledge graph'), and distinguishes from siblings like 'deletecontext' (deletion) and 'loadcontext' (loading).

  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?

  The description includes an explicit 'When to use this tool' section with 12 bullet points covering scenarios like creating entities, establishing relationships, and adding metadata. It provides clear context for when to use this tool versus alternatives (e.g., for creation vs. deletion with 'deletecontext'), though it doesn't name specific sibling tools, it implies usage distinctions.

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

• deletecontextA
  4.6/5.0
  Behavior5/5

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

  With no annotations provided, the description carries the full burden and excels in disclosing behavioral traits. It details deletion behaviors by type (e.g., 'Entities: Removes the specified entities and all their associated relations'), safety considerations (e.g., 'Entity deletion is permanent'), cascading effects, and specific management rules for status, priority, and sequential tasks. This goes far beyond basic functionality.

  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 well-structured with clear sections (Purpose, When to use, Key features, Parameters, etc.), but it is excessively long with repetitive advice (e.g., multiple reminders about status/priority relation management). While informative, it could be more concise by eliminating redundancy and focusing on essential guidance.

  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 complexity (destructive operations with cascading effects), no annotations, and no output schema, the description provides comprehensive context. It covers purpose, usage, parameters, behavioral details, safety considerations, and even return information, making it complete enough for safe and effective use despite the lack of structured metadata.

  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?

  Despite 100% schema description coverage, the description adds substantial value beyond the schema. It provides detailed semantics for the 'type' parameter with examples for each enum value, explains how 'data' structure varies by type with concrete examples, and clarifies interpretation rules (e.g., 'Determines how the data parameter is interpreted'). This significantly enhances understanding beyond the schema's basic 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?

  The description clearly states the tool's purpose as 'removing elements from the project management knowledge graph' with specific mention of 'entities, relations, and observations.' It distinguishes from sibling 'buildcontext' by being for deletion rather than creation. However, it doesn't explicitly differentiate from other siblings like 'advancedcontext' or 'loadcontext' beyond the deletion focus.

  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?

  The description provides extensive, explicit guidance on when to use this tool through a dedicated 'When to use this tool' section with 13 specific scenarios (e.g., 'Removing completed or canceled projects or tasks,' 'Deleting erroneous relationships'). It also mentions using it 'in conjunction with buildcontext' for refinement, giving clear alternatives and context.

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

• endsessionA
  4.6/5.0
  Behavior4/5

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

  With no annotations provided, the description carries the full burden of behavioral disclosure and does so comprehensively. It details the multi-stage workflow (7 typical stages), explains what happens upon completion (e.g., 'Records the session completion in persistent storage,' 'Updates the project status in the knowledge graph'), and covers operational aspects like revision handling, stage progression, and return formats. It does not mention potential errors, rate limits, or authentication needs, but given the depth provided, it exceeds the baseline for no-annotation tools.

  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 well-structured with clear sections (purpose, usage guidelines, key features, stages, parameters, management details, completion actions, return info, instructions), but it is excessively long and repetitive. For example, the 'When to use this tool' list has 13 items with some redundancy (e.g., 'Documenting decisions' and 'Recording achievements'), and details like 'Status and Priority Management' could be more succinct. While informative, it could be trimmed without losing essential information.

  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 high complexity (9 parameters, multi-stage workflow, no annotations, no output schema), the description is exceptionally complete. It covers purpose, usage, behavior, parameters, workflow stages, management details, completion actions, return formats, and agent instructions. The absence of an output schema is mitigated by detailed explanations of JSON and markdown responses. This provides all necessary context for an agent to use the tool effectively.

  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?

  Despite 100% schema description coverage, the description adds significant value beyond the schema. It provides a dedicated 'Parameters explained' section with detailed semantics for all 9 parameters, including examples, stage-specific data structures for 'stageData' (e.g., formats for 'achievements,' 'taskUpdates'), and practical usage notes (e.g., 'Obtained from the startsession tool,' 'Typically 7 for the complete workflow'). This compensates for any schema ambiguities and enhances agent understanding.

  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 as a 'multi-stage tool for documenting project management sessions' with specific verbs like 'recording achievements, tracking task updates, and creating a structured record.' It distinguishes itself from sibling tools like 'startsession' by focusing on concluding sessions rather than initiating them, and from context tools by handling session documentation rather than context management.

  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?

  The description provides explicit guidance on when to use this tool with a dedicated 'When to use this tool' section listing 13 specific scenarios (e.g., 'Concluding a project planning or review session,' 'Documenting decisions made during team meetings'). It also implicitly distinguishes from alternatives by referencing 'startsession' for obtaining session IDs and 'loadcontext' for visualizing task sequences, though it could more directly contrast with sibling tools like 'advancedcontext' or 'buildcontext.'

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

• loadcontextA
  4.6/5.0
  Behavior4/5

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

  With no annotations provided, the description carries full burden and delivers comprehensive behavioral disclosure. It explains output format ('formatted markdown text with hierarchical structure'), session tracking behavior, error handling ('Error messages if the entity doesn't exist'), and detailed return information for each entity type. The only minor gap is lack of explicit rate limit or performance characteristics.

  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?

  While well-structured with clear sections, the description is excessively long (over 700 words) with repetitive information. Multiple sections cover similar ground (entity type details appear in both 'Key features' and 'Each entity type returns' sections). The core purpose could be communicated more efficiently without sacrificing clarity.

  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 3 parameters with 0% schema coverage, no annotations, and no output schema, the description provides exceptional completeness. It covers all parameters thoroughly, explains behavioral characteristics, details output format and content for each entity type, provides usage scenarios, and contrasts with sibling tools. Nothing essential appears missing for this retrieval tool.

  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?

  With 0% schema description coverage, the description fully compensates with a detailed 'Parameters explained' section. It provides clear explanations for all 3 parameters including purpose, examples, defaults, and practical usage guidance. The entityType parameter explanation includes a comprehensive list of valid values and their implications for output formatting.

  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 as 'retrieving detailed contextual information about project entities' with specific entity types (projects, tasks, milestones, team members, resources). It distinguishes from sibling tools by explicitly contrasting with 'buildcontext' (for adding new entities) and 'deletecontext' (for removal), establishing clear functional boundaries.

  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?

  The description provides extensive explicit guidance with a dedicated 'When to use this tool' section listing 13 specific scenarios, plus a 'You should' section with 14 actionable recommendations. It clearly distinguishes when to use this tool ('only retrieves existing information') versus alternatives like 'buildcontext' (for adding new entities) and mentions integration with 'startsession' for session tracking.

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