Server Quality Checklist

Tool Scores

• extract_drawing_textA
  4.2/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true, indicating a safe read operation. The description adds behavioral details: it returns token index, text, position, rotation, page geometry, and a heuristic unit system guess. It also notes it's per-page. No contradictions or hidden behaviors are present.

  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 consists of two sentences: the first introduces the tool's output, and the second explains its purpose using token indices. Every sentence adds value with no padding. The structure is clear and front-loaded.

  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?

  Given no output schema, the description explains the output in sufficient detail: token index, text, position, rotation, page geometry, and unit system guess. It also clarifies the relationship with convert_drawing_pdf. Missing error handling details, but for a read-only extraction tool, this is adequate.

  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 covers 100% of parameters with descriptions for 'path' and 'page'. The description adds no new parameter-level details beyond stating that page is optional and 1-based (already in schema). Baseline 3 is appropriate as the schema already does the heavy lifting.

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

  Purpose5/5

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

  The description 'Read the printed text tokens of one page of a technical-drawing PDF' specifies a clear verb ('read') and resource ('printing text tokens of a technical-drawing PDF'). It distinguishes itself from siblings like convert_drawing_pdf, which converts the whole PDF, and convert_value/convert_text, which handle individual values. The purpose is unique and unambiguous.

  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 explicitly states when to use this tool: 'Use the token indices to build classifications for convert_drawing_pdf when you want to decide yourself which tokens are convertible values'. It implies a specific workflow. However, it does not explicitly mention when not to use it or alternatives, though the sibling context makes differentiation clear.

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

• convert_valueA
  4.3/5.0
  Behavior4/5

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

  Annotations indicate read-only safe operation. Description adds value by detailing return structure (exact value, display-rounded, derivation, confidence), which goes beyond annotations. No contradictions.

  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?

  Description is informative and well-structured: first sentence states purpose, then lists kinds with examples, then return structure. Efficient but packs necessary detail.

  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?

  Despite no output schema, description explains return values and derivation method clearly. Covers all kinds and parameter constraints. Could mention error handling or edge cases, but overall complete for typical use.

  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 covers 75% of parameters with descriptions. Description adds context: explains each kind, gives examples, and clarifies that value is required except for thread. This compensates for the schema's lack of description for the 'kind' parameter.

  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?

  Description clearly states it converts engineering values between metric and imperial, lists specific kinds with examples, and distinguishes from sibling tools like convert_text (text conversion) and lookup_thread (thread lookup).

  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?

  Description provides clear context on when to use (for engineering conversions) and lists supported kinds, but does not explicitly state when not to use or suggest alternatives, though sibling tool names provide implicit guidance.

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

• lookup_threadA
  4.4/5.0
  Behavior4/5

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

  The description adds behavioral context beyond annotations (readOnlyHint=true): it returns the closest standard counterpart, major diameters, pitch/TPI, and match closeness. It also reveals special behavior (full chart when designation omitted). No contradictions with 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 description is two concise sentences. The first sentence covers purpose and outputs; the second covers special behavior. No wasted words, and essential information is front-loaded.

  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?

  Given no output schema, the description adequately explains return values (major diameters, pitch/TPI, closeness). It covers the optional parameter behavior. A minor gap: it doesn't clarify if multiple matches are possible or if the closest match is exact.

  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 100%, and the description enriches the parameter 'designation' with examples (e.g., 'M8', '5/16-18 UNC') and the key behavior of omitting for full chart. This adds practical meaning beyond the schema description.

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

  Purpose5/5

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

  The description clearly states the tool's purpose: 'Look up the closest standard counterpart of a thread designation (ISO metric coarse ⇄ Unified UNC), with major diameters, pitch/TPI and how close the match is.' It uses a specific verb ('look up') and resource ('thread designation'), and distinguishes from siblings (conversion/extraction 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 provides clear usage context: cross-referencing metric and inch threads. It also hints at when to omit the parameter ('omit `designation` to get the whole cross-reference chart'). However, it does not explicitly state when not to use or mention alternatives, though siblings are clearly different.

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

• convert_drawing_pdfA
  4.6/5.0
  Behavior4/5

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

  The description confirms the input is never modified (consistent with destructiveHint=false) and notes that converted values are stamped over originals. It adds a safety warning about verifying critical dimensions, which provides context beyond what annotations convey about idempotency and non-destructiveness.

  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 concise (~100 words), front-loaded with the core function, and every sentence contributes essential information (modes, prerequisites, limitations, safety warning). 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?

  Covers purpose, input/output, modes, prerequisites, and limitations. While no output schema exists, the description implies the output is a file at the specified path. Missing explicit return value details, but sufficient for a file-generation tool with high schema coverage.

  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 description coverage is 100%, so baseline is 3. The description adds value by explaining the interplay between heuristic and classification modes, linking to specific parameters (classifications, bare_numbers). It also describes default output path behavior, integrating parameter usage into an actionable workflow.

  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 ('produce a converted copy'), resource ('technical-drawing PDF'), and outcome ('every recognised value stamped in place'). It distinguishes from siblings by focusing on PDF conversion with stamping, while other tools handle individual values or text extraction.

  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?

  Explicitly states when to use heuristic mode vs. classification mode, prerequisites (PDF with text layer), and alternatives for scanned drawings (web app) or preparatory step (extract_drawing_text). This provides clear guidance on when and how to use the tool.

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

• convert_textA
  4.7/5.0
  Behavior5/5

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

  Beyond the readOnlyHint annotation, the description discloses detailed behavioral traits: angles left unchanged, how bare numbers are interpreted based on category, the fallback with assume_lengths, and specific conversion examples. There is no contradiction with 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 description is concise yet packed with information: examples, behavior rules, and parameter explanations. It is front-loaded with the core purpose and uses multiple sentences that each add value without redundancy.

  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 description covers key aspects: unit conversion, notation preservation, category effects, and assume_lengths use. However, it lacks detail on return format (e.g., does it return converted text or structured output?) and error handling for unrecognized patterns, leaving minor gaps given the tool's complexity and no 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?

  The description enriches the schema by explaining the 'text' parameter (as callout string), the effect of 'category' on number interpretation, and the use case for 'assume_lengths'. It compensates for the missing schema description on 'text' by context. The examples clarify parameter semantics.

  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 converts printed drawing callouts between metric and imperial while preserving notation. It provides concrete examples and distinguishes itself from sibling tools (e.g., convert_value, lookup_thread) by focusing on callout text with complex patterns.

  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 gives good guidance on when to use this tool (converting callout strings) and explains parameter nuances (category for surface roughness, assume_lengths for tolerance rows). However, it doesn't explicitly mention when not to use it or direct users to alternative sibling tools.

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