Server Quality Checklist

Tool Scores

• knowledge_codeD
  1.6/5.0
  Behavior2/5

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

  Annotations carry the safety profile with destructiveHint=true and readOnlyHint=false, so the agent is warned that this tool can be destructive. However, the description adds no behavioral context about what gets destroyed, when side effects occur, or how fallback behavior works. The word 'fallback' hints at one behavior but is not explained.

  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 extremely short, which is concise, but it is under-specified rather than efficiently structured. It is not a sentence, provides no front-loaded action, and leaves the agent to infer meaning from the schema. This is closer to a set of tags than a usable description.

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

  Completeness1/5

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

  Given 14 parameters, 9 possible actions, a destructive hint, and seven sibling tools, this description is radically incomplete. An agent cannot determine which action to invoke, what parameters are relevant, or what safety caveats apply. The output schema helps with return values, but the lack of contextual guidance makes the tool very hard to use correctly.

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

  Parameters1/5

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

  Schema description coverage is only 7%, and the description does almost nothing to compensate. It names 'symbols' and 'callers', which loosely map to the symbol and references actions, but it provides no meaning for the many parameters such as path, kinds, query, symbol_id, resource_uri, or fallback_result_paths. This is insufficient for a 14-parameter tool.

  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 is a fragment: 'Code index, symbols, callers, fallback.' It names the tool's domain but uses no verb and does not state what the tool actually does. It is not a tautology, but it is far too vague to convey a clear purpose or distinguish it from sibling tools.

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

  Usage Guidelines1/5

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

  There is no guidance on when to use this tool versus siblings like knowledge_context or knowledge_page. No conditions, exclusions, or alternatives are mentioned. The action enum in the schema gives per-action hints, but the description itself provides zero usage direction.

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

• knowledge_contextD
  1.6/5.0
  Behavior2/5

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

  Annotations already indicate readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds no extra behavioral context such as retrieval behavior, output scope, or parameter interactions, and it does not contradict the annotations.

  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 extremely short and under-specified rather than appropriately concise. It is a noun phrase with no structure, offering minimal value for a tool with 14 parameters.

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

  Completeness1/5

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

  For a complex tool with 14 parameters and multiple modes, this description is completely inadequate. It does not explain the modes, parameter semantics, or how to choose settings, leaving the agent without sufficient context to invoke the tool correctly.

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

  Parameters1/5

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

  Schema description coverage is only 7%, and the description does not compensate. The phrase 'Evidence/gaps, pages, search, and graph' only loosely maps to the mode enum and provides no meaning for the 13 other parameters like query, intent, max_depth, or retrieval_profile.

  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 'Evidence/gaps, pages, search, and graph' lists content areas but lacks a verb or explicit action, so it does not clearly state what the tool does. It vaguely hints at functionality without distinguishing it from sibling tools.

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

  Usage Guidelines1/5

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

  No guidance is provided on when to use this tool versus alternatives like knowledge_page or knowledge_document_context. There are no usage scenarios, exclusions, or references to sibling tools.

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

• knowledge_adminD
  1.8/5.0
  Behavior2/5

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

  Annotations declare destructiveHint=true and idempotentHint=false, raising the bar for behavioral disclosure, but the description adds nothing about what gets destroyed or modified, whether safety nets like backup, dry_run, or setup_mode=preview exist, or what side effects rebuild/repair/migrate have. The words 'rebuild,' 'repair,' and 'migration' are consistent with the annotations, so there is no contradiction—but the description fails to elaborate on any destructive consequence beyond the action names themselves.

  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 single 12-word line is brief, but this is under-specification masquerading as conciseness. There is no lead sentence stating purpose, no grouping of related behaviors, and no hierarchy—just a flat list that duplicates the action enum. Brevity without information structure earns no credit.

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

  Completeness1/5

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

  This is a high-complexity tool—15 parameters, 7 actions, conditional parameter-action interactions (force/dry_run for lint, clients/setup_mode for client_setup, migration_action/target_version for migrate), and destructive semantics—yet the description delivers zero operational guidance. Even with an output schema present, an agent cannot determine which parameters are valid for which action, what the safety modes do, or what output to expect. The definition is severely inadequate for its complexity.

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

  Parameters1/5

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

  Schema description coverage is only 20% (3 of 15 parameters documented: action, force, dry_run, each with a terse one-liner), so the description carries a heavy burden it does not meet. It adds zero meaning about parameters like backup, clients, setup_mode, integrity_mode, migration_action, target_version, include_missing, include_orphans, or include_broken_links, and it does not explain which parameters apply to which action. The description merely restates the action enum, which the schema already provides.

  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, "Initialize/inspect/rebuild, client setup, lint/repair, drift, and migration," is a comma-separated list that maps almost one-to-one onto the action enum (init, status/checkpoint, client_setup, lint, drift, migrate). It never states a clear verb+resource purpose such as 'administers the knowledge base' or 'performs maintenance operations,' so an agent cannot tell what the tool fundamentally does or how it differs from siblings like knowledge_ingest or knowledge_document. This is close to restating the schema's own enum values in prose.

  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?

  There is no guidance on when to use this tool versus its seven siblings, no example workflows, no conditions, and no exclusions. The only usage signal is the action list itself, which the input schema already exposes. An agent gets zero help deciding between knowledge_admin, knowledge_ingest, and knowledge_page.

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

