Server Quality Checklist

Tool Scores

• carve_formatA
  3.5/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 agent knows the operation is safe and non-mutating. The description adds that it reports lossy raw-format nodes, which is useful, but it doesn't clarify what constitutes a lossy node or what the report looks like. This is acceptable given the annotations but not richly detailed.

  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?

  One sentence, front-loaded with the action, and free of redundant wording. Every component earns its place: the verb, the resource, the mode ('canonically'), and the reporting behavior.

  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?

  For a single-parameter, read-only tool this is mostly sufficient: it names the action and the report. However, there is no output schema, so the description should more explicitly define the 'report' output format. It also doesn't mention error behavior or what 'canonical' means in practice, leaving some ambiguity.

  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?

  The input schema provides 100% coverage with a description for the single 'source' parameter, so the description doesn't need to repeat it. The tool description adds no extra parameter meaning beyond what the schema already states.

  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 states a specific verb and resource: 'Format Carve source canonically.' It also indicates a distinct outcome—reporting lossy raw-format nodes—which separates it from parsing, linting, rendering, or migrating. It doesn't explicitly name sibling tools, but the verb 'Format' and the unique report clause make the purpose unambiguous.

  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 for canonical formatting of Carve source, so an agent could infer when it applies. However, there is no explicit guidance on when to choose this over carve_lint, carve_render, or carve_migrate, nor any 'when not to use' conditions.

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

• carve_renderA
  3.5/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 description does not need to restate safety. The phrase 'with loss reporting' adds a behavioral detail, but it is vague and does not clarify what the loss report contains, how it is returned, or whether it accompanies the rendered output.

  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?

  A single, front-loaded sentence communicates the core purpose, output variants, and an additional behavioral note. Every word earns its place; there is no repetition of schema properties or annotation 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 tool is simple with only two parameters, and annotations cover safety, but there is no output schema. The description does not explain the expected return value or the semantics of the loss report, leaving an agent uncertain about what the invocation will actually produce beyond the chosen format.

  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%, so the description carries some of the burden. It repeats the target enum values and clarifies that the source is a Carve document, but it does not add meaningful detail beyond the schema for 'source' or explain constraints/pitfalls of each target format. The description is adequate but not compensatory.

  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 states a specific action ('Render Carve') and enumerates the exact output formats: HTML, Markdown, plain text, and ANSI terminal text. This clearly distinguishes the tool from its siblings (carve_lint, carve_format, carve_parse, carve_migrate) by focusing on conversion/rendering rather than analysis or mutation.

  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 gives no explicit guidance on when to use this tool versus alternatives like carve_parse or carve_format. The usage is only implied by the tool's name and the listed output formats; there is no mention of when rendering is appropriate or inappropriate, nor any exclusions.

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

• carve_lintA
  3.6/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 safety profile is covered. The description adds useful context about what the linter detects ('author-facing problems and silent degradation'), but it does not disclose return format, error behavior, or whether any action is taken. The read-only annotation mitigates the need for mutation details.

  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?

  One short sentence that is front-loaded with the action ('Check') and the resource ('Carve source'). Every word contributes to the purpose; there is no redundancy.

  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 two parameters, no output schema, and read-only annotations, the description is mostly sufficient for a simple linting operation. The main gaps are the unexplained `platforms` parameter and the fact that the return value (e.g., diagnostics list) is not specified. An agent could infer behavior from the verb 'Check', but it is not fully explicit.

  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 tool description adds no parameter-level meaning. The `source` parameter is described in the schema, but `platforms` has no schema description and the tool description also does not explain what `platforms` controls. With 50% schema coverage, the description should compensate for the undocumented `platforms` parameter, but it does not.

  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' with the resource 'Carve source' and specifies the goal: detecting 'author-facing problems and silent degradation.' This clearly distinguishes it from siblings carve_format, carve_render, carve_parse, and carve_migrate, each implying a different operation.

  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 this is the linting/validation tool for Carve source, but it does not explicitly state when to use it over siblings or when not to use it. There are no exclusions or alternative routing; the agent must infer from the name and the verb 'Check' that this is the validation tool.

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

• carve_parseA
  4/5.0
  Behavior3/5

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

  Annotations already provide readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds useful output context by specifying that the result is a 'position-aware' AST, but it does not disclose behavior around errors, resolution failures, 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.

  Conciseness5/5

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

  The description is a single well-formed sentence that immediately states the operation, the input, and the output. There is no redundant or filler content.

  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?

  The tool is simple with one required parameter and annotations covering safety, and the description tells the agent exactly what the tool produces. The lack of an output schema makes the 'position-aware interchange AST' mention valuable, though more detail about resolution behavior or error conditions would make it fully complete.

  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%, and the single 'source' parameter is already documented as 'Document source (maximum 1000000 UTF-8 bytes)'. The description does not add meaningful parameter-level details beyond what the schema provides, so the baseline score of 3 is appropriate.

  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 ('Parse and resolve') and a specific resource ('Carve'), and names the exact output ('position-aware interchange AST'). This clearly distinguishes it from the sibling tools carve_lint, carve_format, carve_render, and carve_migrate.

  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 states that this tool is for parsing and resolving Carve into an AST, which gives the agent a clear context for when it should be used. It does not explicitly name alternatives or exclusions, but the operation is distinct enough from lint, format, render, and migrate.

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

• carve_migrateA
  4.1/5.0
  Behavior4/5

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

  Annotations already cover the read-only, non-destructive safety profile. The description adds value by disclosing that conversion produces 'fidelity diagnostics', which tells the agent to expect quality/compatibility feedback beyond the converted output. This is meaningful behavioral context beyond 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.

  Conciseness5/5

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

  The entire description is one front-loaded, information-dense sentence. Every phrase earns its place: the migration action, the supported formats, the target, and the diagnostics behavior. There is no filler or repetition of schema details.

  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?

  For a two-parameter tool with read-only annotations, the description is mostly sufficient, but with no output schema it does not clarify what the result looks like beyond 'fidelity diagnostics'. It also does not mention edge cases, formatting details, or whether output is returned as text or a structured object. A bit more return-shape context would help.

  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 50%: 'source' has a description with size limits, and 'format' has an enum but no description. The description restates the format options in prose but does not add new parameter meaning, such as format detection, normalization behavior, or how source content is interpreted. This is adequate but not compensatory.

  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 names a specific action ('Migrate'), a clear resource ('HTML, Markdown, or Djot source'), and a target format ('Carve'). It also adds a distinctive behavioral detail ('with fidelity diagnostics') that separates it from obvious siblings like carve_parse or carve_render.

  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 context is clear: use this tool when you have HTML, Markdown, or Djot source and want to convert it to Carve. It does not explicitly name sibling tools or exclusion conditions, but the migration-focused wording sufficiently distinguishes it from lint, format, render, and parse.

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