FD Solutions MCP Server

Overview Schema Source Related Servers Discussions Admin

Run / solve

run_action

Launches photonic simulation solvers, parameter sweeps, and analysis scripts, and polls job status to manage runs without duplicate starts.

Instructions

Run solvers, sweeps, or analysis scripts.

Confirm with the user before action=run / run_sweep / eme_sweep. If the call blocks until done and the MCP request times out, the solver may still be running in SimWorks — do not issue a second start to "retry" a timeout.

Input Schema

Name	Required	Description
`action`	Yes	run: launch simulation (confirm with user first). status: poll FDTD simulation status (use after run / timeout). solve_mode: FDE mode solve. run_setup: structure-group setup script. run_analysis: analysis-group script. eme_propagate: EME propagation. run_sweep: runsweep — all sweeps, or named sweep via object_name (confirm first; long-running). eme_sweep: emesweep — optional eme_sweep_mode (propagation / wavelength / mode convergence); confirm first. resource_info: getresourceinfo — CPU/GPU resource listing. IMPORTANT: an MCP/client timeout on run / run_sweep / eme_sweep does NOT mean the job failed to start — do NOT call the same action again. Poll status when applicable. Only re-run if the user explicitly asks.
`object_name`	No	Optional target: solve_mode / run_analysis object path; run_sweep sweep name (omit = all sweeps).
`eme_sweep_mode`	No	For action=eme_sweep only. Omit or 'propagation sweep' for default; 'wavelength sweep'; 'mode convergence sweep'.

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Oct 29, 2026

TDQS

A3.9/5.0

Behavior4/5

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

No annotations are provided, so the description carries the full behavioral burden, and it does disclose the key non-obvious trait: a timeout does not mean the job failed to start, and the solver may still be running in SimWorks. It stops short of saying which actions block versus return immediately, and doesn't cover permission or side-effect scope.

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?

Two short sentences, front-loaded with the purpose and then the safety rule. There is minor noise from stray quotation marks and a trailing newline, but nothing wasteful in content.

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?

For a three-parameter multiplexed action tool with a full output schema and per-enum documentation, the description supplies the one thing the structured fields can't: the timeout/retry hazard. Only the absence of sibling routing and blocking-behavior detail keeps it from a 5.

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% and the action enum is documented per-value, so the baseline is 3. The description reinforces the confirmation requirement for specific action values but adds no syntax or format detail beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource set: running solvers, sweeps, and analysis scripts. The enum in the schema makes the scope concrete. It does not, however, name which sibling tool to use instead for adjacent jobs (e.g. jobs_action for job management), so differentiation is left to inference.

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?

Gives a clear conditional rule — confirm with the user before action=run / run_sweep / eme_sweep — and explains the timeout recovery path. What it lacks is routing guidance across siblings or when-not-to-use cases beyond the confirmation gate.

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