• knowledge_ingestD
  1.8/5.0
  Behavior2/5

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

  The annotations already indicate destructiveHint=true and readOnlyHint=false, but the description adds no behavioral context beyond that. It does not describe effects, prerequisites, or what makes the operation destructive, though it does not contradict the annotations.

  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 extremely short, but this is under-specification rather than efficient structure. It front-loads keywords that do not convey enough meaning to be useful, so the brevity does not earn its place.

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

  Completeness1/5

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

  For a tool with 19 parameters, a 10-value action enum, and a complex ingestion/recovery workflow, this description is severely incomplete. It gives no sense of the required sequence, the meaning of the actions, or how this tool fits with sibling tools.

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

  Parameters1/5

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

  With 19 parameters and only 11% schema description coverage, the description needed to compensate by clarifying parameter meaning and workflow. Instead, it offers only domain keywords and no parameter semantics, leaving the large action enum and many parameters unexplained.

  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 is a set of noun phrases ('Source ingestion, claims, coverage, recovery') rather than a clear statement of what the tool does. It lacks a verb and resource pattern, and it does not distinguish knowledge_ingest from its knowledge_* siblings.

  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?

  There is no guidance about when to use this tool versus alternatives like knowledge_page, knowledge_document, or knowledge_admin. The action enum implies a workflow, but the description itself provides no usage context or exclusions.

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

• knowledge_document_contextD
  1.9/5.0
  Behavior2/5

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

  Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds almost no behavioral context: it does not explain what the tool outputs, how it processes inputs, or what side effects (if any) are expected. It neither contradicts annotations nor enriches them.

  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 short, but under-specification is not the same as conciseness. A single vague phrase without a clear subject-verb-object structure does not front-load the purpose. It reads more like a topic tag than a functional description.

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

  Completeness1/5

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

  This is a high-complexity tool with 21 parameters and close sibling tools, yet the description is practically empty. Nothing tells an agent about the tool's scope, how to choose between plan and section, what evidence types are relevant, or how this differs from knowledge_document or knowledge_context. The output schema and annotations mitigate some gaps, but they cannot replace basic operational orientation.

  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 only 5% across 21 parameters, so the description must compensate. It barely does: 'plans' and 'section evidence' loosely map to the two action enum values (plan and section), but essentially no other parameters (query, audience, max_pages, page_paths, required_evidence, etc.) are clarified. This leaves an agent guessing at most of the input semantics.

  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 'Document plans and section evidence.' is a fragmented, ambiguous phrase. It fails to state a clear verb and resources: 'Document' could be a noun or a verb, and 'plans and section evidence' are vague objects. It does not convey whether the tool creates a plan, gathers evidence, or both, and it does nothing to distinguish it from sibling tools like knowledge_context or knowledge_document.

  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?

  There is no usage guidance whatsoever. The description does not mention when to prefer this tool over knowledge_document, knowledge_context, or other siblings, nor does it state any prerequisites or when not to use it. The only implicit hint is the schema's action enum, which is separate from the description.

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

