Loading ToolBench
MCP server for TIA Portal integration, providing PLC code analysis, compilation management, hardware configuration, and data delivery tools for Siemens automation projects
This MCP server exhibits significant definition quality gaps across nearly all 20 tools. While tool names follow verb_noun conventions (analyze_, get_, find_, trace_, generate_), the majority of tools lack complete input parameter descriptions and explicit output schemas. Parameter descriptions are present but often generic ('XML content of the block', 'Dict of {block_name: xml_content}'). The server provides no evidence of output schema documentation, error handling guidance, or parameter constraints (enums, ranges, validation rules). All tools are READ_ONLY, which is correct, but the documentation does not explicitly state this across all tool descriptions. The fundamental issue is that LLMs cannot reliably select and invoke these tools without better parameter guidance, output field documentation, and error recovery hints.
Comprehensive analysis of a single block's code. Returns code_type, line_count, complexity_metrics, used_tags, called_blocks, and warnings
Perform deep complexity analysis on a single block. Returns cyclomatic_complexity, cognitive_complexity, nesting_depth, line_count, comment_ratio, and maintainability_index
Detailed analysis of block interface (inputs, outputs, statics, etc). Returns parameter_count, interface_complexity, naming_consistency, documentation_coverage, and potential_issues
Analyze compilation dependencies between blocks. Returns dependency_graph, circular_dependencies, compilation_order, and unreachable_blocks
Analyze compilation status across entire project. Returns success status, compiled blocks count, errors, warnings, compilation time, and memory usage
Analyze complete hardware configuration. Returns devices list, network_topology, io_configuration, and communication_paths
No documented output schemas for any tool. Tools return complex dataclass objects (BlockDependency, SignalFlow, InterlockChain, CodePattern) but LLMs have no explicit field documentation to understand the response structure. This forces LLMs to guess at field names and types, increasing downstream errors.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 51 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 48 | - | v1 |
Compare two blocks to identify differences. Returns differences in code, interface, behavior, and recommendations
Extract and visualize the logic flow of a block. Returns flow_type, decision_points, execution_paths, loops, state_machines, and flow_diagram
Detect common code smells and anti-patterns in PLC code. Returns list of detected issues with severity and suggestions
Find inconsistencies in I/O configuration. Returns list of inconsistency descriptions with types and messages
Generate compilation report in specified format. Supports text, html, and json formats
Generate hardware configuration report in specified format. Supports text, json, and csv formats
Get block data with minimal processing. Returns block metadata, operand paths, raw XML content, and equipment references
Analyze dependencies between all blocks in a project. Returns list of BlockDependency objects showing calls, DB usage, and UDT relationships
Extract compilation errors from project. Returns list of CompilationError objects with error_code, severity, message, block_name, line_number, column, and suggestion
Get diagnostic information for a specific device. Returns device status, errors, warnings, properties, and modules
Get high-level project overview with operand statistics. Returns project_name, plc_count, total_blocks, blocks_parsed, total_operands, export_timestamp, and block_summary
Search for equipment references across all blocks. Returns list of EquipmentReference objects with context
Trace signal flow from start_tag to end_tag through all blocks. Returns SignalFlow with read/write locations and intermediate blocks
Validate block for common consistency issues. Returns is_valid status, detected issues, suggestions, and overall score
Parameter descriptions are generic and non-actionable. Example: 'Dict of {block_name: xml_content}' does not explain the expected structure, format requirements, size limits, or what constitutes valid XML. LLMs cannot validate inputs before passing them.
Tools accepting project_obj (TIA Portal project object) or device_obj provide no guidance on how to obtain these objects, what fields they contain, or how to validate them. These are opaque dependencies that are not self-discoverable by agents.
No error handling guidance. Tools in the source code catch exceptions and return {'error': str(e)}, but there is no documented error classification (retryable vs user-fixable vs fatal), no recovery hints, and no examples of error responses. Agents cannot reason about failures.
generate_compilation_report and generate_hardware_report accept a 'format' enum with values [text|html|json|csv], but there is no documentation of what each format produces, when to use each, or whether the output is a string, file URI, or structured object.
No parameter constraints declared. Numeric parameters (line_count, line_number, page_size if added) lack min/max bounds. String parameters lack regex patterns, length limits, or allowed character sets. XML parameters lack validation requirements (well-formed, schema, encoding).
Tools returning lists (get_block_dependencies, find_code_smells, get_compilation_errors, find_io_inconsistencies) provide no pagination support (limit, offset, next_cursor) and no total count. Large result sets will blow context windows and degrade LLM reasoning.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). While all 20 tools are READ_ONLY by design, this is not declared in the tool metadata, forcing LLMs to infer safety from descriptions alone.
Composition risk: tools like get_block_dependencies and trace_signal_path both require a 'project_blocks' dict parameter. There is no discovery tool to help agents construct this dict, and no guidance on the structure. Agents will struggle to chain these tools together.
Inconsistent parameter naming. Some tools use 'xml_content', others use 'project_blocks' or 'project_obj'. When similar tools operate on the same resource (block XML), the naming should be consistent to help LLMs understand equivalences.