Loading ToolBench
Model Context Protocol (MCP) server for Ansys Lumerical through PyLumerical
PyLumerical MCP demonstrates solid foundational quality with well-structured tool definitions and comprehensive descriptions. All 7 tools have clear, detailed descriptions (avg ~180 chars) that explain WHAT, WHEN, and consequences. Input schemas are present and properly typed with enums where appropriate (e.g., product enum in open_session). However, output schemas are not documented, responses are described as 'JSON-safe envelope' but the actual structure is not specified. Error handling descriptions are present but lack actionable recovery guidance in most tools. Tool composition is clean (each does one thing), and naming follows verb_noun convention. The execute_python_code tool is particularly well-described with guidance to avoid inventing APIs. Missing: explicit output schema documentation, per-parameter validation rules, and structured error classification.
Close a Lumerical session and remove it from the registry. Bounded by :data:`_CLOSE_SESSION_TIMEOUT_S`. On timeout, returns a failure envelope with ``timed_out=True`` and ``retained=True`` so the agent can dispatch ``restart_session`` to recover. The orphaned worker thread is left to drain on its own (asyncio cannot cancel it).
Execute arbitrary Python code in the persistent subprocess and return a JSON-safe envelope with success/failure, stdout, stderr, and error summary. Use _lum_print_json(...) for structured output. Avoid inventing lumapi APIs; call get_guidelines_for before writing Lumerical scripting code you are unsure about. The envelope is size-capped to prevent context bloat.
Retrieve Lumerical workflow guidance and best practices. Call this before generating Lumerical Python code. Start with 'workflow', then fetch only the task-specific topics (for example fdtd_workflow, geometry, materials, sweeps, fdtd_results).
List all open Lumerical sessions with their metadata (name, product, filename, hide flag, opened_at timestamp).
Toolset definitions consumed by MCP clients and Ansys product UIs.
Output schemas not documented. Tools return 'JSON-safe envelope' or 'metadata' but the actual response structure (fields, types, nesting) is not specified. LLMs cannot plan downstream operations without knowing what fields to extract.
Error handling lacks actionable recovery guidance. close_session mentions 'timed_out=True' and 'retained=True' fields but does not explain what the LLM should do next. execute_python_code mentions 'error summary' but does not specify format or how to interpret failures.
Parameter validation rules not specified. execute_python_code accepts arbitrary Python code with no constraints documented. get_guidelines_for accepts 'topic' but does not enumerate valid topics or explain fallback behavior for unknown topics.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 65 | 2025-06-18+ | v2 |
Open a Lumerical CAD session and register it under ``name``. Multiple sessions of any product type may be open concurrently. Each is addressable by the ``name`` you choose here. Returns a JSON-safe dictionary envelope (delivered to the client as MCP ``structuredContent``) with success/failure plus session metadata. Common failures include duplicate name, invalid product, and license-server errors. The call blocks until the subprocess finishes the open. If a Lumerical product wedges (such as a license-server hang), dispatch a parallel ``restart_session`` tool call to recover.
Restart the persistent Python subprocess that hosts all Lumerical sessions. Use this to recover from a wedged subprocess or license-server state. All open sessions are lost; the registry is cleared.
Tool composition: execute_python_code is extremely broad (arbitrary code execution). While descriptions warn against inventing APIs, there is no mechanism to prevent LLMs from executing unsafe or incorrect code. Consider narrowing scope or adding a dry-run/confirmation pattern.
list_sessions and list_tool_sets lack pagination parameters (limit, offset, cursor). If session count or toolset count grows large, responses could bloat context. No documented result limits.