• knowledge_documentC
  2.6/5.0
  Behavior2/5

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

  Annotations already indicate destructiveHint=true and readOnlyHint=false, so the agent knows this mutates. But the description does not mention overwrite behavior, wiki update plan side effects, or document review semantics. With zero descriptive behavior beyond 'write or review,' the agent gets little insight into what changes are made.

  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 extremely short (8 words), which is concise, and the action enum values add meaningful precision. But it is under-specified rather than efficiently complete, so it doesn't earn a 5.

  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?

  With 12 parameters, 8% schema coverage, a true output schema, destructive annotations, and seven sibling tools, the description should explain what an evidence-backed document is, when to use each action, and what side effects occur (overwrite, wiki plan, file writes). It addresses almost none of that.

  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 very low (8%) and 12 parameters exist, so the description carries almost none of the explanatory burden. However, the action description ('write=save Markdown; review=delivery check') does add meaning for two params. Most parameters—content, language, overwrite, diagram_mode, project_name, client_facing, required_sections, include_wiki_update_plan—are not explained anywhere in the description, so the score is at best a 3.

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

  Purpose3/5

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

  The description says the tool writes or reviews evidence-backed documents, with action enum distinguishing write=save Markdown and review=delivery check. It is somewhat broad ('documents') given the knowledge_* sibling family, but the action enum and document_type parameter give it enough shape. It doesn't clearly distinguish itself from siblings like knowledge_page or knowledge_document_context.

  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 explicit when-to-use guidance, no alternatives mentioned, and no context about when write vs review should be chosen beyond the schema's one-line enum meaning. The sibling list invites comparison but the description provides no routing cues.

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

• knowledge_filesC
  2.8/5.0
  Behavior2/5

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

  With destructiveHint=true in annotations, the description should explain what side effects may occur, especially given the overwrite parameter, but it does not. The word 'controlled' suggests access limits, but it adds little concrete behavioral context about mutation, overwriting, or normalization 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.

  Conciseness5/5

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

  The description is a single compact sentence that front-loads the core resource and action set. There is no filler or redundant restatement of the tool name.

  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 six parameters, a destructive hint, an overwrite flag, and several sibling tools, this one-line description is not sufficient context. The output schema may cover return values, but input selection, side effects, and usage boundaries are left unexplained.

  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 only 17%, so the tool description must compensate for undocumented parameters like path, pattern, category, max_chars, and overwrite. It does not explain these; only the action values are loosely reflected in the description.

  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 identifies a specific resource ('controlled source files and PDFs') and concrete actions (list, read, normalize to Markdown), so an agent can tell what the tool operates on and what it can do. It stops short of a 5 because it does not differentiate this tool from closely named siblings like knowledge_document or knowledge_page.

  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?

  There is no guidance about when to choose this tool over siblings such as knowledge_document_context or knowledge_admin, nor any mention of when to use list versus read versus normalize. The action enum hints at usage, but the description does not provide decision criteria or exclusions.

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

• knowledge_pageC
  2.8/5.0
  Behavior3/5

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

  Annotations already convey that the tool is destructive and not read-only, and the description does not contradict them. 'Durable log' adds a small behavioral nuance suggesting append_log events persist, but the description does not disclose destructive consequences, path mapping behavior, or how actions like move/delete behave.

  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 text is extremely short and front-loaded with the resource name, but for a tool with 13 parameters and six distinct actions it is under-specified rather than appropriately concise. It reads more like a label than a usable tool description.

  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 tool's complexity, the one-phrase description is not enough for an agent to safely invoke the right action with the right parameters. The schema and annotations supply some structure, but the description omits important context such as action semantics, path resolution, dry-run behavior, and when to use append_log versus a page write.

  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?

  The description provides no parameter-level information beyond the generic CRUD/log idea, while schema description coverage is only 23%. It does not compensate for the many undocumented parameters such as old_string/new_string, replace_all, dry_run, max_chars, or level.

  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 phrase 'Page CRUD and durable log' clearly identifies the tool as performing CRUD operations on wiki pages plus a persistent log action, so an agent can tell this is not a file-walking or ingest tool. It is not a tautology, but it does not explicitly differentiate itself from siblings like knowledge_document or knowledge_files.

  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?

  There is no guidance about when to choose this tool over alternatives, no mention of workflow context, and no exclusions such as 'for raw file operations use knowledge_files.' The word 'Page' offers only an implicit hint that this tool is page-oriented.

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