The comsol-mcp server enables automated control of COMSOL Multiphysics simulations by connecting to a running COMSOL server and operating on shared models visible in the COMSOL Desktop.
Connection & Server Management
Start a local COMSOL server or connect/disconnect to an existing one
Retrieve server status, configured paths, and runtime state
Model Management
Create new in-memory models, load .mph files (sync or async), save models to disk
Inspect the model's structural tree; manage a "visible-main" workflow that locks a model so MCP tools and COMSOL Desktop stay in sync
Save model snapshots and commit/iterate changes
Parameters & Expressions
Get and set global parameters
Evaluate expressions with options for aggregation, entity selection, and time-point selection
Geometry & Mesh
Ensure components, geometry sequences, and mesh sequences exist
Create, update, delete, and run geometry features
Physics & Variables
List, create, and remove physics interfaces and features
Set selections for physics features and manage variable nodes
Solver & Study Execution
List, create, and configure solver configurations and features
Run studies synchronously or asynchronously; poll status of async runs
Model Inspection & Tooling
Retrieve the full model structure tree
Audit available MCP tools
Provides tools for attaching to a running COMSOL Multiphysics Server, enabling collaborative modeling with visible Desktop GUI. Allows creating, loading, and modifying models; managing components, geometry, meshes, features; running meshes and studies; and saving models.
Click on "Install 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., "@comsol-mcp connect to server localhost:2035 and create a model"
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.
中文 | English
comsol-mcp 是一个面向 COMSOL Multiphysics 的 MCP Server。它采用
attach-first 工作流：先连接到一个已经运行的 COMSOL Multiphysics Server，
再加载并锁定一个主 .mph 模型，让 MCP 和 COMSOL Desktop 看到并操作同一个
服务端模型。
这个项目的目标不是把 COMSOL 当成黑盒批处理器，而是让自动化过程保持可见： 你可以在 Desktop 中实时观察 MCP 对几何、参数、网格、求解和保存流程的修改。
连接已有的 COMSOL Multiphysics Server
与 COMSOL Desktop 共享同一个服务端模型状态
支持 visible-main 主模型锁，避免误切换或误保存模型
支持参数设置、表达式求值、几何特征创建/更新/删除、物理场、变量、求解器配置和研究运行
支持主模型快照、当前模型保存、异步加载大型 .mph
公开工具接口稳定，目前注册 50 个 MCP tools
Related MCP server: COMSOL MCP Server
当前版本从 35 个 MCP tools 扩展到 50 个，重点补齐了真实 COMSOL 建模中经常需要绕回 Java 脚本的部分：
新增 9 个物理场与变量工具：列出/创建/删除 physics interface，管理 physics feature，设置选择集，管理变量节点。
新增 6 个求解器与异步工具：列出和创建 solver config，查看和配置 solver feature，后台运行 study 并轮询状态。
增强连接稳定性：为 COMSOL Java I/O 调用加入硬超时保护，避免连接、断开或加载模型时长期卡住 MCP runtime lock。
增强 evaluate_expressions()：支持更适合 2D/3D 模型的维度感知聚合、实体选择、时间点选择和结果大小限制。
修复状态报告：连接状态现在从共享 runtime state 动态读取，避免 server_info() 等工具显示过期的 disconnected 状态。
visible-main 工作流继续保持锁定模型身份，新增工具也纳入 SAFE_READ / SAFE_WRITE 分类。
下一阶段会优先让 COMSOL 日常仿真工作流更少依赖临时 Java 脚本：
P0：材料管理、网格特征配置、结果后处理与图片/数据导出。
P1：多物理耦合、探针管理、插值/解析/分段函数定义。
P2：CAD/几何高级操作、工作平面、参数化扫描和自适应网格等高级求解器配置。
测试增强：为 physics、solver、connection timeout 增加更多 mock 单元测试，并保留 live COMSOL Server 集成测试入口。
长期目标是逐步扩展到约 75 个 MCP tools，覆盖 COMSOL 日常仿真的大部分建模、求解和结果提取操作。
需要一边自动化建模，一边在 COMSOL Desktop 中检查模型变化
需要让 AI Agent 修改同一个当前主模型，而不是反复启动批处理任务
需要保留每次迭代的 .mph 快照
需要在长时间运行的 COMSOL Server 会话中做参数、几何或求解探索
Windows
Python 3.10 或更高版本
本机已安装 COMSOL Multiphysics
有效的 COMSOL 许可证
手动启动的 COMSOL Multiphysics Server
git clone https://github.com/Ching-Chiang/comsol-mcp.git comsol-mcp
cd comsol-mcp
python -m pip install -e .开发环境可安装测试依赖：
python -m pip install -e ".[dev]"根据你的 COMSOL 安装位置设置：
$env:COMSOL_ROOT = "C:\Program Files\COMSOL\COMSOL63\Multiphysics"
$env:COMSOL_SERVER_MCP_HOME = "$PWD\comsol-server-home"COMSOL_SERVER_MCP_HOME 用于保存运行状态、日志、输出和快照。该目录默认位于
仓库下的 comsol-server-home/，并已被 .gitignore 忽略。
推荐直接启动长驻 MCP 进程：
python -m comsol_mcp.mcp_server也可以使用脚本：
.\scripts\start_comsol_mcp.ps1 -Python python -ComsolRoot "C:\Program Files\COMSOL\COMSOL63\Multiphysics" -McpHome "$PWD\comsol-server-home"Claude Desktop 或其他 MCP host 可以参考：
examples/claude_desktop_config.json
.mcp.json
一个最小配置类似：
{
"mcpServers": {
"comsol-mcp-server": {
"command": "python",
"args": ["-m", "comsol_mcp.mcp_server"]
}
}
}flowchart LR
User["User / AI Agent"] --> Host["MCP Host"]
Host --> MCP["comsol-mcp<br/>persistent MCP process"]
MCP --> PortCheck["check_server_port<br/>server_connect"]
PortCheck --> Server["COMSOL Multiphysics Server<br/>shared server-side model"]
Desktop["COMSOL Desktop<br/>visual client"] --> Server
MCP --> Lock["visible-main lock<br/>tag + label + path"]
Lock --> Server
MCP --> Tools["MCP tools<br/>parameters, geometry, physics,<br/>solver, study, snapshot"]
Tools --> Server
Server --> Desktop
Tools --> Snapshot["save-copy snapshots<br/>current main path preserved"]手动启动 COMSOL Multiphysics Server。
记录 Server 控制台显示的真实端口。
启动本项目的 MCP Server，并保持进程运行。
调用 start_visible_main_workflow(host, port, path)。
MCP 连接 Server、加载主 .mph，并锁定该 visible-main 模型。
在 COMSOL Desktop 中连接同一个 Server。
在 Desktop 中导入或切换到已经加载的服务端模型。
后续通过 MCP tools 修改模型，并在 Desktop 中观察变化。
大型 .mph 如果加载时间超过 MCP host 的单次工具调用超时，使用异步入口。
请把示例路径替换为你本机可访问的 .mph 文件：
start_visible_main_workflow_async("localhost", <actual_port>, "C:/path/to/model.mph")
visible_main_workflow_status("<job_id>")如果希望始终围绕一个当前主模型工作，并为每次迭代保存快照：
configure_single_main_workflow(
"C:/path/to/model.mph",
"comsol-server-home/snapshots",
"free_convection"
)常用迭代流程：
verify_visible_main_session()
run_visible_main_iteration("trial_label", "[{\"name\":\"param1\",\"expression\":\"1.0\"}]", "")
save_model()连接与状态：
server_info()
check_server_port(host="localhost", port=2036)
server_start(...)
server_connect(host, port, model_name="")
server_disconnect(shutdown_server=false)
workflow_info()
mcp_tool_audit()
visible-main 工作流：
configure_single_main_workflow(current_main_model_path, snapshot_dir="", snapshot_prefix="", notes="")
start_visible_main_workflow(host="localhost", port=2036, path="")
start_visible_main_workflow_async(host="localhost", port=2036, path="")
visible_main_workflow_status(job_id="")
load_visible_main_model(path="")
verify_visible_main_session()
unlock_visible_main(reason)
load_current_main_model()
模型与保存：
model_create(name="Server Model")
model_load(path)
prune_loaded_models(keep="current")
save_main_model_snapshot(snapshot_label)
commit_current_main_model(snapshot_label="")
save_model(path="")
model_tree()
参数、表达式与指标：
get_parameters()
set_parameters(parameters_json)
evaluate_expressions(expressions_json="[]")
get_core_metrics()
几何、网格与求解：
ensure_component(component="comp1", dimension=2)
ensure_geometry(component="comp1", geometry="geom1", dimension=2)
ensure_mesh(component="comp1", mesh="mesh1")
create_feature(component, geometry, tag, feature_type, properties_json="[]", run_geometry=false)
update_feature(component, geometry, tag, properties_json, run_geometry=false)
delete_feature(component, geometry, tag, run_geometry=false)
run_feature(collection, tag, component="comp1")
run_study(study_tag="")
run_visible_main_iteration(label, parameters_json="[]", study_tag="")
物理场与变量：
list_physics(component="comp1")
create_physics(component, tag, physics_type, dimension=0, dependent_variables="u")
remove_physics(component, tag)
list_physics_features(component, physics_tag)
create_physics_feature(component, physics_tag, feature_tag, feature_type, properties_json="[]")
update_physics_feature(component, physics_tag, feature_tag, properties_json)
remove_physics_feature(component, physics_tag, feature_tag)
set_physics_selection(component, physics_tag, feature_tag, entities_json)
manage_variables(component="comp1", action="list", tag="", expressions_json="[]")
求解器与异步运行：
list_solver_config()
create_solver_config(sol_tag, study_tag)
list_solver_features(sol_tag)
configure_solver(sol_tag, feature_tag, properties_json="[]")
run_study_async(study_tag="")
run_study_status(job_id="")
load_visible_main_model() 成功后，MCP 会记录模型的 tag、label 和 path。
后续写操作会先检查当前服务端模型是否仍然是这个主模型。
安全读工具始终允许执行
安全写工具仅在模型身份匹配时允许执行
model_create()、model_load()、prune_loaded_models()、
commit_current_main_model() 在锁定状态下会被阻止
这个设计用于防止 Desktop 正在查看的主模型被意外切走或覆盖。
普通测试不需要 COMSOL Server：
pytest带真实 COMSOL Server 的集成测试使用 comsol_server 标记，默认跳过。
comsol_mcp/
_server.py # FastMCP 实例、全局状态、工具分类
_state.py # 状态持久化、日志、路径和端口工具
_connection.py # 连接生命周期与客户端访问
_model.py # 模型采用、清理、visible-main 锁
_model_ops.py # 参数、表达式、指标、树和几何纯辅助函数
_physics_ops.py # 物理场与变量纯辅助函数
_solver_ops.py # 求解器配置纯辅助函数
_tools_connection.py # 连接相关 MCP tools
_tools_workflow.py # 工作流和 visible-main tools
_tools_model.py # 模型创建、加载、清理 tools
_tools_params.py # 参数、表达式、指标 tools
_tools_geometry.py # 组件、几何、网格、特征 tools
_tools_physics.py # 物理场、physics feature、变量 tools
_tools_solver.py # 求解器配置和异步 study tools
_tools_snapshot.py # 迭代、快照和保存 tools
mcp_server.py # 入口与工具注册本项目不包含 COMSOL 二进制文件或专有模型资源。
COMSOL Desktop 连接 Server 后，可能需要手动导入或切换到服务端已加载模型。
server_start() 只是高级备用入口；推荐手动启动 COMSOL Server 并使用真实端口连接。
保持 MCP 进程长驻，不要用一次性脚本加载模型后立刻退出。
维护者：蒋铖 jiang-jc24@mails.tsinghua.edu.cn
MIT. See LICENSE.
comsol-mcp is an MCP server for COMSOL Multiphysics. It uses an
attach-first workflow: connect to an already running COMSOL Multiphysics
Server, load and lock a main .mph model, and let MCP tools and COMSOL
Desktop operate on the same server-side model.
The goal is visible automation. Instead of treating COMSOL as a black-box batch runner, this server lets you watch geometry, parameters, mesh, solve steps, and saved snapshots evolve in COMSOL Desktop.
Attach to an existing COMSOL Multiphysics Server
Share one server-side model with COMSOL Desktop
Lock the visible main model to prevent accidental model switching
Set parameters, evaluate expressions, edit geometry and physics features, configure solvers, run mesh and studies
Save main-model snapshots and handle large .mph loads asynchronously
Stable MCP tool surface with 50 registered tools
The current version expands the tool surface from 35 to 50 MCP tools and removes several places where users previously had to fall back to ad hoc Java scripts:
Added 9 physics and variable tools for physics interfaces, physics features, selections, and variable nodes.
Added 6 solver and async tools for solver configs, solver features, background study execution, and polling.
Added hard timeout protection around slow COMSOL Java I/O calls so connect, disconnect, and model load operations do not permanently block the MCP runtime lock.
Enhanced evaluate_expressions() with dimension-aware aggregation, entity selection, time-point selection, and result-size limits.
Fixed runtime status reporting so connection state is read from shared state rather than stale imported values.
The next releases will focus on reducing the remaining need for handwritten COMSOL Java scripts:
P0: material management, mesh feature configuration, result plots, image export, and data export.
P1: multiphysics couplings, probes, and interpolation/analytic/piecewise functions.
P2: CAD import, advanced geometry workflows, work planes, parametric sweeps, and adaptive mesh configuration.
Testing: broader unit tests for physics, solver, and timeout behavior, plus live COMSOL Server integration scenarios.
The long-term target is about 75 MCP tools covering most day-to-day COMSOL modeling, solving, and result extraction workflows.
Windows
Python 3.10+
Local COMSOL Multiphysics installation
Valid COMSOL license
A manually started COMSOL Multiphysics Server
git clone https://github.com/Ching-Chiang/comsol-mcp.git comsol-mcp
cd comsol-mcp
python -m pip install -e .For development:
python -m pip install -e ".[dev]"Set environment variables for your COMSOL installation:
$env:COMSOL_ROOT = "C:\Program Files\COMSOL\COMSOL63\Multiphysics"
$env:COMSOL_SERVER_MCP_HOME = "$PWD\comsol-server-home"Start the MCP server:
python -m comsol_mcp.mcp_serverExample MCP host configuration:
{
"mcpServers": {
"comsol-mcp-server": {
"command": "python",
"args": ["-m", "comsol_mcp.mcp_server"]
}
}
}Start COMSOL Multiphysics Server manually.
Note the real listening port from the server console.
Keep python -m comsol_mcp.mcp_server running.
Call start_visible_main_workflow(host, port, path).
Connect COMSOL Desktop to the same server.
Import or switch to the already loaded server-side model in Desktop.
Use MCP tools to modify the locked main model and watch Desktop update.
For large .mph files, use the async entrypoint and replace the example path
with a local .mph file:
start_visible_main_workflow_async("localhost", <actual_port>, "C:/path/to/model.mph")
visible_main_workflow_status("<job_id>")pytestThe default test suite does not require COMSOL. Integration tests that need a
live COMSOL Server are marked with comsol_server and skipped by default.
Maintainer: mr jiang jiang-jc24@mails.tsinghua.edu.cn
MIT. See LICENSE.
Create a geometry feature and optionally apply initial properties.
| Name | Required | Description | Default |
|---|---|---|---|
| component | Yes | ||
| geometry | Yes | ||
| tag | Yes | ||
| feature_type | Yes | ||
| properties_json | No | [] | |
| run_geometry | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, and the description only implies a write operation without detailing side effects, permissions required, or what happens on duplicate creation. For a mutation tool, this is insufficient.
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, which is concise but lacks structure. It fails to front-load key information and does not earn its brevity given the tool's complexity.
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?
Despite an output schema, the description omits prerequisites, return format, and constraints. The 6 parameters are poorly explained, making the definition incomplete for an agent.
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?
With 0% schema description coverage, the description must compensate but only mentions 'geometry feature' and 'initial properties'. It does not explain the meaning of parameters like 'component', 'tag', 'feature_type', or 'run_geometry'.
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 the tool creates a geometry feature and optionally applies properties. It uses a specific verb-resource pair and distinguishes from 'delete_feature' and 'update_feature'. However, it does not clarify what a 'geometry feature' entails.
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 'run_feature' or 'update_feature'. The description gives no context for appropriate invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a geometry feature from the selected server-side model.
| Name | Required | Description | Default |
|---|---|---|---|
| component | Yes | ||
| geometry | Yes | ||
| tag | Yes | ||
| run_geometry | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It only says 'Delete' but omits details like reversibility, side effects, required state, or impact of the 'run_geometry' parameter.
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?
While a single sentence is concise, it omits essential parameter details, making it inadequate for a tool with 4 parameters and a complex operation.
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 lack of annotations, presence of an output schema not described, and 4 undocumented parameters, the description is severely incomplete. It does not enable 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 description coverage is 0%, yet the description adds no explanation for any of the 4 parameters (component, geometry, tag, run_geometry). The agent gains no insight beyond raw names.
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 the action ('Delete') and the resource ('geometry feature') with context ('from the selected server-side model'), distinguishing it from siblings like create_feature and update_feature.
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 on when to use this tool versus alternatives (e.g., run_feature, update_feature). No conditions, prerequisites, or when-not advice provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Ensure a component exists in the selected server-side model.
| Name | Required | Description | Default |
|---|---|---|---|
| component | No | comp1 | |
| dimension | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must disclose behavior. It implies idempotency but does not clarify what happens if component already exists (no-op vs update). No mention of side effects, permissions, or error conditions.
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?
Single sentence is concise, but at the cost of omitting essential details. Not a model of efficient communication.
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 2 parameters with no descriptions, and existence of output schema, the description fails to provide sufficient context about prerequisites, behavior, or return values.
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 has 0% parameter descriptions. The description adds no explanation for 'component' or 'dimension', leaving the agent to guess their meaning and valid values.
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?
Description clearly states the action (ensure existence) and resource (component) and context (selected server-side model). However, it does not differentiate from sibling tools like ensure_geometry or ensure_mesh, which also create/verify entities.
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 on when to use this tool versus alternatives, such as ensure_geometry or ensure_mesh. No prerequisites or conditions mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Ensure a geometry sequence exists in the selected server-side model.
| Name | Required | Description | Default |
|---|---|---|---|
| component | No | comp1 | |
| geometry | No | geom1 | |
| dimension | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and description fails to disclose behavioral traits such as idempotency, side effects, or what 'ensure' means (create vs check). Minimal transparency.
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?
Single sentence is concise but lacks structure; it is minimally informative but not wasteful. Could benefit from additional context without being verbose.
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 three parameters, no annotations, and an output schema, the description is incomplete. It does not explain parameter roles, output meaning, or behavioral details.
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 0%, and the description adds no meaning to any of the three parameters (component, geometry, dimension). The defaults exist in schema but are unexplained.
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?
Description clearly states the tool ensures a geometry sequence exists in a server-side model, using specific verb and resource. It distinguishes from siblings like ensure_component and ensure_mesh by naming geometry, but lacks explicit differentiation.
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 on when to use this tool versus alternatives, no prerequisites, no exclusions. The description is purely declarative without usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Ensure a mesh sequence exists in the selected server-side model.
| Name | Required | Description | Default |
|---|---|---|---|
| component | No | comp1 | |
| mesh | No | mesh1 |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Implies idempotent 'ensure' behavior but does not specify side effects, error handling, or what happens if the mesh already exists. With no annotations, the description fails to disclose key behavioral traits.
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, concise but too brief. It lacks structure to highlight key points, though it is not verbose.
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?
Despite having an output schema (unknown), the description provides no information about return values or tool behavior. With no annotations and minimal parameter info, the description is incomplete for effective 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 coverage is 0%, and the description does not explain what 'component' and 'mesh' parameters represent. It only repeats the names, adding no semantic value 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 clearly states the tool ensures a mesh sequence exists, using a specific verb and resource. However, it does not explicitly differentiate from siblings like ensure_component or ensure_geometry, lacking comparative context.
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 on when to use this tool versus alternatives, nor any prerequisites or conditions. The description is silent on usage context, leaving the agent to infer.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return current global parameters from the selected server-side model.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits such as read-only nature, side effects, or error conditions (e.g., if no model is loaded). The agent has no information about what happens if the server state is invalid.
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, front-loaded sentence with no redundant words. It conveys the core purpose 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 tool has zero parameters and an output schema exists, the description still lacks context about prerequisites (e.g., model loaded, server connected) and when to call it. This is inadequate for a tool that interacts with server state.
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?
With zero parameters, the input schema provides no parameter info, but the description does not add meaning beyond stating the tool returns 'global parameters'. It does not clarify what constitutes global parameters or how they relate to the model, so it adds minimal value.
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 the tool returns global parameters from the server-side model, using a specific verb ('Return') and resource ('global parameters'). It distinguishes itself from sibling 'set_parameters'.
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 does not provide guidance on when to use this tool versus alternatives like model_tree or server_info. No prerequisites, exclusions, or context are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new in-memory model on the connected COMSOL server and select it as current.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | Server Model |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It indicates creation of an in-memory model but lacks details on side effects (e.g., replacing current model) or behavioral traits like required prior connections.
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?
Single sentence, front-loaded with key information, no wasted words. Efficient and clear.
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 1 parameter, no annotations, and an output schema (content unknown), description covers basic purpose but omits prerequisites like server connection and what 'select as current' entails. Adequate but not complete.
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 has 1 parameter (name) with 0% description coverage. The description does not explicitly explain the parameter beyond the action; it implies naming but adds no detail on syntax or constraints.
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 the specific action: 'create a new in-memory model' and the additional outcome 'select it as current.' This distinguishes it from sibling tools like model_load, which loads existing models.
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 on when to use this tool versus alternatives. Sibling tools like model_load exist but no differentiation or prerequisites (e.g., server must be connected) are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Load an MPH file on the connected COMSOL server and select it as current.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It does not disclose side effects (e.g., overwrites current model), error handling (file not found, invalid format), or any constraints (file size, server state). Only states the basic function.
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?
Single sentence front-loaded with action, no unnecessary words. Efficient and clear.
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?
Despite having an output schema (unknown content), the description omits return value details, prerequisites (server connection), and behavioral context needed for a load operation. Incomplete for the tool's complexity.
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 coverage is 0%, so description must add meaning. It mentions 'MPH file' which adds file type context to the 'path' parameter, but does not specify path format, required extension, or allowed values beyond the schema indicating it is required.
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 the action ('Load an MPH file') and the effect ('select it as current'). It distinguishes from sibling tools like 'model_create' (create new model) and 'save_model' (save).
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 on when to use this tool vs alternatives, no prerequisites (e.g., server must be connected via 'server_connect'), and no context about required order of operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return tags and structure for the current server-side model.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose side effects or read-only nature, but it only states what is returned. No mention of safety, permissions, or model mutability.
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?
Single sentence, front-loaded with key information. No wasted words.
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?
Adequate for a zero-parameter tool with an output schema. Description covers the return purpose without needing to detail output structure.
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?
No parameters exist, so baseline is 4 per rules. Schema coverage is 100%, and description correctly implies no input needed, adding no extra meaning.
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?
Description uses clear verb 'Return' and specific resource 'tags and structure for the current server-side model', distinguishing it from sibling tools like model_create or model_load.
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 on when to use this tool versus alternatives like get_parameters or server_info. Lacks any context about prerequisites or typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run a geometry or mesh sequence on the selected server-side model.
| Name | Required | Description | Default |
|---|---|---|---|
| collection | Yes | ||
| tag | Yes | ||
| component | No | comp1 |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description should disclose behavioral traits. It only says 'run', lacking details on whether it modifies state, is destructive, requires authentication, or what the output represents. Very limited transparency.
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 extremely concise (one sentence), but this comes at the cost of missing critical information. It is not well-structured to front-load key details for an agent.
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 lack of annotations, high parameter count (3), and an output schema that is not described, the description fails to provide sufficient context for an agent to correctly invoke the tool. It omits return behavior, side effects, and parameter roles.
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 0%, yet the description adds no meaning to any of the three parameters (collection, tag, component). It does not explain what these parameters represent or how they affect execution.
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 the action 'Run' and the target 'geometry or mesh sequence on the selected server-side model'. It effectively conveys what the tool does and distinguishes it from sibling tools like create_feature or delete_feature, though it could be more explicit about the semantic difference.
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. The description implies use for executing a sequence, but there is no explicit context about prerequisites, conditions, or excluded use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run the current model study, optionally restricting execution to a study tag.
| Name | Required | Description | Default |
|---|---|---|---|
| study_tag | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It says 'run' but does not disclose if it modifies state, requires permissions, or is reversible. Output schema exists but return values are not mentioned.
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?
Single sentence with no wasted words. Front-loaded with purpose and optional constraint.
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?
Tool is simple with one optional parameter and output schema exists. However, description does not clarify what constitutes a 'study' or whether it requires a loaded model, which is relevant given siblings like model_load.
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 coverage is 0%, so description must compensate. It mentions 'study tag' restricts execution but does not explain format or meaning beyond that. The default empty string is not interpreted.
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 the verb 'Run' and the resource 'current model study', and mentions optional restriction by study tag. It distinguishes from sibling 'run_feature' implicitly, but does not explicitly differentiate.
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 on when to use vs alternatives like run_feature, no prerequisites (e.g., study must exist), and no when-not conditions. The only hint is optional restriction by tag.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Save the current server-side model to disk.
| Name | Required | Description | Default |
|---|---|---|---|
| path | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description only says 'save to disk' without disclosing side effects (overwrite behavior, asynchronicity, permissions required). For a mutation tool, this is insufficient.
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 extremely concise at one sentence, but it sacrifices necessary detail. It is not verbose, but also not sufficiently informative for an agent to use correctly.
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, the return value might be documented, but the description still lacks essential context like success/failure behavior, default save location, and whether a model must be loaded. It is incomplete for practical 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?
The only parameter 'path' has no description in the schema (0% coverage) and the tool description adds no meaning. The default empty string is unexplained, and the expected format or behavior is unclear.
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 the action 'save' and the resource 'current server-side model to disk'. It distinguishes from sibling tools like model_create or model_load, but lacks specifics about the default path or file format.
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 on when to use this tool over alternatives, no prerequisites, and no mention of when not to use it. Among many sibling tools, usage context is missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Connect the MCP client to an existing COMSOL Multiphysics Server.
| Name | Required | Description | Default |
|---|---|---|---|
| host | No | localhost | |
| port | No | ||
| model_name | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must convey behavioral traits. It only states the high-level action, omitting details like connection persistence, error handling, or state changes. The presence of an output schema might help but is not described.
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 front-loading the core action. However, it is too sparse, sacrificing completeness for brevity.
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 three parameters with no schema descriptions and no annotations, the description is woefully incomplete. It fails to provide enough context for correct invocation, such as parameter roles or required setup.
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 has 0% description coverage for parameters, and the description adds no meaning to host, port, or model_name. Crucial context like what model_name specifies (e.g., a model to load after connection) is missing.
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 the action (connect) and resource (MCP client to existing COMSOL server). It is specific enough to distinguish from siblings like server_disconnect and server_start.
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. It does not mention prerequisites (e.g., server must be running via server_start) or situations where server_connect is inappropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Disconnect the MCP client. Optionally shut down the local server if MCP started it.
| Name | Required | Description | Default |
|---|---|---|---|
| shutdown_server | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries the burden. It discloses the optional server shutdown condition, but lacks details on side effects or prerequisites.
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?
Two sentences, no redundancy, front-loaded with the action. Every word earns its place.
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 tool with one optional parameter and an output schema, the description sufficiently covers purpose and behavior. No missing information for typical 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?
Although schema coverage is 0%, the description explains the optional shutdown behavior based on MCP starting the server, adding meaning beyond the bare boolean 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?
Clearly states it disconnects the MCP client and optionally shuts down the server. Verb and resource are specific, and it distinguishes from sibling tools like server_connect or server_start.
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?
Describes the optional shutdown behavior but does not provide explicit guidance on when to use this tool versus alternatives, or when to set shutdown_server flag.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return COMSOL Server MCP status, configured paths, and current runtime state.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It clearly states what is returned (status, paths, runtime state) and implies a read-only, non-destructive operation. Could add more detail about what 'runtime state' includes, but sufficient.
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?
Single, well-structured sentence with no wasted words. Information is front-loaded and easy to parse.
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 simple nature and presence of an output schema (likely describing the return structure), the description covers the key aspects. Could specify what 'configured paths' refers to, but adequate for a status tool.
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 tool has 0 parameters, so no additional meaning is needed. Baseline for 0 params is 4, and the description adds no confusion.
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 clear verb 'Return' and specifies the resource: 'COMSOL Server MCP status, configured paths, and current runtime state.' It distinguishes from sibling tools which focus on features, models, and parameters.
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 explicit guidance on when to use or avoid this tool. Usage is implied from its purpose, but there are no alternatives mentioned or context for conditionality.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Start a local COMSOL Multiphysics Server and connect the MCP client to it.
This is an advanced entrypoint. The recommended visible workflow is to start COMSOL Multiphysics Server manually, connect Desktop to it, and then use server_connect() from MCP.
| Name | Required | Description | Default |
|---|---|---|---|
| port | No | ||
| cores | No | ||
| multi | No | on | |
| timeout_seconds | No | ||
| version | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description lacks any behavioral details such as whether the operation is destructive, what happens to existing servers, or error conditions. The description does not go beyond stating basic functionality.
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 brief and front-loaded with the core action. The second paragraph adds useful context. It could be slightly more concise, but overall it is well-structured without unnecessary fluff.
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 five parameters undocumented and no annotations, the description fails to provide a complete picture. The agent lacks information on default behavior, output, or error handling, making it insufficient for a tool with this complexity.
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 0%, and the description provides no explanation for any of the five parameters (port, cores, multi, timeout_seconds, version). The agent gets no guidance on how to use these parameters effectively.
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 it starts a local COMSOL Multiphysics Server and connects the MCP client. It distinguishes itself from sibling tools like server_connect by labeling itself as an 'advanced entrypoint' and recommending an alternative 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?
Explicitly provides when-to-use vs alternatives: it says this is advanced, and the recommended workflow is to manually start the server and use server_connect instead. This helps an agent decide which tool to invoke.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Set multiple global parameters on the selected server-side model.
| Name | Required | Description | Default |
|---|---|---|---|
| parameters_json | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavior. It fails to explain safety (e.g., mutation effects), required permissions, or how parameters are updated (overwrite vs merge). Only a minimal action statement is provided.
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?
Single sentence, efficient and front-loaded. However, it is slightly too terse, missing necessary detail around parameter usage.
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?
Despite having an output schema, the tool is incomplete: the parameter's format is unexplained, and no behavioral context is given. For a tool with one parameter, more detail is expected.
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 sole parameter 'parameters_json' has no schema description (0% coverage). The description does not clarify the expected format (e.g., JSON string with key-value pairs), leaving the agent unable to construct a proper value.
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 the action ('Set') and the resource ('global parameters on the selected server-side model'), which is specific and distinct from siblings like get_parameters.
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 explicit guidance on when to use this tool versus alternatives (e.g., get_parameters for reading), nor any prerequisites or conditions. Usage is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update geometry feature properties on the selected server-side model.
| Name | Required | Description | Default |
|---|---|---|---|
| component | Yes | ||
| geometry | Yes | ||
| tag | Yes | ||
| properties_json | Yes | ||
| run_geometry | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavior; it only says 'update' implying mutation, but omits side effects, atomicity, return value details, or whether existing properties are replaced or merged.
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 single sentence is concise and front-loaded, but it omits essential information for effective use, making it slightly under-specified.
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 5 undocumented parameters and an unexplained output schema, the description is far from complete; it fails to equip the agent with sufficient context 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?
Despite 0% schema coverage and 5 parameters, the description provides no explanation of any parameter (component, geometry, tag, properties_json, run_geometry), leaving the agent without semantic understanding.
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 explicitly states the action ('update') and the resource ('geometry feature properties on the selected server-side model'), clearly distinguishing it from sibling tools like create_feature or delete_feature.
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 on when to use this tool versus alternatives like create_feature or run_feature, nor any prerequisites or conditions for invocation.
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. Dates show when Glama detected each change.
v0.1.0create_featuredelete_featureensure_componentensure_geometryensure_meshget_parametersmodel_createmodel_loadmodel_treerun_featurerun_studysave_modelserver_connectserver_disconnectserver_infoserver_startset_parametersupdate_featureEvery tool targets a distinct action or entity: server management, model operations, geometry/mesh features, parameters, and study execution. There is no ambiguity between server tools, model tools, and feature tools.
Tool names mix two patterns: noun_verb (e.g., server_connect, model_create) and verb_noun (e.g., create_feature, set_parameters). While still readable, the inconsistency across the set reduces predictability.
With 18 tools, the set covers server lifecycle, model CRUD, geometry/mesh operations, parameters, and study runs without being bloated or insufficient for the domain.
The tools cover core workflows: server management, model creation/loading/saving, parameter manipulation, feature creation/deletion/update, and running sequences/studies. Missing result extraction and mesh-specific feature creation are minor gaps.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Hosted MCP server for task-first delegation to remote workstations and workers.
MCP server for progressive tool usage at any scale (see https://klavis.ai)
MCP server to assist with JxBrowser development.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/Ching-Chiang/comsol-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
