Server Quality Checklist

Tool Scores

• foundation_scan_changesB
  3/5.0
  Behavior3/5

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

  Annotations already declare read-only, idempotent, and non-destructive behavior. The description adds the scope of scanning multiple sources but provides no additional behavioral details such as output format, computation cost, or prerequisites beyond what annotations cover.

  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, well-structured sentence that efficiently lists the scan targets and the overall goal. Every word contributes to the purpose, with no redundancy or filler.

  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?

  The tool scans multiple complex sources and produces 'combined boundary signals,' yet the description does not explain what the output looks like, how signals are defined, or when this should be used relative to sibling tools. The complexity demands more informational context.

  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 50%: project_root is described, but base_ref has no description. The tool description does not mention either parameter or clarify how base_ref affects the scan, failing to compensate for the missing schema-level documentation.

  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 identifies the tool's purpose: scanning Git changes, dependencies, migrations, environment names, and structure. It states the goal of combining boundary signals, which distinguishes it from generic analysis tools, though 'boundary signals' could be more specific.

  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 when-to-use guidance is provided. The description does not mention alternatives or contrast with sibling tools like foundation_analyze_project or foundation_doctor, so the agent has no context for selecting this tool over similar ones.

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

• foundation_analyze_projectB
  3.3/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true and destructiveHint=false; the description adds context about additive traces, route elimination, and deliberate abstention. It also mentions the analysis is deterministic and uses specific checks, going beyond the annotation basics.

  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 three sentences and each sentence carries meaningful information about purpose, traces, and side effects. It is appropriately front-loaded and avoids redundant statements, though the phrasing is dense with technical terms.

  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 the absence of an output schema and the complexity of four parameters, the description leaves gaps: no explanation of the return value (beyond proposal/abstention), no parameter details, and no explicit usage guidance. However, it covers the high-level behavior and safety profile reasonably.

  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 25% (only project_root has a description). The description does not mention or explain any of the four parameters (requirement, project_diff, project_root, project_summary), leaving their semantics mostly undocumented. It fails to compensate for the low schema coverage.

  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 proposes or deliberately abstains from a project Foundation using specific checks. It distinguishes itself by noting it does not write project state, implying a read-only analysis. Sibling differentiation is implicit via the 'Does not write' contrast, but no explicit alternative names are given.

  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 the tool is used for Foundation decision-making with the MCP's internal model, but it does not provide explicit when-to-use vs alternatives like foundation_commit or foundation_scan_changes. No exclusions are stated, so usage is implied rather than clearly defined.

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

• foundation_doctorA
  3.5/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is known. The description adds valuable behavioral context by specifying it checks 'non-secret' configuration and 'credential presence' (not values), plus allowed-root access. This clarifies scope and avoids ambiguity, with no 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?

  The description is a single sentence that starts with the verb 'Check' and efficiently enumerates six specific areas without filler. While the sentence is long and could be split for readability, every term contributes to defining the tool's scope.

  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?

  The description thoroughly lists what is checked, providing a solid overview. However, with no output schema, it doesn't mention the return format or how results are delivered, which is a gap for a diagnostic tool. Annotations cover safety, and the scope is clear, but the expected output remains unstated.

  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 50%: project_root is described, but check_model is not. The tool description doesn't explain check_model's role or connection to the listed checks, so the agent must guess its meaning. The description fails to compensate for the missing parameter documentation.

  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 the specific verb 'check' and lists six distinct resources or aspects being examined, making it clear this is a diagnostic tool. It distinguishes itself from sibling tools like 'commit' or 'scan_changes' by focusing on model configuration, credentials, connectivity, and protection status.

  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?

  The description provides no explicit guidance on when to use this tool versus alternatives. It doesn't state conditions like 'when you suspect connectivity issues' or mention sibling tools as alternatives, leaving the usage context implied rather than stated.

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

• foundation_getA
  3.6/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds useful context: it explains the output can be 'readable Markdown' or 'compact Session Brief', and emphasizes the data is 'authoritative'. However, it does not disclose error behavior, permission requirements beyond schema hints, or how the output structure differs by format. This adds value but lacks deeper behavioral detail.

  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 sentence, front-loaded with the action verb 'Read' and directly naming the resource and output variants. There is zero fluff; every phrase ('authoritative', 'readable', 'compact') earns its place by sharpening the tool's nature.

  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 read-only tool with two parameters and no output schema, the description adequately conveys the core purpose and output formats. However, it omits practical notes such as the allowable roots restriction (mentioned in schema) and does not describe what happens when the project_root is invalid or not found. Given the simplicity, it is nearly complete but leaves minor edge-case questions.

  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 50%: project_root has a clear description, but format is only an enum. The description's 'readable Markdown' and 'compact Session Brief' add mild semantic shades to the format values, but it does not explain the relationship between the format parameter and the output, nor any constraints beyond the schema. The enum itself already enumerates the choices, so the added value is modest.

  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 function: 'Read the authoritative Foundation JSON, readable Markdown, or compact Session Brief.' It names a specific verb ('Read') and resource (Foundation), and enumerates the three output formats, effectively distinguishing it as the canonical read tool among the sibling analysis and mutation tools.

  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?

  The description provides no guidance on when to use this tool versus alternatives. There is no mention of preferred scenarios, exclusions, or explicit comparisons to sibling tools like foundation_analyze_project or foundation_scan_changes. The word 'authoritative' hints at being the primary read source, but no direct alternatives are cited.

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

