Server Quality Checklist

Tool Scores

• fillA
  3.6/5.0
  Behavior3/5

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

  No annotations provided, so description bears full burden. It mentions deterministic CadQuery and no network call, which are helpful. However, it does not disclose error handling, performance characteristics, or any side effects. More detail would improve transparency for a complex tool.

  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, information-dense sentence that efficiently captures the tool's purpose, input constraints, and key features. It is front-loaded and free of fluff, though splitting into two sentences could improve readability.

  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 tool's complexity (7 params, many shape options) and no output schema, the description covers input format, shape types, deterministic behavior, and no network use. It lacks explicit output description (e.g., format or file type) and has no annotations. Fairly complete but could add more context.

  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?

  With 57% schema description coverage, the description adds value by summarizing shape types and mentioning tapered (hinting bottomShape is optional). It clarifies input format (JSON only). But many detailed constraints are left to the schema; description does not fully compensate for gaps.

  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 generates a solid plug to fill holes/cavities, lists all supported shapes (circular, rectangular, stadium, polygon, freeform), and mentions uniform or tapered options. This distinguishes it from sibling tools like caps or meshes.

  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 does not explicitly state when to use this tool versus alternatives. However, sibling tool names (caps, meshes, repairs) are distinct, and the description implies JSON-only input. No explicit when-not or alternative recommendations, but the shape-specific schema descriptions provide guidance within the tool.

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

• generate_precise_capA
  4.2/5.0
  Behavior4/5

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

  No annotations provided, so description carries full burden. It discloses deterministic CadQuery and no network call, giving insight into reliability and offline behavior. Does not mention side effects or resource usage, but for a generation tool these are secondary.

  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?

  Three sentences packed with essential information: what it generates, input constraints, and behavioral traits. No wasted words, front-loaded with the main purpose.

  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 8 parameters with 100% schema coverage, no output schema, and no annotations, the description covers the tool's purpose, input constraints, and behavior. Could mention return format or size limits, but overall 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?

  Schema description coverage is 100% (all parameters have descriptions in schema). The description does not add per-parameter meaning beyond the high-level summary, so baseline 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?

  Description clearly states it generates a threaded cap STL/STEP from measured dimensions, specifying the output format (STL/STEP) and key features (solid closed top, skirt, helical internal threads). It distinguishes itself from sibling tools like fill, generate_visual_mesh, and repair_mesh by being for cap generation from dimensions.

  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?

  Explicitly mentions it takes structured JSON only and that vision/dimension extraction happens client-side before calling this tool, clarifying when to use it. No explicit alternatives or when-not-to-use guidance, but the context is clear.

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

• repair_meshA
  4.2/5.0
  Behavior4/5

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

  With no annotations, the description covers key behaviors: removal of non-manifold edges, hole filling, normal unification, optional remeshing, and returning base64 + summary. It lacks details on side effects or limitations like potential detail loss.

  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 purpose, then input/output. Every sentence adds value; no 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?

  Given 7 parameters and no output schema, the description covers core functionality and input/output well. It could elaborate on repair levels and the repair summary, but overall is sufficiently complete for a complex tool.

  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?

  All 7 parameters have schema descriptions (100% coverage). The tool description adds context on input sources and output format but does not significantly enhance parameter meaning beyond schema defaults.

  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 repairs a 3D mesh to be manifold, watertight, and print-ready, listing specific actions. It distinguishes from siblings like generate_visual_mesh by mentioning it accepts output from that tool.

  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 specifies input sources (URL from generate_visual_mesh or base64) and output (repaired STL plus summary). It implies when to use (need repair) but does not explicitly exclude scenarios or provide alternatives.

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

• generate_visual_meshA
  4.5/5.0
  Behavior4/5

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

  No annotations provided, so description carries full burden. It discloses that output is not dimensionally precise and is for visualization only. Missing details on error handling or if image is invalid, but sufficient for the tool's simplicity.

  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?

  Three concise sentences with no fluff: purpose, usage caveat, and next step. Front-loaded and efficient.

  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 has only one parameter and no output schema or annotations, the description covers everything needed: what it does, when to use, limitations, and what to do with the output. Complete for the context.

  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% with adequate parameter description. The tool description adds no new information about the parameter beyond what the schema provides, so baseline score of 3 applies.

  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 it generates a 3D mesh from a raw image via the Meshy API and returns an STL file. It distinguishes from siblings by specifying it's for visualization only and not dimensionally precise.

  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 (visualization only) and when not to use (cap/plug requiring fit). Provides a follow-up step to feed output into repair_mesh.

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