Loading ToolBench
This is a well-structured DWG file manipulation server with 11 tools covering document lifecycle, querying, and rendering. Tool naming follows verb_noun convention consistently (open_file, list_types, query_objects). Descriptions are generally comprehensive and explain prerequisites and intent. Input schemas are present and mostly complete with proper type declarations. However, several parameters lack descriptions, and some complex nested objects (whereClauses, scope, relations, sort in dwg.query_objects) are defined as generic 'object' types without detailed structure documentation. Output schemas are not documented in the provided source, which limits LLM planning capability. Error handling is mentioned as present (errorReporting=true) but specifics are not visible in the code samples. The server uses STDIO transport, which caps protocol readiness but does not affect definition quality scoring.
Close a previously opened document and release worker resources.
Describe a supported DWG type, including aliases, properties, and default select fields.
Fetch objects by handle from an opened DWG. Preserves input order and reports missing handles.
List types present in an opened DWG. Use this after open_file to discover valid typeName values.
List available render views for the opened DWG document.
List roots that can be used with dwg.open_file. Uses MCP client roots when the client provides them, otherwise uses server-configured allowed roots.
dwg.query_objects has complex nested parameters (whereClauses, scope, relations, sort) defined as generic 'object' type without documented structure. LLMs cannot infer the shape of these objects, leading to malformed queries.
Output schemas are not documented in the tool definitions. LLMs cannot predict the structure of responses from dwg.get_objects, dwg.query_objects, dwg.render_view, or any discovery tools, limiting their ability to chain operations or extract specific fields.
Parameters in dwg.query_objects (whereClauses, scope, relations, sort) lack descriptions explaining their structure, acceptable keys, or format. This violates the 'every parameter needs a description' rule.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | B | 76 | 2025-06-18+ | v2 |
List globally supported DWG types (not file-specific). Supports regex filtering and cursor pagination.
Open a DWG or DXF from a listed root and return documentId. Call dwg.list_roots first, then provide one returned rootUri and a relativePath under that root.
Query objects in an opened DWG using filters, scope, relations, sorting, and pagination.
Render a view of the opened DWG document as an image.
Update writable properties of a block reference entity in an opened DWG.
The 'select' parameter in dwg.get_objects, dwg.set_entity_properties, and dwg.query_objects is documented as 'Optional property names to include' but does not specify what property names are valid, how to discover them, or formatting constraints.
dwg.set_entity_properties accepts a 'properties' object (name->value mapping) with no description of valid property names, value types, or constraints. This forces LLMs to call dwg.describe_type first to discover writable properties, adding latency.
List tools (dwg.list_types, dwg.list_file_types) accept 'limit' and 'cursor' parameters. No documentation of pagination semantics: does cursor come from a previous response? What does an opaque cursor contain? How is totalCount returned?
No visible error handling documentation or examples. The 'errorReporting=true' feature flag indicates error handling exists, but the code samples do not show error message structure, recovery guidance, or error classification.