• foundation_answer_questionA
  3.7/5.0
  Behavior4/5

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

  The description discloses that the tool re-runs classification and the internal model recommendation, which adds procedural context beyond the readOnlyHint/destructiveHint annotations. No contradiction is present, though it could be more explicit that no persistent 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.

  Conciseness5/5

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

  The description is a single sentence, direct, and front-loaded with the primary action. No filler or redundancy is present; every clause contributes meaningful information.

  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?

  The description explains the workflow (apply answer, re-run classification/recommendation) but does not state what the tool returns, especially since there is no output schema. For an agent invoking the tool, the return value or result handling is left implicit.

  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?

  With 0% schema description coverage, the description must compensate for missing parameter documentation. It implies the 'answer' parameter is the user's answer, but it does not clearly explain 'analysis_id', leaving the agent to infer that it identifies the returned question/analysis.

  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 uses a specific verb ('Apply') and identifies the resource ('the one returned material-reality or financial-scope question'), then states the follow-up actions. It is reasonably distinct from siblings like analyze_project or get, although it does not explicitly name alternatives or contrast with them.

  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 clearly implies when to use the tool: when a single material-reality or financial-scope question has been returned and the user has provided an answer. It provides clear context but does not include exclusions or explicit alternatives among sibling tools.

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

• foundation_commitA
  3.7/5.0
  Behavior3/5

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

  No annotation hints are provided, so the description carries the burden. It discloses atomicity and the boundary (never modifies application source), but doesn't explain what 'commit to Foundation artifacts' actually entails, side effects, or failure modes. Minimal but not misleading.

  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, front-loaded with the core action, and no wasted words. The key constraint 'Never modifies application source' is prominent.

  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 8 parameters, no output schema, and low schema coverage, the description is too thin. It doesn't mention required parameters, return values, or the meaning of the complex capability/evidence fields, leaving the agent under-informed for a multi-parameter tool.

  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 13%, and the description adds no parameter-level detail. It doesn't clarify what project_root, analysis_id, evidence_checks, or capability lists mean semantically, leaving the agent with sparse guidance.

  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 a specific verb ('commit') and resource ('Foundation artifacts') with a clear condition ('validated, user-confirmed analysis proposal'). It clearly distinguishes this commit tool from the analysis/scan/verify 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 Guidelines4/5

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

  The description implies it should be used only after validation and user confirmation, and explicitly states it never modifies application source. It could name alternative tools more explicitly, but the contextual guidance is sufficient.

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

• foundation_assess_changeA
  3.9/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true and destructiveHint=false, so the 'Does not commit changes' reiterates that. The description adds valuable behavior beyond annotations: 'reanalyze only affected capabilities', indicating a scoped analysis rather than a full reanalysis. However, it does not disclose return format, error conditions, or prerequisites like needing a committed state, so the additional context is moderate.

  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, front-loaded with the core purpose. Every sentence earns its place: the first says what it does, the second clarifies a key non-behavior. No redundant or vague wording.

  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 two parameters, no output schema, and read-only annotations, the description gives enough to invoke the tool: it knows what it does, what it affects, and that it doesn't commit. However, it lacks any mention of return values or next steps after the assessment, which an agent would need to interpret the result. A brief note on output would improve completeness.

  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 50%: project_root has a description, but new_requirement does not. The description mentions 'new requirement' and 'committed Foundation state', which gives some meaning to new_requirement, but it does not clarify parameter syntax or format beyond what the schema already provides. Since coverage is below 80%, the description partially compensates but could be more explicit about the 'new_requirement' content and how it relates to project_root.

  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 compares a new requirement with committed Foundation state and reanalyzes only affected capabilities. This specific verb+resource combination distinguishes it from siblings like foundation_commit (which commits) and foundation_analyze_project (which likely analyzes the whole project). The explicit note 'Does not commit changes' further disambiguates its purpose.

  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 context: use this tool when you have a new requirement and want to assess its impact without committing. It does not explicitly name alternatives or exclusions, but the 'Does not commit changes' caveat implicitly tells the agent not to use this for committing. A small gap is that it doesn't mention when to prefer this over foundation_scan_changes or foundation_analyze_project.

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

• foundation_verifyA
  4.1/5.0
  Behavior4/5

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

  Annotations are sparse (readOnlyHint: false, destructiveHint: false), and the description adds valuable safety context: 'with no shell' indicates command execution is disabled, and 'preview or run' clarifies available modes. This exceeds the annotation baseline without contradicting it.

  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 sentence, immediately front-loaded with the core purpose, and contains no filler or redundant phrasing. Every word contributes to understanding.

  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?

  The tool has no output schema and the description does not mention return values, failure modes, or what 'preview' vs 'run' produces. For a simple tool this is adequate, but it leaves gaps about expected outcomes, making it minimally 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 only 33%, with only project_root described. The description compensates by mapping 'preview or run' to the mode parameter and 'one explicitly registered' to check_id, providing meaning that the schema lacks. It partially compensates for the low 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?

  The description clearly states the action ('Preview or run') and the resource ('one explicitly registered, allowlisted Foundation evidence check'), with a scope constraint ('with no shell'). It distinguishes from siblings by focusing on a single check rather than broad analysis or scanning.

  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 for a single, pre-registered check, but does not explicitly name alternatives or state when to prefer this over sibling tools like foundation_analyze_project or foundation_scan_changes. This is clear context but lacks explicit exclusion guidance.

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