Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@tidy3d-research validate the simulation JSON and estimate FlexCredit cost"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
一个独立的 Tidy3D MCP 服务，用于声明式 FDTD 配置校验、受控云端任务流程，以及把 Tidy3D 结果归一化为元数据和有限的 CSV 观测数据。它与应用层 tutor 解耦，不会把 Tidy3D 凭据或云端执行权限加入其他服务。
An independent Tidy3D MCP server for declarative FDTD validation, guarded cloud-task workflows, and normalization of Tidy3D results into metadata plus bounded CSV observables. It is decoupled from application-level tutors and does not add Tidy3D credentials or cloud-execution privileges to other services.
本仓库是 Industrial_Local_Agent superproject 的独立 child component；父仓库通过 components/tidy3d-research-mcp submodule 固定本仓库的具体 commit。
This repository is an independent child component of the Industrial_Local_Agent superproject; the parent pins its exact commit through the components/tidy3d-research-mcp submodule.
Related MCP server: polyflow
cd tidy3d-research-mcp
python3 -m venv .venv
.venv/bin/python -m pip install -e '.[dev]'
.venv/bin/pytestTidy3D 认证使用官方客户端配置，不把 key 写入仓库。可以使用 SIMCLOUD_APIKEY 环境变量，或在本机执行 tidy3d configure。服务本身不会返回、记录或转发 key。
Tidy3D authentication uses the official client configuration; the key is never stored in this repository. Use the SIMCLOUD_APIKEY environment variable or run tidy3d configure locally. The server never returns, logs, or forwards the key.
在 MCP 客户端中配置 STDIO server：
Configure a STDIO server in the MCP client:
{
"mcpServers": {
"tidy3d-research": {
"command": "path/to/tidy3d-research-mcp/.venv/bin/tidy3d-research-mcp",
"env": {
"TIDY3D_MCP_WORKSPACE_DIR": "path/to/your/project"
}
}
}
}默认只允许本地校验和结果读取。云端 upload/start 必须同时满足：
Cloud upload/start requires all of the following:
TIDY3D_MCP_ALLOW_CLOUD_SUBMISSION=1；
MCP 调用参数中的显式确认；
start_simulation 提供正的 max_flexcredits，且预估成本不超过上限。
TIDY3D_MCP_ALLOW_CLOUD_SUBMISSION=1;
explicit confirmation in the MCP call;
a positive max_flexcredits on start_simulation, with the estimate at or below that cap.
export TIDY3D_MCP_ALLOW_CLOUD_SUBMISSION=1这不是预算保证；FlexCredit 价格和账户限制由 Tidy3D 服务端决定。执行前仍需人工检查配置、预估成本和研究授权。
This is not a budget guarantee; FlexCredit pricing and account limits are controlled by the Tidy3D service. A researcher must still inspect the configuration, estimate cost, and confirm authorization before execution.
validate_simulation：校验序列化的 tidy3d.Simulation JSON，返回 digest、配置摘要和科学复核标记。
upload_simulation：在显式确认后上传草稿，但不启动求解。
estimate_task_cost：读取任务的最大 FlexCredit 预估。
start_simulation：在显式确认、环境开关和成本上限都满足后启动任务。
get_simulation_status：读取任务的 allowlisted 状态字段。
download_simulation_result：在显式确认后下载到私有 artifact 目录，并生成归一化摘要。
normalize_local_result：只读取 TIDY3D_MCP_WORKSPACE_DIR 下的相对路径，拒绝绝对路径、路径穿越和 symlink。
read_normalized_artifact：读取由本服务生成的 metadata.json 和受限 observables.csv。
validate_simulation: validate serialized tidy3d.Simulation JSON and return a digest, configuration summary, and scientific-review flags.
upload_simulation: upload a draft after explicit confirmation without starting the solver.
estimate_task_cost: read the maximum FlexCredit estimate for a task.
start_simulation: start only after explicit confirmation, the environment gate, and a cost cap pass.
get_simulation_status: read allowlisted task-status fields.
download_simulation_result: download after explicit confirmation into a private artifact directory and normalize it.
normalize_local_result: read only a relative path under TIDY3D_MCP_WORKSPACE_DIR; absolute paths, traversal, and symlinks are rejected.
read_normalized_artifact: read the generated metadata.json and bounded observables.csv.
MCP 接口不接受 Python 代码，不执行模型生成的代码，不提供 shell、任意 URL、任意路径、删除任务或 key 管理工具。结果是仿真证据，不是实验验证；网格/时间收敛必须由研究人员设计并检查。
The MCP accepts no Python code, executes no model-generated code, and exposes no shell, arbitrary URL, arbitrary path, task deletion, or key-management tool. Results are simulation evidence, not experimental validation; mesh and time convergence must be designed and checked by a researcher.
本仓库同时发布可复用的 tidy3d-research skill。入口文件为 skills/tidy3d-research/SKILL.md，其中包含 MCP workflow、Tidy3D API 和 scientific checks references。
This repository also publishes the reusable tidy3d-research skill. Its entry point is skills/tidy3d-research/SKILL.md, with references for the MCP workflow, Tidy3D API, and scientific checks.
当前仓库未附许可证文件。公开可见不等于授予复制、修改或再分发权；许可证决定应在后续独立决策中明确。
No license file is included at this time. Public visibility does not by itself grant rights to copy, modify, or redistribute; a licensing decision should be made separately.
下面的 JSON 可以由 Tidy3D Simulation.model_dump_json() 生成，再交给 validate_simulation。MCP 不要求使用特定 Python 代码来构造模型。
The JSON below can be produced by Tidy3D Simulation.model_dump_json() and passed to validate_simulation. The MCP does not require a particular Python code generator for model construction.
import tidy3d as td
sim = td.Simulation(
size=(2, 2, 2),
run_time=1e-13,
grid_spec=td.GridSpec.auto(wavelength=1.5, min_steps_per_wvl=10),
sources=[
td.PointDipole(
center=(0, 0, 0),
source_time=td.GaussianPulse(freq0=2e14, fwidth=2e13),
polarization="Ex",
)
],
monitors=[
td.FieldMonitor(
name="field",
center=(0, 0, 0),
size=(2, 2, 0),
freqs=[2e14],
fields=["Ex"],
)
],
)
simulation_json = sim.model_dump_json()以上配置仅用于接口测试，不代表研究结果或收敛结论。
The configuration above is only an interface fixture; it is not a research result or a convergence claim.
在显式确认后把已完成任务下载到私有目录，并生成归一化元数据和观测 CSV。 / After explicit confirmation, download a completed task into a private directory and create normalized metadata and observable CSV.
| Name | Required | Description | Default |
|---|---|---|---|
| task_id | Yes | Completed Tidy3D task identifier | |
| confirm_download | No | Must be true before downloading result data |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnlyHint=false, destructiveHint=false, idempotentHint=false), the description discloses that the tool writes to a private directory, creates normalized metadata and an observable CSV, and requires explicit confirmation. These side-effect details are not present in the schema and help the agent anticipate what the tool does.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence in each language, front-loaded with the key condition 'After explicit confirmation'. It packs action, condition, destination, and result artifacts into a compact form with no filler, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present and parameter descriptions at 100% coverage, the description only needs to cover usage context and side effects, which it does by stating the precondition and artifacts created. It leaves little for the agent to infer, though it could clarify its relationship with normalize_local_result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already documents both parameters with 100% coverage, so the baseline is 3. The description's references to explicit confirmation and completed task map to confirm_download and task_id, but add no new syntactic or semantic details beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action (download), resource (completed Tidy3D task), destination (private directory), and outputs (normalized metadata and observable CSV). This distinguishes it from siblings such as get_simulation_status or normalize_local_result, which serve different workflow stages.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states a clear precondition: use after explicit confirmation and only for completed tasks. This gives the agent a concrete trigger condition. However, it does not explicitly name alternatives or state when not to use the tool, so it falls short of full routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
读取已上传任务的最大 FlexCredit 预估，不启动任务。 / Read the maximum FlexCredit estimate for an uploaded task without starting it.
| Name | Required | Description | Default |
|---|---|---|---|
| task_id | Yes | Task identifier returned by upload_simulation |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
注解已提供 readOnlyHint=true、idempotentHint=true 和 destructiveHint=false，覆盖了安全性。描述补充了“最大”预估和“不启动”的行为，但没有进一步说明如异步性、费用影响或副作用，在注解覆盖下该级别是合理的。
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
描述简短且信息集中，双语版本但内容不冗余。第一句给出了核心行为和限制，结构清晰。虽然双语可能稍显重复，但整体简洁高效。
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
存在输出模式，因此无需在描述中解释返回值。工具简单，只有一个参数，描述已提供核心行为和安全属性。唯一缺失的是明确的使用时机（如“在启动前需要知道预估”），但整体上对于该简单工具已足够完整。
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
只有一个参数 task_id，schema 描述为“Task identifier returned by upload_simulation”，覆盖率 100%。描述未在文本中重复参数说明，但 schema 已完全覆盖，因此基线为 3。
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
描述明确说明了动词“读取”、资源“最大 FlexCredit 预估”和操作对象“已上传任务”，并明确指出“不启动任务”。这清晰地区分了该工具与 start_simulation 等启动类工具，尽管没有直接命名替代工具，但目的明确。
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
描述说明了用途（读取预估）和关键约束（不启动任务），提供了清晰的使用上下文。虽然没有明确列出替代工具，但“不启动任务”这一否定条件暗示了何时使用（预估）以及何时不使用（启动）。
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
读取 Tidy3D 任务的 allowlisted 状态字段。 / Read allowlisted status fields for a Tidy3D task.
| Name | Required | Description | Default |
|---|---|---|---|
| task_id | Yes | Tidy3D task identifier |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the default safety profile is well covered. The description adds the 'allowlisted' qualifier, hinting that only certain status fields are exposed, but it does not explain what is excluded or that status values can change over time. There is no contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single compact bilingual sentence with no filler. It front-loads the verb and resource, and the 'allowlisted' qualifier adds meaningful scope without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter, read-only status tool with an output schema and strong annotations, the description is nearly complete. The only gap is the lack of explicit workflow placement (e.g., that it should be called after start_simulation), but the tool's purpose and scope are sufficiently clear.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and task_id is already documented as the Tidy3D task identifier. The description adds no additional parameter semantics beyond what the schema provides, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action ('read') and resource ('allowlisted status fields for a Tidy3D task'), making the tool's core function obvious. It does not explicitly differentiate from sibling tools, though the focus on 'status' distinguishes it from download/read-artifact tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, such as when to poll status after start_simulation or how it relates to download_simulation_result. No exclusions or alternative tool mentions are present, so the agent must infer usage from the tool name and schema alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
读取配置 workspace 下的相对 Tidy3D JSON/HDF5 结果，不访问任意路径。 / Read a relative Tidy3D JSON/HDF5 result under the configured workspace without arbitrary path access.
| Name | Required | Description | Default |
|---|---|---|---|
| workspace_path | Yes | Relative path under TIDY3D_MCP_WORKSPACE_DIR |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description only mentions the path restriction ('without arbitrary path access') but does not disclose side effects. Despite annotations indicating idempotent and non-destructive, readOnlyHint is false, implying potential writes, yet the description frames the operation as a read, which is inconsistent with the mutation implied by normalization. The description also omits whether a normalized artifact is written.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short (two sentences) and front-loads the security constraint, but it is bilingual, repeating the same information in English and Chinese. While not verbose, the lack of substantive content makes the conciseness less valuable—it is compact but shallow.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, return-value details are not needed, but the description fails to explain the normalization workflow, when to call this versus read_normalized_artifact, or what side effects occur. Given the tool's role among siblings, this is a significant gap for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents workspace_path as a relative path under TIDY3D_MCP_WORKSPACE_DIR (100% coverage). The description adds that it reads JSON/HDF5 results, which gives file-format context, but this is minimal and does not explain formatting, encoding, or validation details beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description says 'Read a relative Tidy3D JSON/HDF5 result' but the tool name is 'normalize_local_result', implying a transformation. It does not explain what normalization entails, and the read action overlaps with the sibling tool read_normalized_artifact, so an agent cannot distinguish this tool's core purpose from that sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like download_simulation_result or read_normalized_artifact. There is no mention of prerequisites, order in a workflow, or conditions that select this tool over its siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
读取本服务生成的 Tidy3D metadata.json 和受限 observables.csv。 / Read the metadata.json and bounded observables.csv generated by this service.
| Name | Required | Description | Default |
|---|---|---|---|
| artifact_id | Yes | Artifact identifier returned by normalization | |
| include_csv | No | Whether to include bounded CSV text |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false, covering the safety profile. The description adds only 'bounded' to describe the observables.csv scope, which is a data scope detail rather than a behavioral trait such as pagination, error behavior, or rate limits. It does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and front-loaded, with no wasted sentences. The bilingual repetition (Chinese and English) is slightly redundant for an AI agent but does not meaningfully harm clarity, so it earns a strong score rather than a perfect one.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with full schema coverage, annotations, and an output schema, the description is sufficiently complete. It could benefit from explicit guidance on ordering relative to normalize_local_result, but the 'generated by this service' phrase provides enough context for correct use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both artifact_id and include_csv already documented. The description does not add extra meaning to the parameters beyond what the schema provides, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('read') and names concrete resources ('metadata.json and bounded observables.csv') generated by this service. This clearly distinguishes the tool from siblings like download_simulation_result or normalize_local_result, which concern different stages of the workflow.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context by stating these artifacts are 'generated by this service', implying use after normalization. However, it does not explicitly mention when to prefer this over siblings or exclude any alternatives, so it falls short of full guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
只有显式确认、云端开关打开且预估成本不超过 max_flexcredits 时才启动任务。 / Start only after explicit confirmation, the cloud gate, and the estimated cost is within max_flexcredits.
| Name | Required | Description | Default |
|---|---|---|---|
| task_id | Yes | Uploaded task identifier | |
| confirm_start | No | Must be true to start the cloud task | |
| max_flexcredits | Yes | Positive maximum allowed FlexCredits |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate a mutating operation (readOnlyHint=false), but the description adds behavioral context: it only starts when conditions are met, implying a gate check. It also mentions cost implications via FlexCredits, which goes beyond the schema and annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One concise bilingual sentence, efficiently conveying the gating conditions. The action is in the title, and the description focuses on when to start, which is appropriate and not redundant.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With a full output schema and 100% parameter coverage, the description covers the essential decision logic. It does not explain the 'cloud gate' in detail, but that may be a global setting known to the agent. Overall sufficient for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers each parameter individually, but the description ties them together: confirm_start must be true, max_flexcredits is the budget limit, and the cloud gate condition. This relational meaning adds value beyond the schema definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The title explicitly states 'Start Tidy3D simulation' and the description clarifies the action is to start a task, with conditions. It is clearly distinct from siblings like estimate_task_cost or upload_simulation, as it is the only tool that launches the simulation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides concrete preconditions: explicit confirmation, cloud gate, and cost within max_flexcredits. This tells the agent when it is appropriate to call the tool (after validation and cost estimation), though it does not explicitly name alternatives or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
在环境开关和显式确认后上传 Tidy3D 草稿，不启动求解。 / After the environment gate and explicit confirmation, upload a Tidy3D draft without starting it.
| Name | Required | Description | Default |
|---|---|---|---|
| task_name | No | Optional task label | |
| folder_name | No | Tidy3D folder label | default |
| confirm_upload | No | Must be true to create a cloud draft | |
| simulation_json | Yes | Serialized tidy3d.Simulation JSON |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false and destructiveHint=false, so the tool is known to be a non-destructive write. The description adds behavioral context by specifying that confirmation is required and that no solving starts, which goes beyond the annotations without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences (bilingual) with zero filler. The core action ('upload without starting') is front-loaded, and the precondition is stated efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema and full schema coverage for inputs, the description covers the essential behavior and precondition. It doesn't mention validation steps (e.g., validate_simulation) or error handling, but these are not strictly required for calling the tool. The mention of 'explicit confirmation' aligns with the confirm_upload parameter, providing enough context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so each parameter (task_name, folder_name, confirm_upload, simulation_json) is already documented. The tool description does not add extra meaning beyond the schema, such as constraints on simulation_json format or how confirm_upload interacts with the 'explicit confirmation' phrase. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('upload'), a clear resource ('Tidy3D draft'), and explicitly scopes the action as 'without starting it', distinguishing it from start_simulation. This is precise and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions preconditions ('environment gate and explicit confirmation') and implies that this tool is for uploading only, not running (contrasting with start_simulation). However, it does not explicitly name alternative tools or state when not to use it, leaving some inference to the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
校验序列化的 tidy3d.Simulation JSON，不执行代码或提交任务。 / Validate serialized tidy3d.Simulation JSON without executing code or submitting a task.
| Name | Required | Description | Default |
|---|---|---|---|
| simulation_json | Yes | Serialized tidy3d.Simulation JSON |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnly, idempotent, and non-destructive behavior, but the description adds the important guarantee that no code is executed and no task is submitted. This provides behavioral transparency beyond the annotations, though it does not elaborate on what validation checks are performed or how invalid input is reported.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact, bilingual, and front-loaded with the core action. It includes only the essential information: what is validated and what is explicitly not done. No filler or redundant elaboration is present.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With one fully documented required parameter, an output schema available, and annotations covering side-effect behavior, the description is complete enough for an agent to invoke the tool correctly. The explicit 'without executing code or submitting a task' also removes the main ambiguity that could arise from sibling simulation tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema describes simulation_json as 'Serialized tidy3d.Simulation JSON', which matches the description exactly, and schema coverage is 100%. The description adds no additional format, size, or serialization details, but the schema already sufficiently documents the only parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Validate') and a specific resource ('serialized tidy3d.Simulation JSON'), and explicitly adds the negative scope 'without executing code or submitting a task.' This makes the tool's purpose clear and distinguishes it from sibling execution tools like start_simulation and upload_simulation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly communicates that this tool is for validation only and not for running or submitting simulations, which provides useful context for when to use it. However, it does not explicitly name alternative tools or state 'use start_simulation to execute' or similar routing guidance, so it stops short of full alternative-based usage instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0download_simulation_resultestimate_task_costget_simulation_statusnormalize_local_resultread_normalized_artifactstart_simulationupload_simulationvalidate_simulationScored across 8 tools
Each tool maps to a distinct stage in the Tidy3D simulation workflow—cost estimation, validation, upload, start, status, download, local normalization, and artifact reading. Even the result-handling tools are separated clearly by source and purpose.
All tool names follow a consistent snake_case verb_noun pattern with unambiguous verbs (estimate, validate, upload, start, get, download, normalize, read). The naming is uniform and predictable.
Eight tools is well-scoped for a Tidy3D research workflow, covering the full simulation lifecycle without unnecessary redundancy or bloat. Each tool earns its place in the pipeline.
The core lifecycle is covered end-to-end: validate, upload, start, monitor, download, normalize, and read. Cancel/delete operations for tasks are absent, but these are not critical for the apparent research workflow.
Scoped agent execution. Server-side credentials, policy, budgets and verifiable receipts.
Design, save, and run outcome-aligned AI workflows and verifiers, with reliable image output.
Reliable async execution for agent tool calls: schema gating, retries, idempotency, audit trail.
Build, validate, deploy — HTTP APIs, cron jobs, webhooks and MCP tools — from your AI client.
