Loading ToolBench
MCP server for LLM-assisted engineering drawing generation (BFD/PFD/P&ID) using DEXPI and SFILES formats
This server has significant definition quality gaps that prevent confident production use. Of 9 tools, 6 have acceptable schemas but descriptions are either missing entirely, cryptically brief, or contain problematic migration notices that undermine clarity. Parameter descriptions are sparse or absent. No input validation guidance is provided. Error handling strategies are not documented. The batch operations (model_batch_apply, rules_apply, graph_connect) lack clarity on failure modes and recovery paths. Tools marked as '[Consolidated into]' or '[Available via]' create confusion about which tools agents should actually call. Schema completeness is moderate (7/9 tools have visible input schemas), but several schemas are under-specified (e.g., graph_modify lacks properties for its actions; rules_apply lacks detailed rule_set definitions). Output schemas are entirely undocumented. The domain is specialized (engineering P&ID/PFD/BFD), which justifies technical parameters, but descriptions do not adequately explain WHEN or WHY an agent should call each tool.
Generate PFD expansion options for a BFD block. Suggests equipment breakdowns based on process type. Returns multiple expansion options with typical configurations.
[Available via model_tx_apply or direct call] Add equipment to the P&ID model (159 types available). Supports both SFILES aliases and DEXPI class names. Examples: 'pump' (CentrifugalPump), 'boiler' (Boiler), 'conveyor' (Conveyor), 'steam_generator' (SteamGenerator), 'crusher' (Crusher). See docs/FEATURE_PARITY_MATRIX.md for migration guide.
[Available via model_tx_apply or direct call] Add instrumentation to the P&ID model (34 types available). Supports both SFILES aliases and DEXPI class names. Examples: 'transmitter' (Transmitter), 'positioner' (Positioner), 'actuator' (ControlledActuator), 'signal_conveying_function' (SignalConveyingFunction). See docs/FEATURE_PARITY_MATRIX.md for migration guide.
[Available via model_tx_apply or direct call] Add piping component to the P&ID model (79 types available). Supports both SFILES aliases and DEXPI class names. Includes valves, flow measurement, connections, fittings, etc. Examples: 'pipe' (Pipe), 'electromagnetic_flow_meter' (ElectromagneticFlowMeter), 'flange' (Flange), 'orifice_plate' (OrificeFlowMeter). See docs/FEATURE_PARITY_MATRIX.md for migration guide.
Deprecation notices in descriptions undermine tool clarity. Tools dexpi_create_pid, dexpi_add_equipment, dexpi_add_piping, dexpi_add_instrumentation all begin with '[Consolidated into]' or '[Available via]' instead of explaining what the tool does. LLM cannot determine whether to call the tool, what alternative to use, or how the tool fits into the workflow.
graph_modify tool schema is severely incomplete. The schema declares only 'model_id' and 'action' as parameters, but the description references 10 distinct actions (insert_component, remove_component, etc.) that surely require additional parameters (component_id, component_type, etc.). These parameters are missing from the visible schema, violating the principle that input schemas must match the tool's functionality.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 47 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 43 | - | v1 |
[Consolidated into model_create] Initialize a new DEXPI P&ID model with metadata. See docs/FEATURE_PARITY_MATRIX.md for migration guide.
Smart autowiring with patterns and optional inline components
Apply tactical graph modifications (10 actions: insert/update/remove component, inline insertion, segment operations, etc.)
Execute multiple operations in a single call for efficiency
Apply validation rules and return structured issues for LLM processing. Optionally auto-fix issues.
Output schemas are entirely absent for all 9 tools. LLM cannot predict the structure of responses, making it impossible to chain tools or extract relevant fields. This violates the pattern that every tool must document its return type and structure.
Parameter descriptions are sparse or absent for critical parameters. Examples: 'segment_id' in dexpi_add_piping is required but has no description; 'connected_equipment' in dexpi_add_instrumentation is described only as 'Tag of connected equipment' (no explanation of format or scope); 'params' in model_batch_apply is described as 'Parameters for the tool' (circular and unhelpful). LLM cannot infer parameter semantics without guidance.
Domain-specific concepts are unexplained. Terms like 'CS150' (pipe class), 'SFILES aliases' vs 'DEXPI class names', 'BFD block', 'segment', and 'nozzle' are used without definition. Agents cannot reason about these concepts without documentation.
No error handling guidance. Tools do not document what errors can occur (e.g., duplicate tag names, invalid equipment type, validation rule failures), whether errors are retryable, or what the agent should do next. This violates the recovery-guide pattern.
Batch operation failure semantics are unclear. model_batch_apply has a 'stop_on_error' flag, but no description of per-operation results or partial success handling. How does the agent know which operations succeeded and which failed? What is returned when stop_on_error=false?
Strategy selection guidance is absent. graph_connect offers 'by_port_type' vs 'pumps_to_header' strategies with no explanation of when to use each, what assumptions each makes, or typical results. Agent must guess.
Autofix behavior is under-specified. rules_apply has an 'autofix' boolean, but documentation does not clarify which issue types can be auto-fixed, what auto-fixes are applied, or what manual intervention is needed. This violates the principle of actionable tool descriptions.