MCP-сервер на базе ИИ для COMSOL с рабочим процессом через визуальный настольный клиент.
comsol-mcp создан для рабочего процесса, в котором:
вы вручную запускаете COMSOL Multiphysics Server
COMSOL Desktop подключается к этому серверу как визуальный клиент
MCP-клиент подключается к той же модели на стороне сервера
изменения в модели остаются видимыми, а не выполняются как пакетное задание в «черном ящике»
Этот репозиторий является новой основной веткой для визуальной автоматизации COMSOL в данной кодовой базе. Старый путь, ориентированный на пакетную обработку, теперь является лишь устаревшей справочной информацией.
Многие процессы автоматизации COMSOL мощны, но непрозрачны. Они могут компилировать Java, запускать пакетные задания или управлять общими симуляциями на стороне сервера, но они не всегда позволяют наблюдать за развитием модели в графическом интерфейсе Desktop.
comsol-mcp фокусируется на другой цели:
видимые изменения в графическом интерфейсе
общее состояние модели на стороне сервера
отсутствие моста опроса на стороне Desktop
отсутствие уровня автоматизации графического интерфейса
отсутствие рабочего процесса только через пакетные задания в «черном ящике»
Related MCP server: COMSOL MCP Server
Этот проект использует рабочий процесс «сначала подключение» (attach-first):
Запустите COMSOL Multiphysics Server вручную.
Запишите реальный порт прослушивания из консоли сервера.
Подключите COMSOL Desktop к тому же порту.
При необходимости импортируйте модель с сервера в Desktop.
Подключите MCP к тому же серверу с помощью server_connect(host, port).
Создайте или загрузите рабочую модель.
Используйте инструменты MCP для изменения общей модели на стороне сервера.
Наблюдайте за обновлением той же модели в COMSOL Desktop.
Полную версию см. в руководстве по рабочему процессу.
Windows с установленным локально COMSOL
Действующая лицензия COMSOL
Python 3.10 или новее
Вручную запущенный COMSOL Multiphysics Server
Из исходного кода:
git clone <your-repo-url> comsol-mcp
cd comsol-mcp
python -m pip install -e .Установите переменные окружения:
$env:COMSOL_ROOT = "C:\Program Files\COMSOL\COMSOL63\Multiphysics"
$env:COMSOL_SERVER_MCP_HOME = "$PWD\comsol-server-home"Запустите 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"См.:
server_connect("localhost", <actual_port>)
model_create("VisibleServerModel")
ensure_component("comp1", 2)
ensure_geometry("comp1", "geom1", 2)
ensure_mesh("comp1", "mesh1")
create_feature("comp1", "geom1", "r1", "Rectangle", "[{\"name\":\"size\",\"values\":[\"60[mm]\",\"30[mm]\"]},{\"name\":\"pos\",\"values\":[\"-30[mm]\",\"-15[mm]\"]}]", true)
run_feature("mesh", "mesh1", "comp1")В Desktop должна отображаться та же геометрия, поскольку Desktop и MCP используют одну и ту же модель на стороне сервера.
См. examples/attach_first_demo.md для ознакомления с тем же процессом в виде документа.
Текущие инструменты:
server_info()
server_start(...)
server_connect(host, port, model_name="")
server_disconnect(shutdown_server=false)
model_create(name="Server Model")
model_load(path)
model_tree()
get_parameters()
set_parameters(parameters_json)
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="")
save_model(path="")
Набор инструментов моделирования намеренно сделан стабильным. Очистка этого репозитория не переименовывает и не удаляет эти инструменты.
Рекомендуемая точка входа:
server_connect("localhost", <actual_port>)server_start() по-прежнему доступен, но теперь это расширенный резервный вариант. Используйте его только тогда, когда хотите, чтобы MCP управлял жизненным циклом сервера COMSOL, и готовы к тому, что COMSOL может автоматически выбрать другой порт прослушивания.
COMSOL Desktop может не отображать автоматически модель на стороне сервера после успешного подключения; возможно, вам потребуется импортировать или переключиться на существующую модель сервера.
server_connect() может завершиться успешно, даже если не выбрана текущая рабочая модель; в этом случае используйте model_create() или model_load().
Вывод консоли сервера и фактический порт прослушивания всегда следует сверять с реальным активным прослушивателем.
Графика Desktop может потребовать легкого обновления после изменений модели на стороне сервера.
См. руководство по устранению неполадок.
abaqus-mcp-serverabaqus-mcp-server — это проект в стиле скриптов графического интерфейса / автоматизации графического интерфейса. Он работает с уже запущенным графическим интерфейсом и использует методы автоматизации графического интерфейса для запуска действий.
comsol-mcp не использует автоматизацию графического интерфейса в стиле pywinauto для COMSOL. Вместо этого он подключается напрямую к COMSOL Multiphysics Server и управляет той же моделью на стороне сервера, которую визуализирует Desktop.
Публичные списки COMSOL MCP часто делают упор на широту решателей, генерацию сетки, настройку физики и покрытие параметрических разверток.
Этот проект подчеркивает другое ценностное предложение:
«сначала подключение»
визуальный рабочий процесс Desktop
моделирование без «черного ящика»
общее состояние модели между Desktop и MCP
Это не просто «еще один MCP для автоматизации COMSOL»; он специально создан для того, чтобы сделать рабочий процесс видимым и совместным с клиентом Desktop.
Старый пакетный путь использовал:
comsolcompile
comsolbatch
Этот путь все еще полезен для автономных заданий, но он больше не является публичным лицом этого проекта. В этом репозитории он рассматривается как устаревшая справочная информация, а не как основная ветка.
См. docs/differences.md для более полного сравнения.
Более ранний внутренний путь comsol-mcp в этой кодовой базе был ориентирован на пакетную обработку и обертывал comsolcompile плюс comsolbatch. Этот устаревший путь намеренно не является публичным лицом этого репозитория.
Этот репозиторий фокусируется на:
COMSOL Multiphysics Server
Desktop как визуальный клиент
Подключение MCP к той же модели
Построено на базе MPh
Вдохновлено рабочими процессами клиент-сервер COMSOL и связанными исследованиями MCP
Не связано с COMSOL
Не включает бинарные файлы COMSOL или проприетарные активы
MIT. См. 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
