Allows AI agents to automate COMSOL Multiphysics simulations, including model management, geometry building, physics configuration, meshing, solving, and results visualization.
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 Server Create a 3D block 10x5x2 mm"
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.
MCP Server for COMSOL Multiphysics simulation automation via AI agents.
English | 中文
Related MCP server: flex-sensor-agent-mcp
Build a complete COMSOL MCP Server enabling AI agents (like Claude, opencode) to perform multiphysics simulations through the MCP protocol:
Model Management - Create, load, save, version control
Geometry Building - Blocks, cylinders, spheres, boolean operations
Physics Configuration - Heat transfer, fluid flow, electrostatics, solid mechanics
Meshing & Solving - Auto mesh, stationary/time-dependent studies
Results Visualization - Evaluate expressions, export plots
Knowledge Integration - Embedded guides + PDF semantic search
COMSOL Multiphysics (version 5.x or 6.x)
Python 3.10+ (NOT Windows Store version)
Java runtime (required by MPh/COMSOL)
# Clone repository
git clone https://github.com/Zhangyoupeng1996/Codex_MCP_Comsol.git
cd Codex_MCP_Comsol
# Install dependencies
python -m pip install -e .
# Test server
python -m src.serverFor Windows workstations where the default COMSOL profile directory is not
writable or has stale credentials, start comsolmphserver with workspace-local
runtime folders while keeping COMSOL authentication enabled.
.\scripts\start_comsol_mphserver.ps1 `
-ComsolBin "D:\Software\Comsol6.3\COMSOL63\Multiphysics\bin\win64" `
-Port 2036 `
-User ROG `
-SyncDefaultLoginNotes:
-SyncDefaultLogin copies the local COMSOL login.properties hash into the
workspace runtime directory so the Python client and server use the same
authenticated CHAP login data.
The script intentionally uses -login auto, not -login never.
It writes local runtime state under .comsol_runtime/; this directory is
ignored by Git.
Validate the same Python client path used by the MCP server:
python scripts/test_comsol_connection.py --host localhost --port 2036You should see the COMSOL version and the list of loaded models. A listening
TCP port alone is not sufficient; this direct mph.Client(...) check catches
authentication problems such as Wrong_username_or_password.
For Codex Desktop workspace configuration, migration notes, and safe cleanup of
stale MCP Python processes, see
docs/CODEX_WORKSPACE.md.
After the COMSOL server is running and the MCP server dependencies are installed, generate a compact piezoelectric cantilever model:
python examples/piezoelectric_cantilever_classic.pyThe script creates a bonded substrate/piezo layer, electrostatic electrodes, a fixed root, a stationary study, and result plot groups for:
electric potential,
electric field norm,
equivalent piezoelectric bending shape,
true solid displacement norm when COMSOL creates the PiezoelectricEffect
coupling successfully.
Generated .mph files are written to comsol_outputs/, which is ignored by
Git so simulation artifacts do not clutter the MCP source repository.
The pdf/ and knowledge_base/ directories are intentionally ignored by Git.
Place your local COMSOL documentation PDFs under pdf/, then build the local
knowledge base with the commands below.
# Install additional dependencies
pip install pymupdf chromadb sentence-transformers
# Build knowledge base
python scripts/build_knowledge_base.py
# Check status
python scripts/build_knowledge_base.py --statusCreate opencode.json in project root:
{
"$schema": "https://opencode.ai/config.json",
"mcp": {
"comsol": {
"type": "local",
"command": ["python", "-m", "src.server"],
"enabled": true,
"environment": {
"HF_ENDPOINT": "https://hf-mirror.com"
},
"timeout": 30000
}
}
}{
"mcpServers": {
"comsol": {
"command": "python",
"args": ["-m", "src.server"],
"cwd": "/path/to/comsol-mcp"
}
}
}comsol_mcp/
├── opencode.json # MCP server config for opencode
├── pyproject.toml # Python project config
├── README.md # This file
│
├── src/
│ ├── server.py # MCP Server entry point
│ ├── tools/
│ │ ├── session.py # COMSOL session management (start/stop/status)
│ │ ├── model.py # Model CRUD + versioning
│ │ ├── parameters.py # Parameter management + sweeps
│ │ ├── geometry.py # Geometry creation (block/cylinder/sphere)
│ │ ├── physics.py # Physics interfaces + boundary conditions
│ │ ├── mesh.py # Mesh generation
│ │ ├── study.py # Study creation + solving (sync/async)
│ │ └── results.py # Results evaluation + export
│ ├── resources/
│ │ └── model_resources.py # MCP resources (model tree, parameters)
│ ├── knowledge/
│ │ ├── embedded.py # Embedded physics guides + troubleshooting
│ │ ├── retriever.py # PDF vector search retriever
│ │ └── pdf_processor.py # PDF chunking + embedding
│ ├── async_handler/
│ │ └── solver.py # Async solving with progress tracking
│ └── utils/
│ └── versioning.py # Model version path management
│
├── scripts/
│ └── build_knowledge_base.py # Build PDF vector database
│
├── client_script/ # Standalone modeling scripts (examples)
│ ├── create_chip_tsv_final.py # Example: Chip thermal model
│ ├── create_micromixer_auto.py # Example: Fluid flow simulation
│ ├── create_chip_thermal*.py # Various chip thermal variants
│ ├── create_micromixer*.py # Various micromixer variants
│ ├── visualize_*.py # Result visualization scripts
│ ├── add_visualization.py # Add plot groups to model
│ └── test_*.py # Integration tests
│
├── comsol_models/ # Saved models (structured)
│ ├── chip_tsv_thermal/
│ │ ├── chip_tsv_thermal_20260216_*.mph
│ │ └── chip_tsv_thermal_latest.mph
│ └── micromixer/
│ └── micromixer_*.mph
│
└── tests/
└── test_basic.py # Unit testsTool | Description |
| Start local COMSOL client |
| Connect to remote server |
| Clear session |
| Get session info |
Tool | Description |
| Load .mph file |
| Create empty model |
| Save to file |
| Save with timestamp |
| List loaded models |
| Set active model |
| Clone model |
| Remove from memory |
| Get model structure |
Tool | Description |
| Get parameter value |
| Set parameter |
| List all parameters |
| Setup parametric sweep |
| Get/set description |
Tool | Description |
| List geometry sequences |
| Create geometry sequence |
| Add generic feature |
| Add rectangular block |
| Add cylinder |
| Add sphere |
| Add 2D rectangle |
| Add 2D circle |
| Union objects |
| Subtract objects |
| Import CAD file |
| Build geometry |
| List features |
| Get boundary numbers |
Tool | Description |
| List physics interfaces |
| Available physics types |
| Add generic physics |
| Add Electrostatics |
| Add Solid Mechanics |
| Add Heat Transfer |
| Add Laminar Flow |
| Configure boundary condition |
| Assign material |
| List physics features |
| Remove physics |
| Add coupling |
| Interactive heat BC setup |
| Configure heat boundaries |
| Interactive flow BC setup |
| Generic boundary setup |
Tool | Description |
| List mesh sequences |
| Generate mesh |
| Get mesh statistics |
Tool | Description |
| List studies |
| Solve synchronously |
| Solve in background |
| Get progress |
| Cancel solving |
| Wait for completion |
| List solutions |
| List datasets |
Tool | Description |
| Evaluate expression |
| Evaluate scalar |
| Get time steps |
| Get sweep values |
| Export data |
| Export plot image |
| List export nodes |
| List plot nodes |
Tool | Description |
| Get documentation |
| List available docs |
| Physics quick guide |
| Troubleshooting help |
| Best practices |
| Search PDF docs |
| PDF search status |
| List PDF modules |
3D thermal analysis of a silicon chip with Through-Silicon Via (TSV).
Geometry: 60×60×5 µm chip, 5 µm diameter TSV hole, 10×10 µm heat source
# Key steps:
# 1. Create chip block and TSV cylinder
# 2. Boolean difference (subtract TSV from chip)
# 3. Add Silicon material (k=130 W/m·K)
# 4. Add Heat Transfer physics
# 5. Set heat flux on top, temperature on bottom
# 6. Solve and evaluate temperature distributionScript: client_script/create_chip_tsv_final.py
Run:
cd /path/to/comsol-mcp
python client_script/create_chip_tsv_final.pyResults: Temperature rise from ambient with heat flux of 1 MW/m²
3D laminar flow simulation in a microfluidic channel.
Geometry: 600×100×50 µm rectangular channel
# Key steps:
# 1. Create rectangular channel block
# 2. Add water material (ρ=1000 kg/m³, μ=0.001 Pa·s)
# 3. Add Laminar Flow physics
# 4. Set inlet velocity (1 mm/s), outlet pressure
# 5. Add Transport of Diluted Species for mixing
# 6. Solve and evaluate velocity profileScript: client_script/create_micromixer_auto.py
Run:
cd /path/to/comsol-mcp
python client_script/create_micromixer_auto.pyResults: Velocity distribution, concentration mixing profile
Models are saved with structured paths:
./comsol_models/{model_name}/{model_name}_{timestamp}.mph
./comsol_models/{model_name}/{model_name}_latest.mphExample:
./comsol_models/chip_tsv_thermal/chip_tsv_thermal_20260216_140514.mph
./comsol_models/chip_tsv_thermal/chip_tsv_thermal_latest.mph# Access Java model via property (not callable)
jm = model.java # NOT model.java()
# Create component with True flag
comp = jm.component().create('comp1', True)
# Create 3D geometry
geom = comp.geom().create('geom1', 3)
# Create physics with geometry reference
physics = comp.physics().create('spf', 'LaminarFlow', 'geom1')
# Boundary condition with selection
bc = physics.create('inl1', 'InletBoundary')
bc.selection().set([1, 2, 3])
bc.set('U0', '1[mm/s]')Physics | Condition | Property |
Heat Transfer | HeatFluxBoundary |
|
Heat Transfer | TemperatureBoundary |
|
Heat Transfer | ConvectiveHeatFlux |
|
Laminar Flow | InletBoundary |
|
Laminar Flow | OutletBoundary |
|
The mph library creates a singleton COMSOL client. Only one Client can exist per Python process:
# This is handled in session.py - client is kept alive and models are cleared
client.clear() # Clear models instead of full disconnectPDF search supports offline operation with local HuggingFace cache:
# Set mirror for China
export HF_ENDPOINT=https://hf-mirror.comPhase | Description | Status |
1 | Basic framework + Session + Model | Done |
2 | Parameters + Solving + Results | Done |
3 | Geometry + Physics + Mesh | Done |
4 | Embedded knowledge + Tool docs | Done |
5 | PDF vector retrieval | Done |
6 | Integration tests | In Progress |
Complete Phase 6 - Full integration test with proper boundary conditions
Visualization Export - Generate PNG images from plot groups
LSP Warnings - Fix type hints in physics.py
More Examples - Add electrostatics, solid mechanics cases
Error Handling - Improve error messages and recovery
URI | Description |
| Session information |
| Model tree structure |
| Model parameters |
| Physics interfaces |
MIT
Connect to a remote COMSOL server.
Args: port: Port number the COMSOL server is listening on host: Server hostname or IP address (default: 'localhost')
Returns: Connection info or error message
| Name | Required | Description | Default |
|---|---|---|---|
| port | Yes | ||
| host | No | localhost |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavior. It states connection and return of info/error, but lacks details on side effects, session management, blocking behavior, or authentication requirements.
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 concise and front-loaded with the purpose. The docstring format with Args/Returns is efficient, and every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the return description is adequate but minimal. Missing context about prerequisites (e.g., server must be running) and relation to sibling tools. Could note that this is typically used before other COMSOL operations.
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%, but the description adds meaning by explaining 'port' and 'host' (including default). This compensates for the missing schema descriptions, though port range or format could be more specific.
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 the resource ('remote COMSOL server'), distinguishing it from sibling tools like 'comsol_disconnect' and 'comsol_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 explicit guidance on when to use this tool versus alternatives, nor prerequisites like server availability. The implied usage is to connect before other operations, but no exclusions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Disconnect from COMSOL and clear all models from memory.
Returns: Success status and message
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses destructive action (clearing models) without annotations. However, could mention side effects like unsaved work loss. Still, good 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?
Two concise sentences with front-loaded purpose. No redundant information.
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 no parameters and no output schema, description adequately covers purpose and return. Could elaborate on return format.
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; schema coverage is 100% trivially. Baseline 4 applies.
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 'Disconnect from COMSOL and clear all models from memory', using specific verb and resource. It distinguishes itself from siblings like comsol_connect and comsol_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?
Implied usage context (disconnect after connecting), but no explicit when-not or alternatives guidance.
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 client session.
Args: cores: Number of processor cores to use (default: all available) version: COMSOL version to use, e.g., '6.0' (default: latest installed)
Returns: Session info including version and core count, or error message
| Name | Required | Description | Default |
|---|---|---|---|
| cores | No | ||
| version | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It discloses parameters and defaults, and mentions return values include session info or error, but does not detail side effects, auth needs, or whether it affects existing sessions.
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 concise with clear sections for Args and Returns, containing only essential 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?
While the tool is simple, the description lacks details on prerequisites (e.g., COMSOL installation), whether the session starts synchronously, and the exact structure of 'session info'. An output schema is missing, but the return description is minimal.
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%, so the description adds critical meaning: clarifies 'cores' default is 'all available' and 'version' default is 'latest installed' with example '6.0'. This significantly aids the agent.
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 'Start a local COMSOL client session' uses a specific verb ('start') and resource ('COMSOL client session'), clearly distinguishing it from sibling tools like comsol_connect (connect to remote) and comsol_status.
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 implies usage for local sessions via the word 'local', but does not explicitly state when to use this tool versus alternatives like comsol_connect, nor does it provide when-not or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the current COMSOL session status.
Returns: Session information including connection status, version, and loaded models
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description must fully disclose behavioral traits. It states the tool 'gets' status and 'returns' information, implying no side effects, but does not confirm read-only behavior, whether it requires an active session, or any potential impacts. 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?
The description is extremely concise with two sentences that directly convey purpose and return value. No unnecessary information.
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 status tool with no parameters and no output schema, the description gives a reasonable overview of what is returned. However, it lacks specifics about the format or structure of the return value, and could clarify if it works only when COMSOL is connected.
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 in the input schema, so schema description coverage is 100% by default. The description does not need to add parameter details; baseline score of 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets the current COMSOL session status and returns session information including connection status, version, and loaded models. This distinguishes it from sibling tools like comsol_connect (connect to COMSOL) or comsol_start (start session).
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 implies the tool is used to check session status, but does not explicitly state when to use it versus alternatives or provide prerequisites (e.g., requires an active session). No exclusions or when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all datasets in a model.
Datasets represent solution data that can be evaluated or visualized.
Args: model_name: Model name (default: current model)
Returns: List of dataset names
| Name | Required | Description | Default |
|---|---|---|---|
| model_name | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It states the tool lists datasets but does not discuss scope (e.g., all models vs. current model), error behavior, pagination, performance, or side effects. The agent has limited insight into the tool's operational 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 extremely concise and well-structured. It opens with a clear purpose statement, then briefly defines the term 'datasets,' followed by parameter documentation. Every sentence provides value with no extraneous text.
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's simplicity (one optional parameter, no output schema), the description is reasonably complete. It explains the return value ('list of dataset names') and the parameter. However, it omits details like authentication requirements, potential errors, or whether the list is exhaustive. For a simple read tool, this is acceptable but not exceptional.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, so the description compensates by explaining the model_name parameter's purpose and default value ('Model name (default: current model)'). This adds meaningful context beyond the schema, which only shows the type and default null. The description is adequate for the single parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool lists all datasets in a model, specifying the action (list) and resource (datasets). It also provides a brief explanation of what datasets are, aiding understanding. However, it does not explicitly distinguish from sibling tools, though no other tool appears to directly compete.
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 lacks guidance on when to use this tool versus alternatives. It does not mention prerequisites, when not to use it, or how it compares to other tools like model_list or solutions_list. The agent must infer usage context from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get documentation on a specific topic.
Available topics:
"mph_api": MPh Python API reference
"physics_guide": Physics interfaces and boundary conditions
"workflow": Step-by-step modeling workflows
Args: topic: Documentation topic to retrieve
Returns: Documentation content for the topic
| Name | Required | Description | Default |
|---|---|---|---|
| topic | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the burden of behavioral disclosure. It only states that it 'returns documentation content' but does not mention whether the operation is purely read-only, if any authentication is needed, or how errors (e.g., invalid topic) are handled. This is insufficient for a tool with no annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exceptionally concise: two sentences plus a bulleted list of topics. It front-loads the main action and presents the parameter options clearly without any superfluous text.
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 retrieval tool with one parameter and no output schema, the description adequately covers what the tool does and what inputs are valid. However, it omits details like error handling, response format, or whether the documentation content is raw text or structured, which could be helpful but are not critical.
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 the 'topic' parameter, but the description compensates by listing three specific valid topics with brief explanations. This adds significant meaning beyond the bare schema, though it could be improved by including format constraints or error handling notes.
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 'Get documentation on a specific topic' and enumerates the available topics, making the tool's purpose unambiguous. It distinguishes itself from siblings like docs_list (which lists topics) and physics_get_guide (which is physics-specific).
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 implies the tool should be used when a user needs documentation on a known topic, but it provides no explicit guidance on when to prefer this tool over alternatives like physics_get_guide or docs_list. No exclusions or conditions are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all available documentation topics.
Returns: List of available documentation topics with descriptions
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes return value as list of topics with descriptions. No annotations exist, so burden is on description. It is adequate but lacks details on output format or side effects (none expected).
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 with no wasted words. Structure is simple but effective for a zero-parameter tool.
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 no output schema, description should specify return format. It says 'list of topics with descriptions' but not whether it's an array of strings or objects. Adequate but minimal.
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, so baseline 4. No additional parameter info needed beyond 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?
Description clearly states it lists documentation topics. Differentiates from sibling 'docs_get' which likely retrieves a specific topic, though not explicit.
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 docs_get. Does not specify prerequisites or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add a block (rectangular cuboid) to the geometry.
Args: position: Base position [x, y, z] in meters (default: origin) size: Dimensions [width, depth, height] in meters (default: 1m cube) geometry_name: Geometry sequence name (default: first geometry) component_name: Component name (default: 'comp1') feature_name: Feature name (auto-generated if None) model_name: Model name (default: current model)
Returns: Created block info
| Name | Required | Description | Default |
|---|---|---|---|
| position | No | ||
| size | No | ||
| geometry_name | No | ||
| component_name | No | comp1 | |
| feature_name | No | ||
| model_name | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It mentions auto-generation of feature_name but does not describe side effects (e.g., whether it modifies existing geometry, error handling, or what 'Created block info' entails). Critical behavioral traits are missing.
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 concise: one sentence for purpose, then a list of parameters with one-line explanations, and a return note. It is front-loaded and each sentence earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description adequately documents all parameters but lacks behavioral context such as what happens if geometry_name is null or invalid, error conditions, and the format of the return value. For a tool with 6 optional parameters and no output schema, more completeness is needed.
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 compensates excellently. Each parameter is explained with meaningful context: units for position and size, defaults, and optionality for geometry_name, feature_name, model_name. This adds value beyond the sparse 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 adds a block (rectangular cuboid) to the geometry. The verb 'Add' and resource 'block' are specific, and the shape name distinguishes it from sibling geometry_add_circle, cylinder, etc. However, it does not explicitly contrast with alternatives, missing a chance to 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?
The description provides no guidance on when to use this tool versus other geometry_add_* tools or when to avoid it. There is no mention of prerequisites, context, or comparison, leaving the agent without decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add a circle to a 2D geometry or work plane.
Args: position: Center [x, y] in meters radius: Radius in meters (default: 0.5) geometry_name: Geometry sequence name model_name: Model name (default: current model)
Returns: Created circle info
| Name | Required | Description | Default |
|---|---|---|---|
| position | No | ||
| radius | No | ||
| geometry_name | No | ||
| model_name | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. While it states 'Add a circle,' implying mutation, it does not describe side effects, required state (e.g., geometry must exist), or what happens if parameters are omitted beyond defaults. No information about rate limits or destructive behavior.
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 relatively brief and includes a structured Args and Returns section. It is not verbose, but the return value is minimally described ('Created circle info'), which could be expanded. Overall, it is appropriately sized.
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 tool among many geometry_add_* siblings and without an output schema, the description adequately explains parameters but lacks context on when to choose this shape and how it interacts with existing geometry. It does not specify whether geometry_name must refer to an existing geometry or work plane, leaving ambiguity.
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, the description adds meaningful semantics for all four parameters: position as center [x, y] in meters, radius in meters, geometry_name as geometry sequence name, model_name with default current model. This clarifies usage beyond the schema's defaults and types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as adding a circle to a 2D geometry or work plane. It distinguishes itself from sibling tools like geometry_add_block, geometry_add_cylinder, geometry_add_rectangle, and geometry_add_sphere by specifying the shape.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus other geometry_add_* tools. It does not mention prerequisites, such as the need for an existing geometry or work plane, nor does it suggest alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add a cylinder to the geometry.
Args: position: Center of base [x, y, z] in meters radius: Radius in meters (default: 0.5) height: Height in meters (default: 1.0) geometry_name: Geometry sequence name (default: first geometry) component_name: Component name (default: 'comp1') feature_name: Feature name (auto-generated if None) model_name: Model name (default: current model)
Returns: Created cylinder info
| Name | Required | Description | Default |
|---|---|---|---|
| position | No | ||
| radius | No | ||
| height | No | ||
| geometry_name | No | ||
| component_name | No | comp1 | |
| feature_name | No | ||
| model_name | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It only states it adds a cylinder, but does not disclose side effects, whether it modifies existing geometry, what 'add' means in terms of geometry sequences, or the format of return info.
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?
Structured with Args and Returns, brief and to the point. No redundant information.
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 7 parameters, no annotations, and no output schema, the description is insufficient. It does not explain parameter behavior or return format, making it incomplete for effective tool usage.
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 compensates with parameter descriptions (position, radius, height, etc.). However, lacks details on geometry_name (which geometry?), component_name, and feature_name semantics.
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 adds a cylinder to the geometry. The verb 'add' and resource 'cylinder' are specific, but it does not differentiate from sibling tools like geometry_add_block or geometry_add_sphere.
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 like adding other shapes or using geometry_add_feature. No mention of prerequisites or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add a geometry feature to a geometry sequence.
Common feature types:
Block: Rectangular block (3D)
Cylinder: Cylinder (3D)
Sphere: Sphere (3D)
Cone: Cone (3D)
WorkPlane: Working plane for 2D geometry
Rectangle: Rectangle (2D)
Circle: Circle (2D)
Polygon: Polygon from points
Import: Import CAD geometry
Union, Intersection, Difference: Boolean operations
Args: feature_type: Type of geometry feature (Block, Cylinder, etc.) geometry_name: Geometry sequence name (default: first geometry) feature_name: Name for the feature (auto-generated if None) model_name: Model name (default: current model) **kwargs: Feature-specific properties (position, size, etc.)
Returns: Created feature info
| Name | Required | Description | Default |
|---|---|---|---|
| feature_type | Yes | ||
| geometry_name | No | ||
| feature_name | No | ||
| model_name | No | ||
| kwargs | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It mentions adding a feature and returning info, but lacks details on side effects (e.g., whether the geometry is built or needs rebuilding), permissions, or constraints. Behavioral traits are partially disclosed.
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 well-structured with a clear action sentence, a list of feature types, and an 'Args' section. It is concise but informative, with no redundant information. Front-loaded with the main purpose.
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 5 parameters, no output schema, and many sibling tools, the description is moderately complete. It explains parameters and returns but lacks examples and behavioral details. Familiar users might find it sufficient, but novices may need more context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description must compensate. It explains the purpose of each parameter (feature_type, geometry_name, etc.) and mentions kwargs as feature-specific properties. However, it does not provide examples or format for kwargs, nor allowed values for feature_type beyond the list. Adds some meaning but not comprehensive.
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 'Add a geometry feature to a geometry sequence' and lists common feature types, which distinguishes it from sibling tools. However, it does not explicitly differentiate from specific geometry_add_* tools (e.g., geometry_add_block).
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 lists feature types implying when to use this tool, but does not provide explicit guidance on when to use this generic version versus the specific shape tools (siblings). No when-not-to-use or alternative recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add a rectangle to a 2D geometry or work plane.
Args: position: Base position [x, y] in meters size: Dimensions [width, height] in meters geometry_name: Geometry sequence name (default: first geometry) component_name: Component name (default: 'comp1') feature_name: Feature name (auto-generated if None) model_name: Model name (default: current model)
Returns: Created rectangle info
| Name | Required | Description | Default |
|---|---|---|---|
| position | No | ||
| size | No | ||
| geometry_name | No | ||
| component_name | No | comp1 | |
| feature_name | No | ||
| model_name | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes only the action of adding a rectangle without disclosing behavioral traits like side effects, dependency on geometry existence, or performance implications. No annotations exist to compensate.
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?
Concise docstring format with Args and Returns sections. The first sentence clearly states purpose. Every sentence serves a purpose, though the Returns section is minimal.
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?
Covers the basics for a simple add tool but lacks details on return value format and prerequisites like needing an open geometry or work plane. Output schema is absent, so description carries additional burden.
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?
Provides brief descriptions for each parameter (e.g., 'position: Base position [x, y] in meters') and default values, adding some meaning beyond the schema. However, with 0% schema coverage, more detail would be beneficial.
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 'Add a rectangle to a 2D geometry or work plane' with specific verb and resource, distinguishing it from siblings like geometry_add_block or geometry_add_circle.
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 (e.g., circle, block). Does not specify prerequisites or context such as requiring an existing geometry.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add a sphere to the geometry.
Args: position: Center [x, y, z] in meters radius: Radius in meters (default: 0.5) geometry_name: Geometry sequence name (default: first geometry) component_name: Component name (default: 'comp1') feature_name: Feature name (auto-generated if None) model_name: Model name (default: current model)
Returns: Created sphere info
| Name | Required | Description | Default |
|---|---|---|---|
| position | No | ||
| radius | No | ||
| geometry_name | No | ||
| component_name | No | comp1 | |
| feature_name | No | ||
| model_name | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided. The description only states the action and returns 'Created sphere info' but does not disclose side effects, model requirements, or whether the operation is reversible. Minimal behavioral context beyond the basic action.
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 structured as a clear docstring with Args and Returns. It is concise, with no unnecessary words, and front-loades the primary purpose.
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 6 parameters and no output schema or annotations, the description covers all parameters and mentions return info. However, it omits context like the need for an active model or coordinate system, which would aid completeness.
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%, so the description fully compensates. It explains every parameter: position as center [x,y,z], radius with default 0.5, geometry_name, component_name, feature_name, model_name. This adds meaning that the schema titles alone lack.
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 'Add a sphere to the geometry,' which is a specific verb-resource pair. It distinguishes from sibling tools like geometry_add_block or geometry_add_circle that add other shapes.
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 implies usage for adding a sphere shape but offers no explicit guidance on when to use this tool versus alternatives like geometry_add_block. No when-not or prerequisites 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 boolean difference (subtract objects from another).
Args: input_object: Object to subtract from (e.g., 'blk1') objects_to_subtract: Objects to remove (e.g., ['cyl1']) geometry_name: Geometry sequence name (default: first geometry) component_name: Component name (default: 'comp1') feature_name: Feature name (auto-generated if None) model_name: Model name (default: current model)
Returns: Created difference operation info
| Name | Required | Description | Default |
|---|---|---|---|
| input_object | Yes | ||
| objects_to_subtract | Yes | ||
| geometry_name | No | ||
| component_name | No | comp1 | |
| feature_name | No | ||
| model_name | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully describe behavior. It only says 'create a boolean difference' and returns 'operation info', but does not disclose whether the operation is destructive, modifies existing objects, or creates new ones. No side effects or permissions are 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?
The description is concise: one purpose line followed by a structured Args list and a return line. It is front-loaded with the main operation. Minor waste: the 'Returns' line is vague but acceptable.
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 no output schema, the description should provide more detail about the return value. 'Created difference operation info' is too generic. Covers parameter definitions but lacks usage context, error handling, or examples. 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 description coverage is 0%, so description must compensate. The description provides brief role explanations for parameters (e.g., 'Object to subtract from'), and default values for some. This adds meaning beyond the schema's title-only fields, but explanations are still high-level and lack details like allowed formats 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 explicitly states 'Create a boolean difference (subtract objects from another)' with a specific verb and resource. It clearly distinguishes from the sibling tool geometry_boolean_union by naming the operation.
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 or when to prefer alternatives. Does not mention that geometry_boolean_union exists for union operations or provide any context about prerequisites or common use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a boolean union of geometry objects.
Args: input_objects: Names of objects to unite geometry_name: Geometry sequence name model_name: Model name (default: current model)
Returns: Created union operation info
| Name | Required | Description | Default |
|---|---|---|---|
| input_objects | Yes | ||
| geometry_name | No | ||
| model_name | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It only says 'Creates' and 'Returns info', but does not disclose if it modifies existing geometry, how overlaps are handled, or any side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and includes Args/Returns in a structured format. No wasted words, but could be more informative without extra length.
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 boolean union tool with no output schema and no annotations, the description is incomplete. It lacks details on required state, error conditions, and behavior of the union operation.
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% description coverage, so the description must add meaning. It adds brief explanations for each parameter (e.g., 'Names of objects to unite'), which is helpful but still vague for geometry_name and model_name.
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 'Create a boolean union of geometry objects' which is a specific verb-resource pair. It distinguishes from sibling geometry_boolean_difference by name and description.
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 union versus alternatives like difference or add operations. No 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.
Build the geometry sequence to generate the actual geometry.
This must be called after adding/modifying geometry features.
Args: geometry_name: Geometry sequence name (default: build all) component_name: Component name (default: 'comp1') model_name: Model name (default: current model)
Returns: Build status
| Name | Required | Description | Default |
|---|---|---|---|
| geometry_name | No | ||
| component_name | No | comp1 | |
| model_name | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description mentions it is a build operation (likely mutable) and requires prior modifications. However, it does not detail destructiveness, permission needs, or reversible nature.
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 short, efficient sentences. The first clearly states purpose and prerequisite, the second lists parameters. No wasted text.
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?
No output schema; returns are only 'Build status' without detail. No mention of possible failures or side effects. Adequate for a simple tool but lacks completeness for a production setting.
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% coverage (no descriptions), but the description adds meaning for each parameter: defaults for geometry_name (build all), component_name ('comp1'), model_name (current model).
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 the tool builds the geometry sequence to generate the actual geometry, and distinguishes from sibling tools that add/modify features (e.g., geometry_add_block).
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 states 'must be called after adding/modifying geometry features', providing clear context. Does not mention alternatives, but the sister list of geometry modification tools implies when to use others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new geometry sequence in the model's component.
IMPORTANT: A component must exist first. Use model_create_component if needed.
Args: geometry_name: Name for the geometry sequence (default: 'geom1') space_dimension: Space dimension - 2 for 2D, 3 for 3D (default: 3) component_name: Component name (default: 'comp1') model_name: Model name (default: current model)
Returns: Created geometry info
| Name | Required | Description | Default |
|---|---|---|---|
| geometry_name | No | ||
| space_dimension | No | ||
| component_name | No | comp1 | |
| model_name | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It lists parameter defaults and returns 'Created geometry info,' but does not disclose side effects, error conditions, or whether the operation is destructive. This is acceptable but lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise: a clear purpose statement, an important note, and a bulleted parameter list. Every sentence serves a purpose, no 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?
Given the sibling tools, the description adequately identifies this as the step to create a geometry container before adding primitives. It includes a prerequisite note and parameter defaults, but lacks details on how to set the current model or what 'geometry sequence' entails.
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%, so the description must compensate. It explains each parameter with defaults and special notes (e.g., space_dimension: '2 for 2D, 3 for 3D'). This adds useful meaning beyond the schema, though more detail on allowed values or constraints would improve it.
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 'Create a new geometry sequence in the model's component,' using a specific verb and resource. This distinguishes it from sibling tools like geometry_add_block which add primitives to an existing geometry sequence.
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 explicitly warns that a component must exist first and suggests model_create_component if needed. This provides a clear prerequisite, though it does not explicitly contrast with alternatives like geometry_add_*.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get all boundaries from a geometry with their properties.
Use this to identify which boundary numbers correspond to which faces before setting boundary conditions.
Args: geometry_name: Geometry sequence name (default: first geometry) model_name: Model name (default: current model)
Returns: List of boundaries with their numbers and areas
| Name | Required | Description | Default |
|---|---|---|---|
| geometry_name | No | ||
| model_name | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states the return value ('List of boundaries with their numbers and areas') and implies a read-only operation with no side effects, which is transparent.
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 concise (5 lines) and front-loaded with purpose, then usage guidance, then parameters. Every sentence adds value.
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 no output schema, the description includes return value details. It covers purpose, when to use, and parameter meanings, making it complete for a simple retrieval 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 input schema has 0% description coverage (only titles). The description adds meaning by listing both parameters with their defaults ('geometry_name: Geometry sequence name (default: first geometry)'), significantly augmenting 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 'Get all boundaries from a geometry with their properties,' specifying the verb and resource. It differentiates from sibling geometry tools like 'geometry_list' or 'geometry_list_features' by focusing on boundaries.
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 explicitly advises using this tool 'to identify which boundary numbers correspond to which faces before setting boundary conditions,' providing clear context. While it doesn't list when not to use it or alternatives, the guidance is strong.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Import geometry from a CAD file.
Supported formats: STEP, IGES, STL, NASTRAN, etc.
Args: file_path: Path to the CAD file geometry_name: Geometry sequence name import_type: Import type (CAD, mesh, etc.) model_name: Model name (default: current model)
Returns: Import operation info
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | Yes | ||
| geometry_name | No | ||
| import_type | No | CAD | |
| model_name | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description must fully disclose behavior. It only states the basic import action and supported formats, but fails to mention whether the tool overwrites existing geometry, requires a current model, or how it handles errors (e.g., invalid file path). The return value is vaguely described as 'Import operation info', offering no concrete behavioral detail.
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 concise (4 lines excluding header) and front-loaded with the main action. The parameter list is readable but uses plain text without bullet formatting, which could be improved for clarity. Every sentence adds value, with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and 4 parameters with 0% schema coverage, the description is incomplete. It lacks details on prerequisites (e.g., must a model exist?), error handling, and return value structure. The tool interacts with files and likely has side effects (e.g., modifying the current model), but these are not mentioned.
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 adds some value by labeling each parameter: file_path, geometry_name, import_type, model_name, and noting defaults (e.g., model_name defaults to 'current model'). However, it does not provide valid value examples for import_type (e.g., 'CAD', 'mesh') or clarify geometry_name's format, leaving gaps for the agent to infer.
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 'Import geometry from a CAD file' and lists supported formats, distinguishing it from sibling tools that create primitives (e.g., geometry_add_block) or manipulate geometry. The verb 'import' and resource 'geometry from a CAD file' are specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when a CAD file is available and lists supported formats (STEP, IGES, STL, NASTRAN, etc.), providing usage context. However, it lacks explicit exclusions or comparisons to alternative geometry creation tools, such as geometry_create or geometry_add_*. This leaves the agent to infer when to import versus build from scratch.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all geometry sequences in a model.
Args: model_name: Model name (default: current model)
Returns: List of geometry sequence names
| Name | Required | Description | Default |
|---|---|---|---|
| model_name | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It specifies the return type (list of names) and implies a read operation, but does not disclose safety, side effects, or permissions. Adequate but minimal.
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 with two sentences plus an Args/Returns block. Every sentence adds value, 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?
Given no output schema, the description adequately explains the return value. It covers the single parameter well. For a simple list tool, this is sufficient, though it could mention if the list is empty or behavior with invalid model names.
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 description adds meaning to the single parameter 'model_name' by stating it defaults to the current model (schema only shows anyOf string/null with default null). This clarifies the default behavior, compensating for 0% schema description coverage.
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 'List all geometry sequences in a model,' using a specific verb and resource. It distinguishes from sibling tools like geometry_list_features (lists features within a sequence) and geometry_add_* (adds geometry).
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 implies usage (listing geometry sequences) but does not explicitly state when to use it versus alternatives or provide conditions for use. No guidance on when not to use or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all features in a geometry sequence.
Args: geometry_name: Geometry sequence name (default: first geometry) model_name: Model name (default: current model)
Returns: List of geometry features with their types
| Name | Required | Description | Default |
|---|---|---|---|
| geometry_name | No | ||
| model_name | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only says 'list', implying read-only but not explicitly. It lacks details about side effects or any 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 extremely concise with a clear purpose, Args, and Returns sections. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool, the description is fairly complete, specifying the return type (list of geometry features with types). Given no output schema, this is adequate, though it could elaborate on what constitutes a 'feature'.
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%, but the description adds meaningful parameter explanations: geometry_name defaults to first geometry, model_name defaults to current model. This goes beyond the schema's titles and defaults.
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 lists all features in a geometry sequence. It distinguishes from siblings like geometry_list (lists geometries) and geometry_add_feature (adds features).
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. The description does not mention prerequisites or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run a mesh sequence to generate the mesh.
This executes the meshing operations defined in the mesh sequence.
Args: mesh_name: Mesh sequence name (default: run all mesh sequences) model_name: Model name (default: current model)
Returns: Mesh generation status
| Name | Required | Description | Default |
|---|---|---|---|
| mesh_name | No | ||
| model_name | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It explains that executing 'meshing operations defined in the mesh sequence' and returns status, but does not disclose side effects, error conditions, or blocking behavior. Adds some context about defaults but lacks depth.
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 concise, with a clear header and structured argument list. Each sentence is informative, though the 'Args' section could be integrated into the main body for slightly better flow.
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 2 parameters and no output schema, the description covers the basic functionality and return status. However, it lacks information on prerequisites (e.g., existing mesh sequence), error handling, or integration with other tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description includes an 'Args' section explaining each parameter's meaning and default behavior, compensating for the 0% schema coverage. It adds value beyond the raw schema by clarifying default actions for null mesh_name and model_name.
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's purpose: 'Run a mesh sequence to generate the mesh.' It specifies the action (run) and resource (mesh sequence), and distinguishes from siblings like mesh_info or mesh_list.
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 vs alternatives or prerequisites. The description does not mention when not to use it or provide alternative tool names for similar tasks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get information about a mesh.
Args: mesh_name: Mesh sequence name (default: first mesh) model_name: Model name (default: current model)
Returns: Mesh statistics including element counts
| Name | Required | Description | Default |
|---|---|---|---|
| mesh_name | No | ||
| model_name | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes return as 'Mesh statistics including element counts' implying read-only, but does not explicitly state non-destructive behavior or side effects. With no annotations, more detail would be beneficial.
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?
Concise docstring with clear Args/Returns sections. No wasted words; every sentence adds value.
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?
Adequately covers tool purpose and parameters. With no output schema, description could elaborate on return structure, but for a simple info tool it is sufficient.
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?
Adds meaning beyond the schema by providing default values and human-readable descriptions for both parameters ('Mesh sequence name', 'Model name'). Compensates for 0% schema description coverage.
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 'Get information about a mesh' with verb and resource. Distinguishes from sibling mesh tools like mesh_create or mesh_list by focusing on info retrieval, but could be more specific about what information.
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 mesh_list or other info tools. Does not specify prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all mesh sequences in a model.
Args: model_name: Model name (default: current model)
Returns: List of mesh sequence names
| Name | Required | Description | Default |
|---|---|---|---|
| model_name | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description does not disclose behavioral traits like safety or side effects. It only states it returns a list, leaving the agent to infer read-only nature.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise, front-loaded, and includes only essential information: action, parameters, and return. 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?
For a simple list tool with one optional parameter and no output schema, the description covers the main purpose and return format. It could mention ordering or filtering, but it is adequate.
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%, but the description explains the parameter: 'Model name (default: current model)', adding meaningful context 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 'List all mesh sequences in a model' with a specific verb and resource. It distinguishes from siblings like mesh_create and mesh_info.
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 mesh_info or mesh_create. It implies usage for listing but lacks exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Clone a model to create a copy for comparison or modification.
Args: model_name: Name of the model to clone (default: current model) new_name: Name for the cloned model (auto-generated if not provided) set_current: Whether to set the clone as current model (default: False)
Returns: Info about the cloned model, or error message
| Name | Required | Description | Default |
|---|---|---|---|
| model_name | No | ||
| new_name | No | ||
| set_current | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose side effects, prerequisites (e.g., model must exist), or whether the operation is safe. It only states the basic cloning action without behavioral context.
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 concise with a clear structure: purpose sentence, then Args list, then Returns. Every sentence provides necessary information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple clone tool, the description covers parameters and return type. However, it lacks prerequisites (e.g., model must exist) and potential side effects (e.g., does it save to disk?), so completeness is adequate but not full.
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%, but the description adds meaning for all three parameters, explaining their purpose, defaults, and behavior (e.g., 'auto-generated if not provided'). This compensates well for the schema's lack of descriptions.
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 'Clone a model to create a copy for comparison or modification.' It uses a specific verb ('clone') and resource ('model'), and distinguishes from sibling tools like model_create or model_save_version by indicating a copy operation.
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 implies usage for creating a copy for comparison or modification, but does not explicitly state when not to use or mention alternatives. Some guidance is present, but lacks exclusions or context vs. other model tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new empty COMSOL model.
Args: name: Optional name for the model (auto-generated if not provided) set_current: Whether to set this as the current active model (default: True)
Returns: Model info including name, or error message
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | ||
| set_current | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must bear the full burden of behavioral disclosure. However, it only states the action and arguments without detailing side effects, prerequisites, or resource impacts. For a tool that likely requires an active COMSOL connection, this omission is significant.
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 efficient: one main sentence then a compact list for arguments. Every element serves a purpose with no 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?
While the description covers the creation action and arguments, it omits prerequisite context (e.g., need for an active connection). The return value is vaguely described as 'Model info' without structure details, but that is acceptable for a simple create 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 Args section adds meaningful context beyond the schema, explaining the auto-generation of name and the default of set_current. Despite the schema having 0% property descriptions, the description compensates well.
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 it creates a new empty COMSOL model, which is a specific verb+resource combination. This clearly distinguishes it from sibling tools like model_clone 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 explicit guidance on when to use this tool versus alternatives like model_clone or model_load. Usage is only implied by the name and description, lacking when-not-to-use context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a component in the model (required before adding geometry/physics).
Components are containers for geometry, physics, materials, and mesh. Must be created before adding geometry or physics.
Args: component_name: Name for the component (default: 'comp1') model_name: Model name (default: current model)
Returns: Created component info
| Name | Required | Description | Default |
|---|---|---|---|
| component_name | No | comp1 | |
| model_name | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses that the tool performs a write operation ('Create'), specifies it is a prerequisite, and mentions return type ('Created component info'). Additional details like error cases or permissions would improve 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 concise, front-loaded with the purpose, and includes a structured args list. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple creation tool with no output schema, the description covers essential information: purpose, prerequisites, and parameters. Could mention potential errors or side effects, but it's adequate for correct usage.
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 description adds meaning beyond the input schema, which has 0% description coverage. It explains both parameters with names, defaults, and context (e.g., 'default: current model' for model_name), fully compensating for the schema's lack of descriptions.
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 'Create a component in the model' and explains its prerequisite role for geometry and physics. It distinguishes from sibling tools like model_create and geometry_add_*, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states 'Must be created before adding geometry or physics,' providing clear guidance on when to use. Does not explicitly mention alternatives or when not to use, but the context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get best practices for different modeling categories.
Categories:
"geometry": Geometry creation and import
"mesh": Mesh generation strategies
"physics": Physics interface configuration
"solver": Solver configuration and optimization
"results": Results evaluation and visualization
Args: category: Category to get best practices for
Returns: Best practices for the specified category
| Name | Required | Description | Default |
|---|---|---|---|
| category | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description does not disclose any behavioral traits such as read-only nature, prerequisites, or side effects. Minimal disclosure beyond the obvious knowledge retrieval purpose.
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?
Description is well-structured with a title, bullet list, and Args/Returns sections. It is concise and front-loaded, though the Args/Returns section is somewhat redundant.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Missing output schema and description of return format (e.g., string, structure). Does not mention prerequisites like COMSOL connection or error cases. Adequate for a simple lookup but incomplete for a production 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?
Schema has 0% description coverage, but description explicitly lists allowed category values (geometry, mesh, physics, solver, results), compensating for the lack of enum. This adds significant meaning beyond the raw 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?
Description clearly states it gets best practices for different modeling categories, with a specific verb and resource. Lists five concrete categories, distinguishing it from sibling operational tools like geometry_add_block or physics_add.
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 docs_get or troubleshoot. The description only lists categories but does not provide context for decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed information about a model's structure and contents.
Args: model_name: Name of the model to inspect (default: current model)
Returns: Detailed model structure including parameters, physics, studies, etc.
| Name | Required | Description | Default |
|---|---|---|---|
| model_name | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose all behavioral traits. It mentions what is returned (parameters, physics, studies) but does not state that the tool is read-only or safe to call without side effects. This omission is a gap for a tool that likely does not modify state.
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 concise, uses a standard docstring format with Args and Returns, and front-loads the core purpose. Every sentence contributes value with 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?
Given the tool's simplicity (1 optional parameter) and no output schema, the description provides sufficient context about input and return values. It covers the essential behavioral aspects, though it could explicitly state the read-only nature.
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%, but the description adds meaning by stating the default value ('current model') and explaining the parameter's role ('Name of the model to inspect'). This compensates well for the lack of schema detail.
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's purpose with a specific verb ('Get') and resource ('detailed information about a model's structure and contents'), which distinguishes it from sibling tools like model_create, model_list, 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?
The description implies usage for inspection tasks but lacks explicit guidance on when to use this tool versus alternatives (e.g., model_list for listing models, physics_list for physics info). No 'when not to use' or alternative names are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all models currently loaded in the COMSOL session.
Returns: List of models with their names, file paths, and status
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must cover behavioral aspects. It mentions the return type (list of models with names, file paths, status), which is helpful, but does not disclose any side effects, authorization needs, or limitations. For a simple read-only list, this is acceptable but not fully transparent.
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: a single sentence stating the purpose followed by a clear list of return fields. 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?
For a parameterless listing tool with no output schema, the description adequately covers the behavior and return values. It is fully sufficient for an agent to understand and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the input schema covers 100% with no additional information needed. The description adds no parameter details, which is appropriate. Baseline is 3 per rubric due to high schema coverage.
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 'List all models currently loaded in the COMSOL session,' specifying a concrete action and resource. This distinguishes it from siblings like model_create or model_load, which perform different operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives (e.g., model_inspect for details, model_list_components for components). It lacks context on prerequisites or scenarios where it's appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all components in a model.
Args: model_name: Model name (default: current model)
Returns: List of component names
| Name | Required | Description | Default |
|---|---|---|---|
| model_name | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses the tool's behavior: it lists components and returns their names. No side effects or hidden behaviors are relevant for a read-only list operation.
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 with two sentences for purpose and one line each for args and returns, containing no extraneous information.
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's simplicity, the description adequately covers what it does and what it returns. It lacks error handling or format details, but for a straightforward list operation this is sufficient.
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 description adds value to the schema by explaining that model_name refers to the model to query and defaults to the current model. This clarifies usage beyond the schema's type information.
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 'List all components in a model' with specific verb and resource, and it is distinct from sibling tools which focus on other aspects like creating, cloning, or inspecting 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?
The description does not mention when to use this tool versus alternatives, nor does it provide context for selection. Usage is implied but not explicitly guided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Load a COMSOL model from a .mph file.
Args: file_path: Absolute or relative path to the .mph model file set_current: Whether to set this as the current active model (default: True)
Returns: Model info including name, file path, and version, or error message
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | Yes | ||
| set_current | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description provides basic behavioral info: it loads a file and returns model info including name, path, version, or error. However, it does not disclose failure modes (e.g., file not found, invalid format) or side effects (e.g., overriding current model).
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 concise, with 4 lines total. The key purpose comes first ('Load a COMSOL model from a .mph file'), followed by structured argument details and return info. No redundant or irrelevant sentences.
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 of the tool (2 parameters, no output schema), the description covers the main operation, arguments, and return format. Minor gaps include error handling and dependencies (e.g., requires COMSOL connection), but overall it is sufficient for selection and 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 coverage is 0%, so the description compensates by explaining file_path as 'Absolute or relative path to the .mph model file' and set_current as 'Whether to set this as the current active model (default: True)'. This adds meaningful context beyond the schema's type and title.
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 'Load a COMSOL model from a .mph file' with a specific verb and resource. It distinguishes from sibling tools like model_create (new) and model_clone (clone existing) by focusing on loading an existing file.
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. It does not mention prerequisites like needing a running COMSOL session or connected instance, nor does it advise against use in certain scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Remove a model from memory.
Args: model_name: Name of the model to remove
Returns: Confirmation or error message
| Name | Required | Description | Default |
|---|---|---|---|
| model_name | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description should disclose behavioral traits. It only says 'remove from memory' but does not specify side effects, whether unsaved data is lost, or if removal is reversible.
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?
Description is short and front-loaded with purpose. However, the Args/Returns section is boilerplate and could be more informative. It earns its place but lacks depth.
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 no output schema and no annotations, the description is too minimal. It does not explain return values, error conditions, or prerequisites for successful removal.
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 adds a single line for model_name ('Name of the model to remove'), which adds little beyond the schema title. No details on format, lookup, 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?
Description clearly states the action: remove a model from memory. It distinguishes from sibling tools like model_create, model_load, etc., which have different purposes.
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 or prerequisites. The description does not mention when removal is appropriate, e.g., after saving or when model is no longer needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Save a COMSOL model to file.
Args: model_name: Name of the model to save (default: current model) file_path: Path to save to (default: original file path) format: Save format - 'Comsol', 'Java', 'Matlab', or 'VBA' (default: Comsol/.mph)
Returns: Save confirmation with file path, or error message
| Name | Required | Description | Default |
|---|---|---|---|
| model_name | No | ||
| file_path | No | ||
| format | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must carry the full burden. It does not disclose potential side effects such as overwriting existing files, state changes, or permission requirements. The return value is vaguely described as 'Save confirmation with file path, or error message'.
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 concise and well-structured with a clear header, bullet-pointed parameters, and a returns section. Every sentence provides necessary information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers basic usage and return format but misses context such as prerequisites (e.g., model must be loaded), error conditions in detail, and behavior when file_path is omitted. Given the simple tool, it is minimally adequate.
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 adds significant value by explaining each parameter's purpose and default value. It enumerates valid format options, which the schema lacks.
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 ('a COMSOL model to file'), distinguishing it from sibling tools like model_load or model_save_version effectively.
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 (e.g., model_save_version). The description does not specify prerequisites or conditions for use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Save a model with a timestamp version suffix.
Creates a new file with structured path: ./comsol_models/{model_name}/{model_name}_{timestamp}.mph
Also saves a 'latest' copy: ./comsol_models/{model_name}/{model_name}_latest.mph
Useful for version control and design iterations.
Args: model_name: Name of the model to save (default: current model) description: Optional description for this version (stored in metadata)
Returns: Save confirmation with versioned file path, or error message
| Name | Required | Description | Default |
|---|---|---|---|
| model_name | No | ||
| description | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description fully discloses behavior: creates timestamped file and a 'latest' copy, stores optional description in metadata. No contradictions.
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?
Well-structured: summary, path details, usage, arguments, returns. No fluff, every sentence adds value.
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?
Comprehensive for a versioned save tool: explains what it does, its parameters, and return value. No missing 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?
With 0% schema coverage, description adds meaning: explains 'model_name' defaults to current model, 'description' is optional and stored in metadata. Could mention acceptable formats but suffices.
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 'Save a model with a timestamp version suffix', indicating a specific verb and resource. Distinguishes from sibling 'model_save' by emphasizing versioning and file path structure.
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?
Implies usage for version control and design iterations, and contrasts with 'model_save' (sibling) which likely does simple saving without versioning. However, lacks explicit when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Set the current active model for subsequent operations.
Args: model_name: Name of the model to set as current
Returns: Confirmation or error message
| Name | Required | Description | Default |
|---|---|---|---|
| model_name | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It states it sets the current active model but does not disclose side effects, whether the operation is destructive, error handling for non-existent models, or state changes. The Returns section mentions 'confirmation or error message' but lacks detail.
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 concise with a main sentence and structured Args/Returns sections. It avoids unnecessary words, though it could be more informative without sacrificing conciseness.
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 output schema and annotations, the description is minimally adequate for a simple setter. However, it omits key contextual details like when to use it, prerequisites, and error handling, making it incomplete for an agent to reliably invoke without additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description adds meaning by stating 'Name of the model to set as current' for the model_name parameter. However, it does not specify if it's a name, ID, or any constraints like case sensitivity or existence. The baseline is higher due to low coverage, but the description only partially compensates.
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 'Set' and the resource 'current active model', and explains the purpose 'for subsequent operations'. It distinguishes this tool from sibling tools like model_list, model_create, etc., which have different actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites (e.g., model must exist) or when not to use it. No comparison to sibling tools is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add a multiphysics coupling between physics interfaces.
Common coupling types:
"ThermalStress": Couples Heat Transfer and Solid Mechanics
"FluidStructureInteraction": Couples Fluid Flow and Solid Mechanics
"ElectromechanicalForces": Couples Electrostatics and Solid Mechanics
"JouleHeating": Couples Electric Currents and Heat Transfer
Args: coupling_type: Type of multiphysics coupling physics_list: Names of physics interfaces to couple model_name: Model name (default: current model)
Returns: Created coupling info
| Name | Required | Description | Default |
|---|---|---|---|
| coupling_type | Yes | ||
| physics_list | Yes | ||
| model_name | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description has full burden. It discloses the action (adds coupling) and return type but omits side effects, error behavior, or what happens if coupling already exists.
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?
Description is short, front-loaded with purpose, and well-structured with Args/Returns sections. No redundant sentences; every sentence adds value.
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?
Adequately covers parameters and purpose but is incomplete on return value details ('Created coupling info' is vague) and parameter relationships (e.g., coupling_type implies required physics). Given no output schema, 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?
Schema description coverage is 0%, but the description lists all three parameters with examples for coupling_type, adding significant meaning beyond the schema. However, it lacks constraints on physics_list (e.g., required number of interfaces) and model_name format.
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 the verb 'Add a multiphysics coupling between physics interfaces,' identifies the resource (multiphysics coupling), and lists common coupling types, distinguishing it from sibling tools that add single physics interfaces.
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?
Provides examples of coupling types and their combinations, hinting at usage context, but does not explicitly state when to use this tool versus alternatives like physics_add_* or any prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get or set the description of a parameter.
Args: name: Parameter name text: New description text (if None, returns current description) model_name: Model name (default: current model)
Returns: Parameter description, or confirmation of update
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| text | No | ||
| model_name | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses that the tool can get or set based on the 'text' parameter and returns either description or confirmation, but lacks detail on side effects (e.g., overwriting) or confirmation format.
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 concise with a clear top-level statement, structured Args, and Returns. Every sentence adds value, and there is no unnecessary text.
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 get/set tool, the description covers the main purpose and parameters. The return value is stated ('Parameter description, or confirmation of update'), though more specific format details could improve completeness. Given no output schema, this is adequate.
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%, but the description clearly explains each parameter: 'name' (parameter name), 'text' (new description, returns current if None), and 'model_name' (model name, default current). This adds meaning 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 'Get or set the description of a parameter,' specifying the action (get/set) and the resource (parameter description). It distinguishes from sibling tools like param_get and param_set, which deal with parameter values.
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 implies usage for getting or setting parameter descriptions but lacks explicit guidance on when to use this tool versus alternatives like param_get or param_set. No exclusions or alternative references are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the value of a model parameter.
Args: name: Parameter name model_name: Model name (default: current model) evaluate: If True, return evaluated numerical value; if False, return expression string
Returns: Parameter value and description, or error message
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| model_name | No | ||
| evaluate | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the full burden. It transparently states it returns a value/description or error, and explains the evaluate parameter's effect. No side effects are mentioned, but for a getter this is 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?
The description is concise, front-loads the purpose, and uses clear docstring format. No redundant sentences, but could be slightly more streamlined.
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?
No output schema exists, so description should detail return format. It states 'Parameter value and description, or error message' but lacks specifics on structure. Prerequisites (model exist) not mentioned, but adequate for a simple getter.
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 description adds meaning beyond the schema by explaining each parameter's purpose (name, model_name with default, evaluate toggle between numeric and string). Schema coverage is low (0%) but description compensates well.
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 'Get the value of a model parameter' and distinguishes it from siblings like param_list (list all) and param_description (description only) by focusing on value retrieval.
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 implies when to use via parameter explanations but does not explicitly state when to use param_get versus alternatives like param_list or param_description. No when-not or alternative guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all parameters in a model.
Args: model_name: Model name (default: current model) evaluate: If True, return numerical values; if False, return expressions
Returns: Dictionary of all parameters with values and descriptions
| Name | Required | Description | Default |
|---|---|---|---|
| model_name | No | ||
| evaluate | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description declares return type but lacks disclosure on side effects, permissions, or safety. 'List' implies read-only but is not explicit.
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?
Very concise: one-line summary, Args/Returns section. No redundant information. Well-structured for quick parsing.
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?
Explains parameters and return value sufficiently for a simple list tool. Lacks context on usage relative to siblings, but overall adequate.
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?
Description adds meaning beyond the schema, explaining 'model_name' default and 'evaluate' behavior. Schema coverage 0% so description carries full parameter explanation burden.
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 'List all parameters in a model' with specific verb and resource. Distinguishes from parameter-specific tools (param_get, param_set) 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 this tool versus alternatives like param_get or param_description. Does not provide context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Set the value of a model parameter.
Args: name: Parameter name value: Parameter value (can include units, e.g., "5[V]", "1.5[mm]") model_name: Model name (default: current model) description: Optional description for the parameter
Returns: Confirmation with new value, or error message
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| value | Yes | ||
| model_name | No | ||
| description | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions return value (confirmation or error) and the ability to include units in the value. However, it does not specify whether the parameter is created if it doesn't exist, or any side effects.
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 highly concise, using a single introductory sentence followed by structured parameter and returns sections. Every sentence adds value, with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple set operation with 4 parameters and no output schema, the description covers the basics but lacks details on error handling, behavior for non-existent parameters, and any prerequisites. It is adequate but not exhaustive.
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 adds significant meaning: it explains each parameter's purpose, including the units format for value and the default for model_name. This compensates for the sparse 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 verb 'Set' and the resource 'model parameter', making the tool's function unambiguous. It distinguishes from sibling tools like param_get or param_list by its action.
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 explicit guidance on when to use this tool versus alternatives. While the context implies it's for setting parameters, it lacks any 'when to use' or 'when not to use' direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Set up a parametric sweep for a parameter.
Args: parameter_name: Name of the parameter to sweep values: List of parameter values to sweep through model_name: Model name (default: current model) study_name: Study to attach sweep to (default: first study)
Returns: Sweep configuration confirmation, or error message
| Name | Required | Description | Default |
|---|---|---|---|
| parameter_name | Yes | ||
| values | Yes | ||
| model_name | No | ||
| study_name | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It mentions return values (configuration or error) but does not disclose side effects, required permissions, or whether it modifies existing state. Critical details about behavior are missing.
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 reasonably concise but includes unnecessary sections like 'Args:' and 'Returns:' that add no value. The core information is dense but could be more streamlined without the docstring format.
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 no output schema and the complexity of a parametric sweep, the description fails to explain prerequisites, error conditions, or the overall process. It lacks crucial context for correct usage.
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 the description adds some meaning beyond the schema by noting defaults (e.g., 'model_name: Model name (default: current model)'). However, explanations for 'values' and 'study_name' are minimal, not fully compensating for the lack of schema descriptions.
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 sets up a parametric sweep for a parameter, using a specific verb and resource. However, it does not explicitly distinguish from sibling tools like param_set or param_list, which could cause ambiguity.
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 lacks context for prerequisites (e.g., model/study must exist) or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all available COMSOL documentation modules.
Returns: List of module names with file counts
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description notes it returns a list of module names with file counts, implying a read-only operation, but does not mention any other behavioral traits such as permissions, side effects, or limitations.
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 clear sentences with no unnecessary words. Front-loaded with verb and resource, then details return value.
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 zero parameters and no output schema, the description adequately explains the return value (list of module names with file counts). It is minimally complete for a simple listing 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?
Tool has no parameters; schema coverage is 100% (vacuous). Baseline score of 4 applies as description adds no parameter information beyond what is already captured.
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 verb 'list' and resource 'COMSOL documentation modules'. It is specific but does not distinguish from sibling tools like 'docs_list' which might serve a similar purpose.
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. Sibling tools include 'docs_list', 'docs_get', and 'pdf_search' which could be used for related purposes, but no comparison is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search COMSOL PDF documentation using semantic search.
This searches through the indexed COMSOL documentation (60+ modules) to find relevant information about physics, modeling, and API usage.
Args: query: Search query describing what you're looking for n_results: Number of results to return (default: 5, max: 20) module: Optional module filter (e.g., "CFD_Module", "Heat_Transfer_Module")
Returns: Search results with relevant documentation snippets
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | ||
| n_results | No | ||
| module | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes it as a semantic search returning snippets. No annotations provided, so description carries full burden. Does not disclose potential side effects, rate limits, or specific behavioral traits beyond the basic read operation.
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?
Concise and well-structured: brief intro, then clear Args and Returns sections. No redundant information. Front-loaded with purpose.
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?
Covers purpose, all parameters with defaults and examples, and return type. Missing details on return format/structure, but acceptable for a search tool given no output schema. Siblings provide related context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema coverage, the description adds useful context for all parameters: query (search query description), n_results (default and max), module (example values). Enhances understanding beyond bare 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?
Clearly states it searches COMSOL PDF documentation using semantic search. Specifies scope (60+ modules) and purpose (find info on physics, modeling, API usage). Distinguishes from sibling tools like docs_get and pdf_list_modules.
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?
Implied usage for searching documentation by query and optional module filter. No explicit guidance on when to use this vs alternatives like docs_get or pdf_list_modules. Lacks when-not or context-specific recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the status of the PDF documentation search system.
Returns: Status information including whether the knowledge base is built, number of indexed documents, and available modules.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses return values including status info, indexed documents, and available modules. No annotations provided, so description carries the burden, which it does adequately.
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 concise sentences with no wasted words. Efficiently communicates purpose and return information.
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?
No output schema, but description covers the key return elements. Adequate for a simple status tool, though could mention response format.
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; baseline score of 4. Description adds context about return values that complements 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 gets the status of the PDF documentation search system, distinguishing it from sibling tools like pdf_search and pdf_list_modules.
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 like pdf_search or pdf_list_modules. The usage context is implied but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add a physics interface to the model.
Common physics types:
"Electrostatics" or "es": Electrostatic field analysis
"ElectricCurrents" or "ec": Electric current conduction
"SolidMechanics" or "solid": Structural stress analysis
"HeatTransfer" or "ht": Heat transfer in solids
"LaminarFlow" or "spf": Fluid dynamics
Args: physics_type: Type identifier (e.g., "Electrostatics", "es") component_name: Component to add physics to (default: first component) model_name: Model name (default: current model)
Returns: Created physics interface info
| Name | Required | Description | Default |
|---|---|---|---|
| physics_type | Yes | ||
| component_name | No | ||
| model_name | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It does not disclose that adding physics modifies the model, whether a model must be loaded, or any side effects. 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?
Well-organized with header, common types list, and parameter descriptions. The list of types is helpful but slightly verbose; otherwise efficient.
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?
Adequately covers the main purpose and parameters, but lacks context about model prerequisites, return value details, and mutability. For a tool with no output schema and no annotations, more context is needed.
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 coverage, the description adds meaning beyond the schema: explains physics_type with examples and defaults for component_name and model_name. However, it could be more detailed (e.g., valid values for component_name).
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 'Add a physics interface to the model' and lists common physics types with examples, distinguishing it from sibling tools that add specific physics types.
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?
Provides common physics types and aliases but does not explicitly guide when to use this generic version versus specific sibling tools like physics_add_electrostatics. No when-not-to-use or alternatives mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add Electrostatics physics interface for electric field analysis.
Args: domain_selection: Selection name for domains (default: all domains) model_name: Model name (default: current model)
Returns: Created physics info
| Name | Required | Description | Default |
|---|---|---|---|
| domain_selection | No | ||
| model_name | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description bears full burden. It implies state modification ('Add') but does not explicitly state that it modifies the model or requires an existing model. No mention of side effects, required permissions, or performance implications.
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?
Description is very concise: one-sentence purpose followed by standard Args/Returns. Every sentence serves a clear purpose. No redundancy or wordiness.
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 tool with 2 parameters and no output schema, the description is moderately complete. It covers purpose and parameter defaults, but lacks information about prerequisites (e.g., model must exist), return value details beyond 'Created physics info', and error conditions. Considering no annotations, more context would be beneficial.
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 provides default values ('all domains', 'current model') and brief meaning for both parameters. This adds value beyond schema, but lacks detailed explanations such as valid format for selection names or model 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?
Verb 'Add' with specific resource 'Electrostatics physics interface' clearly states the action. The phrase 'for electric field analysis' provides additional context. Among sibling physics_add tools, this one is distinct due to 'electrostatics', meeting the high bar for specificity.
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 other physics_add tools like physics_add_heat_transfer or the generic physics_add. No prerequisites or exclusions are mentioned. The description is purely declarative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add Heat Transfer physics for thermal analysis.
Args: domain_selection: Selection name for domains (default: all domains) model_name: Model name (default: current model)
Returns: Created physics info
| Name | Required | Description | Default |
|---|---|---|---|
| domain_selection | No | ||
| model_name | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided. The description lacks details on side effects, prerequisites (e.g., model existence), or whether the operation is destructive. It only states the action and return value without behavioral context.
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 concise with a clear structure (description, args, returns) in numpy docstring style. No extraneous content, but the args and returns sections are minimal.
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 complexity of adding physics (likely modifying a model), the description is incomplete. It does not mention required model state, potential errors, or the nature of the return value. Without annotations or output schema, more context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage. The description compensates by naming parameters and stating defaults ('all domains', 'current model'), but does not explain what 'Selection name for domains' means or specify valid formats. Adds moderate 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 'Add Heat Transfer physics for thermal analysis,' with a specific verb and resource. The tool's name and description distinguish it from sibling tools like physics_add (generic) and other specific physics adders.
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 such as physics_add or other physics_add_* tools. The description does not include context for selection or exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add Laminar Flow physics for fluid dynamics.
Args: domain_selection: Selection name for domains (default: all domains) model_name: Model name (default: current model)
Returns: Created physics info
| Name | Required | Description | Default |
|---|---|---|---|
| domain_selection | No | ||
| model_name | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description only states that it adds physics and returns info. It does not disclose behavioral traits like modification of the existing model, prerequisites (e.g., open model), or side effects. With no annotations, the burden falls on the description, which it insufficiently addresses.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and uses a clear Args/Returns structure. It contains no redundant information. However, it could be slightly more efficient by integrating the parameter descriptions into a fluent sentence.
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's simplicity (2 optional params, no output schema), the description covers the basic purpose and parameters. It lacks context about prerequisites (e.g., need an active model) and does not mention the return structure beyond 'Created physics info'. Adequate but with clear gaps.
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 the input schema has 0% description coverage, the description provides brief explanations for both parameters (domain_selection and model_name) with defaults. This adds meaningful context beyond the schema, though it could be more detailed (e.g., expected format of selection 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 that the tool adds Laminar Flow physics for fluid dynamics, using a specific verb and resource. However, it does not differentiate itself from sibling tools like physics_add_electrostatics or the generic physics_add, missing an opportunity to clarify when this specific physics is appropriate.
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?
There is no guidance on when to use this tool versus alternatives. Given many sibling physics_add_* tools and a generic physics_add, the description should include context such as 'use for incompressible fluid flow' or link to related physics.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add Solid Mechanics physics for structural analysis.
Args: domain_selection: Selection name for domains (default: all domains) model_name: Model name (default: current model)
Returns: Created physics info
| Name | Required | Description | Default |
|---|---|---|---|
| domain_selection | No | ||
| model_name | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but lacks disclosure of important traits such as idempotency, error handling, or effects if already added. Only basic parameter defaults and return type are 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?
Extremely concise with no wasted words. Two sentences cover purpose and parameters, front-loaded with the primary action.
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 no output schema and only 2 parameters, the description is too brief. It does not describe the return format ('Created physics info' is vague) or any side effects, leaving crucial gaps 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?
Schema coverage is 0%, so description must compensate. While it lists parameters with defaults, it does not explain what 'domain_selection' or 'model_name' mean in the COMSOL context (e.g., selection syntax, valid values). Insufficient detail.
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 adds Solid Mechanics physics for structural analysis. The verb 'Add' and resource 'Solid Mechanics physics' are specific, distinguishing it from other physics_add_* tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives like physics_add_electrostatics or the generic physics_add. The description only states the purpose without context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generic boundary condition setup with boundary selection.
Use this tool to configure any boundary condition by specifying:
The physics interface name
The boundary condition type
The boundary numbers to apply the condition to
Properties specific to the boundary condition
Common boundary condition types by physics:
Heat Transfer (ht):
TemperatureBoundary: Set T0 (temperature)
HeatFluxBoundary: Set q0 (heat flux)
ConvectiveHeatFlux: Set h (coefficient), Text (ambient temp)
Laminar Flow (spf):
InletBoundary: Set U0 (velocity)
OutletBoundary: Set p0 (pressure)
Wall: No-slip wall
Solid Mechanics (solid):
Fixed: Fixed constraint
BoundaryLoad: Set Fx, Fy, Fz or FAx, FAy, FAz
Args: physics_name: Name of the physics interface boundary_condition_type: Type of boundary condition boundary_numbers: List of boundary numbers properties: Dictionary of property names and values model_name: Model name (default: current model)
Returns: Configuration confirmation
| Name | Required | Description | Default |
|---|---|---|---|
| physics_name | Yes | ||
| boundary_condition_type | Yes | ||
| boundary_numbers | Yes | ||
| properties | No | ||
| model_name | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose all behavioral traits. It only states the basic operation and a vague return of 'Configuration confirmation'. It lacks information about side effects (e.g., whether existing conditions are overwritten), required permissions, or error handling, which are critical for a mutation tool.
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 well-structured with sections but contains some redundancy (e.g., listing steps and then repeating information in 'Args'). It is moderately concise but could be tightened without losing clarity.
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 output schema and low schema description coverage, the description provides adequate parameter semantics and usage examples. However, it omits details like return value structure, error scenarios, and confirmation of side effects, leaving some gaps for a tool with 5 parameters.
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%, but the description compensates by listing each parameter in the 'Args:' section, providing examples and explaining the usage of 'properties' with specific dictionary keys for different physics. This adds significant value beyond the schema titles.
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 is for 'Generic boundary condition setup with boundary selection' and provides specific examples for different physics interfaces. However, it does not explicitly differentiate from the sibling tool 'physics_configure_boundary', which likely has overlapping functionality.
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 implies usage by listing steps and common boundary condition types per physics, but it does not provide explicit when-to-use or when-not-to-use guidance, nor does it mention alternatives or prerequisites. Usage context is implied but not clarified.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Configure a boundary condition for a physics interface.
Common boundary conditions for Electrostatics:
"Ground": Zero potential boundary
"ElectricPotential": Specified voltage
"SurfaceChargeDensity": Surface charge
"ZeroCharge": Zero normal displacement field
Common for Solid Mechanics:
"Fixed": Fixed constraint
"Roller": Roller constraint
"Symmetry": Symmetry plane
"BoundaryLoad": Applied force/pressure
Common for Heat Transfer:
"Temperature": Fixed temperature
"HeatFlux": Heat flux boundary
"ConvectiveHeatFlux": Convection cooling
"Symmetry": Symmetry (adiabatic)
Args: physics_name: Name of the physics interface boundary_condition: Type of boundary condition boundary_selection: Boundary/edge numbers to apply condition to properties: Dictionary of property names and values model_name: Model name (default: current model)
Returns: Created boundary condition info
| Name | Required | Description | Default |
|---|---|---|---|
| physics_name | Yes | ||
| boundary_condition | Yes | ||
| boundary_selection | Yes | ||
| properties | No | ||
| model_name | No |
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 authentication, side effects (e.g., model modification), or constraints. The 'Returns' line is minimal.
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 moderately concise with bullet-like lists for common conditions, but some verbosity exists. It is front-loaded with the verb and purpose.
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 5 parameters, 3 required, no enums, no output schema, the description provides basic context and examples, but lacks exhaustive details on properties and return value format.
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%, but the description adds meaning by listing parameters and providing examples for boundary_condition values. However, the properties parameter is only described vaguely as a dictionary without example keys.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Configure a boundary condition for a physics interface' with clear verb+resource. Examples for Electrostatics, Solid Mechanics, and Heat Transfer help clarify the purpose, but it does not differentiate from siblings like physics_boundary_selection or physics_setup_flow_boundaries.
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 implies usage through examples of common boundary conditions per physics, but lacks explicit when-to-use, when-not-to-use, or alternative tools like physics_setup_flow_boundaries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a list of available physics interfaces organized by category.
Returns: Dictionary of physics categories and their interfaces
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure. It explains the return format (dictionary of categories and interfaces) but lacks information on side effects (none expected), performance, or required state (e.g., need a connection). The description implies a read operation but does not explicitly state it.
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 with two sentences, front-loaded with the main action. No unnecessary words. Every sentence adds value.
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?
The tool is simple with no parameters and no output schema, but the description explains the return type (dictionary of categories and interfaces). However, it lacks context about how the returned data integrates with other tools (e.g., using the interface names in physics_add). Given the complexity, it is minimally viable but could be more helpful.
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?
There are zero parameters, so the schema coverage is effectively 100%. The description adds no parameter information, which is acceptable given no parameters exist. According to the rule, 0 parameters yields a baseline of 4.
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 retrieves available physics interfaces organized by category. The verb 'Get' and resource 'available physics interfaces' are specific, and it distinguishes from sibling tools like physics_list (which likely lists interfaces in a model) and physics_add (which adds a physics interface).
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 context, prerequisites, or exclusions. For example, it could suggest using physics_get_available before physics_add to see available options.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a quick guide for a specific physics type.
Available physics types:
"electrostatics": Electric field and capacitance
"heat_transfer": Thermal analysis
"solid_mechanics": Stress and deformation
"fluid_flow": CFD analysis
Args: physics_type: Type of physics to get guide for
Returns: Quick reference guide for the physics type
| Name | Required | Description | Default |
|---|---|---|---|
| physics_type | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavior. It describes a simple non-destructive retrieval operation with no side effects, which is sufficient for a guide tool. It does not elaborate on permissions or data sources, but the behavior is straightforward.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise with a clear structure: purpose statement, enumerated list of physics types, args/returns. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter, no output schema, and no annotations, the description fully covers what the tool does, what the parameter values mean, and the return type. It is complete for agents to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema only names the parameter (physics_type) without description. The description adds extensive meaning by listing valid values and their meanings, compensating for the 0% schema coverage.
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 gets a quick guide for a specific physics type. It lists available types with definitions, distinguishing it from sibling tools like physics_add (which adds physics interfaces) or physics_get_available.
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 implies when to use (when a reference guide is needed) but does not explicitly state when not to use or mention alternative tools. The context of sibling tools and the provided list of types gives some guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Interactive setup wizard for Laminar Flow boundary conditions.
This tool helps identify and configure flow boundary conditions:
Lists all available boundaries
Prompts user to select inlet, outlet, and wall boundaries
Configures appropriate boundary conditions
Args: physics_name: Name of the Laminar Flow physics interface model_name: Model name (default: current model)
Returns: Boundary information and setup instructions
| Name | Required | Description | Default |
|---|---|---|---|
| physics_name | No | Laminar Flow | |
| model_name | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description adds behavioral context by indicating it is interactive and prompts user for boundary selection and configuration. However, it omits details like whether it modifies the model, required permissions, or state changes after completion.
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 relatively concise with clear bulleted steps and Args/Returns sections. However, it includes some redundancy (e.g., 'Interactive setup wizard') and could be slightly more streamlined.
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 and no output schema, the description covers the main workflow and return value. But missing context such as whether it works on the current model, effect on existing boundaries, and guidance on when to use the interactive vs non-interactive sibling.
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%, but the description provides additional meaning: physics_name is 'Name of Laminar Flow physics interface' and model_name is 'Model name (default: current model)'. This partly compensates but lacks detail on valid values or format.
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 is an interactive setup wizard for Laminar Flow boundary conditions. It lists specific steps and distinguishes from sibling tools like physics_setup_flow_boundaries (non-interactive) and physics_interactive_setup_heat (different physics).
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 when-to-use vs alternatives, such as when to prefer physics_setup_flow_boundaries or physics_interactive_setup_heat. It implies interactive use but offers no explicit guidance on context or preconditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Interactive setup wizard for Heat Transfer boundary conditions.
This tool helps identify and configure thermal boundary conditions:
Lists all available boundaries
Shows typical boundary condition types for thermal analysis
Provides setup instructions
Args: physics_name: Name of the Heat Transfer physics interface model_name: Model name (default: current model)
Returns: Boundary information and setup instructions
| Name | Required | Description | Default |
|---|---|---|---|
| physics_name | No | Heat Transfer in Solids | |
| model_name | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must fully disclose behavioral traits. It states the tool is 'interactive' and 'provides setup instructions,' suggesting it does not modify the model directly, but it does not confirm whether it has side effects, requires user interaction during execution, or any constraints. The lack of transparency about potential state changes or prerequisites is a gap.
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 relatively short and includes a clear intro, numbered steps, and an args section. However, the args section merely restates the schema, wasting space without adding value. It is not overly verbose, but could be more efficient by omitting redundant parameter listings.
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 no output schema and only 2 parameters, the description should provide a complete picture of what the tool returns and how it behaves. It mentions returning 'Boundary information and setup instructions' but gives no specifics on the structure or content of the output. The steps are vague (e.g., 'Shows typical boundary condition types' – does it show a list or a form?). Missing details on interaction flow reduce completeness.
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%: the description lists the parameter names (physics_name, model_name) with their defaults, but does not explain their purpose, format, or constraints beyond what the schema already indicates. For example, what values are valid for 'physics_name'? This adds no semantic value, and for a low-coverage situation, the description should compensate but fails to do so.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as an 'Interactive setup wizard for Heat Transfer boundary conditions.' It specifies the domain (Heat Transfer) and the action (setup wizard), distinguishing it from general physics tools or other interactive setups like physics_interactive_setup_flow. However, it does not explicitly differentiate from the sibling tool physics_setup_heat_boundaries, which may overlap in functionality.
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 lists steps that the tool performs (list boundaries, show types, provide instructions) but does not include any guidance on when to use this tool versus alternatives, such as physics_setup_heat_boundaries. No 'when-to-use' or 'when-not-to-use' information is provided, leaving the agent without decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all physics interfaces defined in a model.
Args: model_name: Model name (default: current model)
Returns: List of physics interface names
| Name | Required | Description | Default |
|---|---|---|---|
| model_name | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only states the tool lists interfaces, implying a read-only operation, but does not describe side effects, authorization needs, error handling for missing models, or other important behaviors.
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, using two sentences to state the purpose and one sentence per parameter and return. Every sentence adds value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one optional parameter, no output schema), the description covers the core functionality. It explains the parameter and return value. Minor gaps like error handling or behavior with invalid model names are acceptable at this complexity level.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, leaving the description to explain the parameter. It clarifies that model_name defaults to the current model, which adds meaning beyond the schema. However, it could elaborate on format 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 tool lists all physics interfaces in a model, using a specific verb and resource. It distinguishes itself from siblings like physics_list_features (which lists features of a physics interface) and physics_add (which adds a new physics interface).
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 does not mention contexts where listing interfaces is appropriate or mention any prerequisites (e.g., model must exist).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all features (boundary conditions, domain settings) in a physics interface.
Args: physics_name: Name of the physics interface model_name: Model name (default: current model)
Returns: List of physics features
| Name | Required | Description | Default |
|---|---|---|---|
| physics_name | Yes | ||
| model_name | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It does not disclose behavioral traits such as what happens if the physics_name is invalid, whether the tool can be called multiple times safely, or any side effects. The description is minimal and does not add transparency beyond 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?
The description is short and front-loaded with the core purpose. The Args and Returns sections are somewhat redundant given the schema, but do not harm. However, there is no wasted text; each part serves to clarify the tool's interface.
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 no output schema, the description only says 'List of physics features' without detailing the structure or content of the list. For a domain-specific tool (COMSOL), this is insufficient. The tool has two parameters and likely returns structured data, but the description does not specify what a 'feature' is or the format of the list.
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%, meaning the schema provides no descriptions for parameters. While the Args section in the description mentions physics_name and model_name, it does not explain their purpose, expected format, or constraints. For example, it does not clarify that model_name defaults to the current model. The description adds negligible value over parameter 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: 'List all features (boundary conditions, domain settings) in a physics interface.' It specifies the resource (features in a physics interface) and distinguishes from siblings like physics_list (which lists interfaces) and geometry_list_features (which lists geometry features).
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. For example, it does not mention prerequisites (e.g., need an existing physics interface) or contexts where this tool is preferred over others like physics_get_available. The description simply states what it does without usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Remove a physics interface from the model.
Args: physics_name: Name of the physics interface to remove model_name: Model name (default: current model)
Returns: Removal confirmation
| Name | Required | Description | Default |
|---|---|---|---|
| physics_name | Yes | ||
| model_name | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description does not disclose the destructive nature of removal or any side effects. It merely states 'Removal confirmation' without explaining what that entails. No annotations are present to offset this gap.
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 concise with a clear sentence and an Args block. It is front-loaded with the key action. Minor improvement would be to remove the 'Args' prefix and integrate into prose.
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?
The description covers the basic purpose and parameters but lacks details on return value format, error handling, or prerequisites like the physics interface needing to exist. For a simple tool with no output schema or annotations, it is adequate but not thorough.
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 Args section adds meaning beyond the input schema by explaining each parameter: 'physics_name' is described as the name of the physics interface, and 'model_name' includes its default value. Schema coverage is low (0%), so the description compensates 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 the action ('Remove') and the resource ('a physics interface from the model'). It distinguishes from sibling tools like physics_add and model_remove, which operate on different resources or actions.
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, error conditions, or scenarios where removal is inappropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Assign a material to physics domains.
Args: physics_name: Name of the physics interface material_name: Name of the material to assign domain_selection: Domain numbers (default: all domains for this physics) model_name: Model name (default: current model)
Returns: Assignment confirmation
| Name | Required | Description | Default |
|---|---|---|---|
| physics_name | Yes | ||
| material_name | Yes | ||
| domain_selection | No | ||
| model_name | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description bears full responsibility for disclosing behavioral traits. It only states the action and return value ('Assignment confirmation'), but fails to mention side effects (e.g., overwriting previous assignments), required permissions, or whether the operation is reversible. The description is minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise: one line for purpose, then a bullet list for parameters, and a returns line. No extra information or fluff. Everything 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?
Given the tool has 4 parameters, no output schema, and no annotations, the description is somewhat adequate but lacks depth. It covers the basic action and parameter semantics but omits error conditions, prerequisites, and detailed behavior. For a simple assignment tool, it meets minimum viability.
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 the description must compensate. The 'Args' section describes each parameter: 'physics_name' and 'material_name' as names, 'domain_selection' as domain numbers with default, and 'model_name' with default. This adds meaning beyond the schema, though more detail on domain selection format would improve it.
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's action: 'Assign a material to physics domains.' The verb 'assign' and the resource 'material' are specific, and the tool is distinct from siblings like 'physics_add' or 'physics_configure_boundary' which handle different aspects of physics setup.
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 explicit guidance on when to use this tool versus alternatives, nor does it mention prerequisites or exclusions. The purpose is clear, but usage context (e.g., requires existing physics interface, should be called after adding physics) is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Setup Laminar Flow boundary conditions with specified boundaries.
This tool configures inlet velocity and outlet pressure boundary conditions for a fluid flow simulation.
Args: physics_name: Name of the Laminar Flow physics interface inlet_boundaries: List of boundary numbers for inlets outlet_boundaries: List of boundary numbers for outlets inlet_velocity: Inlet velocity expression (default: "1[mm/s]") outlet_pressure: Outlet pressure expression (default: "0") model_name: Model name (default: current model)
Returns: Configuration confirmation
| Name | Required | Description | Default |
|---|---|---|---|
| physics_name | Yes | ||
| inlet_boundaries | Yes | ||
| outlet_boundaries | Yes | ||
| inlet_velocity | No | 1[mm/s] | |
| outlet_pressure | No | 0 | |
| model_name | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description does not disclose behavioral traits beyond the action itself, such as whether it modifies existing settings, side effects, or validation behavior. For a configuration tool, this is a significant gap.
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 concise with a clear purpose sentence, a brief explanation, and a structured parameter list. No redundant information; every sentence adds value. Front-loaded with the main purpose.
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?
The description adequately covers parameter semantics and indicates a return value ('Configuration confirmation'), but lacks details on error cases, return format, or interactions with other physics setup tools. Given no output schema, some completeness gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, but the description provides a detailed 'Args' section explaining each parameter's purpose and defaults (e.g., inlet_velocity default '1[mm/s]'). This adds meaning beyond the schema titles, though it lacks constraints or examples.
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 'Setup Laminar Flow boundary conditions with specified boundaries.' It specifies the verb 'setup' and the resource 'Laminar Flow boundary conditions', and the context distinguishes it from sibling tools like physics_interactive_setup_flow and physics_setup_heat_boundaries.
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. No mention of prerequisites (e.g., physics must be added first) or when not to use it. The description lacks any usage context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Setup Heat Transfer boundary conditions with specified boundaries.
This tool configures thermal boundary conditions for heat transfer simulation:
Heat flux boundaries (heat sources)
Temperature boundaries (heat sinks)
Convective cooling/heating boundaries
Args: physics_name: Name of the Heat Transfer physics interface heat_flux_boundaries: List of boundary numbers for heat flux temperature_boundaries: List of boundary numbers for fixed temperature convection_boundaries: List of boundary numbers for convection heat_flux_value: Heat flux value (default: "1e6[W/m^2]") temperature_value: Temperature value (default: "293.15[K]" = 20°C) convection_coeff: Convection coefficient (default: "10[W/(m^2*K)]") ambient_temp: Ambient temperature for convection (default: "293.15[K]") model_name: Model name (default: current model)
Returns: Configuration confirmation
| Name | Required | Description | Default |
|---|---|---|---|
| physics_name | Yes | ||
| heat_flux_boundaries | No | ||
| temperature_boundaries | No | ||
| convection_boundaries | No | ||
| heat_flux_value | No | 1e6[W/m^2] | |
| temperature_value | No | 293.15[K] | |
| convection_coeff | No | 10[W/(m^2*K)] | |
| ambient_temp | No | 293.15[K] | |
| model_name | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose all behavioral traits, but it only states the basic functionality and parameter defaults. It does not mention side effects (e.g., overwriting previous boundary settings), whether the tool is idempotent, validation behavior, error cases, or what the returned 'Configuration confirmation' entails. For a tool that modifies simulation state, this is a significant gap.
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 moderately concise: a header sentence, a summary paragraph, and an 'Args' section. The information is front-loaded with the purpose. Some redundancy exists between the summary list of boundary types and the parameter list, but overall it is well-structured and efficient for a tool with 9 parameters.
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's complexity (9 parameters, no output schema, no annotations), the description covers parameter meaning adequately but lacks broader context. It does not explain the workflow (e.g., that this tool should be called after adding heat transfer physics and before solving), nor does it describe the return value. This could lead to misuse in a multi-step simulation 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 input schema has 0% description coverage, so the description must compensate. It does so by listing all parameters with explanations (e.g., 'heat_flux_boundaries: List of boundary numbers for heat flux') and providing default values with units. However, it does not elaborate on the format of string parameters beyond the default, leaving some ambiguity for complex values like '1e6[W/m^2]'.
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 that the tool sets up Heat Transfer boundary conditions, listing three types: heat flux, temperature, and convection. This distinguishes it from sibling tools like physics_setup_flow_boundaries (for flow) and physics_add_heat_transfer (which adds the physics interface). The verb 'Setup' combined with the resource 'Heat Transfer boundary conditions' is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives. It does not mention prerequisites (e.g., that a heat transfer physics must already exist) or when not to use it. Sibling tools like physics_configure_boundary exist, but no comparison or exclusion is given. The description assumes the user knows the context, which is insufficient for an AI agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Evaluate an expression on a solution dataset.
Args: expression: Expression(s) to evaluate, e.g., "es.normE" or ["x", "y", "es.normE"] unit: Desired unit for result, e.g., "V/m", "pF" dataset: Dataset name (default: uses default dataset) inner: For time-dependent solutions: index, 'first', 'last', or list of indices outer: For parametric sweeps: index or list of indices model_name: Model name (default: current model)
Returns: Evaluated values as lists, or error message
| Name | Required | Description | Default |
|---|---|---|---|
| expression | Yes | ||
| unit | No | ||
| dataset | No | ||
| inner | No | ||
| outer | No | ||
| model_name | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. However, it does not disclose behavioral traits like side effects, permissions, error handling, or whether it supports multiple evaluations. It only states the basic action.
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 follows a clean Arg/Returns structure and is relatively concise. Every sentence serves a purpose. However, the Returns section could be more specific (e.g., format of lists).
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 output schema and annotations, the description provides a baseline explanation of parameters and return values. It is not fully comprehensive; for instance, it does not clarify how errors are returned or the structure of the output lists.
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's Args section adds meaning by explaining each parameter (e.g., examples for expression, unit, dataset, etc.). However, some parameters like 'inner' and 'outer' lack detailed context beyond what is in the schema titles. The compensation is partial.
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 evaluates an expression on a solution dataset. The verb 'evaluate' and resource 'expression on solution dataset' are specific. It does not explicitly distinguish from siblings like results_global_evaluate, but the mention of 'solution dataset' hints at a 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?
The description provides no guidance on when to use this tool versus alternatives such as results_global_evaluate, results_inner_values, or results_outer_values. There are no exclusions or context cues for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Export data from an export node.
Args: node_name: Export node name (default: run all exports) file_path: Output file path (overrides node setting) model_name: Model name (default: current model)
Returns: Export confirmation with file path
| Name | Required | Description | Default |
|---|---|---|---|
| node_name | No | ||
| file_path | No | ||
| model_name | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description indicates it exports data and returns a confirmation with file path, but it lacks details on side effects such as file overwriting or required permissions. Since no annotations are provided, the description carries the full burden but is minimal.
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 concise, uses a clear Args/Returns structure, and each sentence adds value. However, the Returns section is somewhat redundant given the simple output, but it is acceptable.
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?
The description covers the core functionality and parameters, but it lacks information about prerequisites (e.g., an existing export node), potential errors, or the format of the confirmation. Given the moderate complexity and no output schema, it could be more 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?
The input schema has 0% description coverage, but the description adds meaning to all three parameters by explaining defaults (e.g., node_name defaults to 'run all exports', file_path overrides node setting). This significantly aids parameter 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 clearly states the action 'Export data from an export node', which is a specific verb-resource combination. It distinguishes from siblings like results_export_image and results_evaluate by focusing on export nodes.
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 implies usage for exporting data from export nodes and mentions parameter defaults, but it does not explicitly state when to use this tool versus alternatives or provide any exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Export a plot as an image.
Args: node_name: Plot export node name file_path: Output image path (e.g., "results.png", "field.png") model_name: Model name (default: current model)
Returns: Export confirmation with file path
| Name | Required | Description | Default |
|---|---|---|---|
| node_name | No | ||
| file_path | No | ||
| model_name | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should detail behavioral traits. It only states it exports an image and returns confirmation, lacking info on file overwrite, error handling, or side effects.
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 concise with a front-loaded purpose statement. Every sentence adds value, though it could include more detail without becoming 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 3 parameters, no annotations, and no output schema, the description is incomplete. It doesn't specify return value format, error conditions, or constraints like image format.
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 carries the burden. It adds meaning by naming parameters and providing examples (e.g., file_path: 'results.png'), but lacks details like supported formats or node_name requirements.
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 'Export a plot as an image' with a specific verb and resource. It distinguishes from siblings like results_export_data (exports data) and results_plots_list (lists plots).
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. Does not mention prerequisites like needing a plot node, or suggest alternatives for data export.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all export nodes defined in a model.
Args: model_name: Model name (default: current model)
Returns: List of export node names
| Name | Required | Description | Default |
|---|---|---|---|
| model_name | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only states that it lists export nodes and returns names. It does not disclose whether the operation is read-only, has side effects, or other 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 very concise, consisting of two lines for the action and one for the parameter. It is front-loaded and every sentence adds value.
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 list tool with one optional parameter and no output schema, the description is minimally adequate. It could be improved by mentioning that the model must be loaded or that exports are defined via other results tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, but the description adds the parameter 'model_name' with explanation 'Model name (default: current model)', providing meaningful context that the schema lacks.
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 'List all export nodes defined in a model.' It uses a specific verb (list) and resource (export nodes), and the purpose is distinct from sibling tools like results_export_data or results_plots_list.
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 such as results_plots_list or results_export_data. There is no mention of prerequisites, context, or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Evaluate a global expression (returns a single scalar value).
Common global expressions include:
Integration: "intop1(T)" where intop1 is an integration operator
Maximum: "maxop1(T)"
Derived values: "2*es.intWe/U^2" for capacitance
Args: expression: Global expression to evaluate unit: Desired unit for result dataset: Dataset name model_name: Model name (default: current model)
Returns: Single numerical value
| Name | Required | Description | Default |
|---|---|---|---|
| expression | Yes | ||
| unit | No | ||
| dataset | No | ||
| model_name | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose behavioral traits. It only states basic operation (evaluate and return scalar) without mentioning side effects, permissions, rate limits, or prerequisites like solving the model first.
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 well-structured: purpose, examples, args list, returns. It is concise with no redundant phrases, though the args list could be slightly more compact.
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?
The description covers purpose, examples, and parameter meanings. However, it lacks details on error scenarios, prerequisites (e.g., model solved), or whether the tool is read-only, which are important for complete understanding.
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 provides brief but informative descriptions for each parameter (unit, dataset, model_name with default) beyond the schema, though could offer more detail like unit formats.
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 evaluates a global expression returning a scalar value, with examples. It specifies 'global' to distinguish from similar tools like results_evaluate, though not explicitly contrasting with siblings.
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 implies usage for computing global expressions but does not provide explicit when-to-use or when-not-to-use guidance, nor mentions alternatives like results_evaluate for non-global evaluations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get inner solution indices and values (time steps in time-dependent study).
Args: dataset: Dataset name (default: default dataset) model_name: Model name (default: current model)
Returns: Arrays of indices and corresponding values (e.g., time values)
| Name | Required | Description | Default |
|---|---|---|---|
| dataset | No | ||
| model_name | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states the tool returns arrays but does not disclose any behavioral traits such as mutability, permissions, or side effects. For a read operation, this is a minor gap.
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: two short paragraphs with front-loaded purpose, then Args and Returns. No wasted sentences.
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 no output schema and no annotations, the description adequately explains the tool's purpose, parameters, and return type. It could benefit from a brief example or more detail on the return format, but is largely 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?
The description adds meaning to both parameters (dataset and model_name) by indicating their defaults and roles, which the input schema alone does not provide. Schema coverage is 0%, so the description fully compensates.
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 verb 'Get' and the resource 'inner solution indices and values', with context 'time steps in time-dependent study'. This clearly distinguishes it from sibling tools like results_outer_values and results_global_evaluate.
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 implies usage for time-dependent studies by mentioning 'time steps', but it provides no explicit when-to-use or when-not-to-use guidance, nor does it compare to alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get outer solution indices and values (parameter values in parametric sweep).
Args: dataset: Dataset name (default: default dataset) model_name: Model name (default: current model)
Returns: Arrays of indices and corresponding parameter values
| Name | Required | Description | Default |
|---|---|---|---|
| dataset | No | ||
| model_name | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavioral traits. It only states a read-like operation without mentioning side effects, authorization, or whether it modifies state. The tool could be read-only, but this is not confirmed.
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 concise and front-loaded with the main purpose. The docstring format is clean and includes parameters and returns without unnecessary detail. However, it could be more compact.
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?
The description provides the essential purpose and parameter defaults, but lacks context on what 'outer' means in parametric sweeps, examples, or return format details. For a simple getter with no output schema, it is adequate but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, but the description includes brief parameter explanations ('Dataset name (default: default dataset)' and 'Model name (default: current model)'). This adds some meaning, though it remains minimal.
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 'Get outer solution indices and values (parameter values in parametric sweep).' This provides a specific verb and resource, and the mention of 'outer' distinguishes it from siblings like results_inner_values, though not explicitly.
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. There is no mention of context, prerequisites, or exclusions. Users must infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all plot nodes defined in a model.
Args: model_name: Model name (default: current model)
Returns: List of plot node names
| Name | Required | Description | Default |
|---|---|---|---|
| model_name | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose any behavioral traits such as side effects, error handling, or that it is a read-only operation. The description is too minimal.
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 concise with no wasted words. The Args and Returns section is clearly formatted and provides necessary information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list operation with one optional parameter and no output schema, the description is adequate. It could be improved by noting what happens when model_name is invalid, but it covers the essentials.
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 description adds value to the schema by explaining the default behavior ('default: current model') and the meaning of the optional model_name parameter, which is not present in 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 action (list), the resource (plot nodes), and the scope (in a model). It distinguishes well from sibling tools like results_exports_list and datasets_list.
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 implies usage when you need to retrieve plot nodes, but there is no explicit guidance on when to use this vs alternatives or any preconditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all solutions in a model.
Args: model_name: Model name (default: current model)
Returns: List of solution configurations
| Name | Required | Description | Default |
|---|---|---|---|
| model_name | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description only states basic operation and return type, omitting behavioral traits like read-only nature, required permissions, or side effects.
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?
Short and front-loaded with the core action. The docstring format is efficient, though the 'Args/Returns' boilerplate could be omitted for even tighter prose.
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?
Adequately covers the simple tool (1 parameter, no output schema), but provides no details on the structure of returned solution configurations, limiting agent's ability to use the result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Adds meaningful context for the only parameter: explains 'model_name' defaults to current model when null, which is not evident from schema alone.
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?
Clear verb 'List' and resource 'solutions in a model'. Distinguishes from sibling list tools which target different entities like datasets, docs, geometry, etc.
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., other list tools) or any context about prerequisites or limitations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Cancel the current solving operation.
Note: The solver may take a moment to respond to cancellation.
Returns: Cancellation status
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description must fully disclose behavior. It mentions a delay in cancellation response, but omits side effects like impact on results, state changes, or idempotency.
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?
Extremely concise: two sentences and a return line. Front-loaded with purpose, no waste.
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 simple cancellation tool, but lacks detail on handling when no operation is running or whether it is idempotent. Output schema absent, but return is simple.
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; schema coverage is 100%. Baseline 4 is appropriate as description adds no param info but none is needed.
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 verb 'Cancel' and resource 'current solving operation' are specific and unambiguous. It clearly distinguishes from siblings like study_solve and study_wait.
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 when-to-use or when-not-to-use guidance. It implies use during an active solving operation, but does not mention alternatives or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the progress of the current solving operation.
Returns: Progress information including status, percentage, and elapsed time
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries full burden. It discloses that the tool returns progress info including status, percentage, and elapsed time, which is transparent.
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 concise with 3 sentences, each providing essential information without any 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?
Given no input parameters and a clear return value description, the description is complete for this simple 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?
No parameters are defined, so the description does not need to add param info. Baseline 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it returns progress of the current solving operation, distinguishing it from sibling tools like study_solve, study_cancel, etc.
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?
It implies usage after solving is initiated but provides no explicit guidance on when to use it vs alternatives like study_status or study_wait.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all studies in a model.
Args: model_name: Model name (default: current model)
Returns: List of study names with their types
| Name | Required | Description | Default |
|---|---|---|---|
| model_name | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the default behavior (current model if model_name omitted) and the return format (list of names with types). This is adequate for a simple list operation, though it could mention error handling or model existence.
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 purpose, followed by parameter and return details. It is efficient, though it partly repeats the schema's default value. No wordiness, but could be slightly more streamlined.
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's simplicity (one optional parameter, no output schema), the description covers the key aspects: what it lists, how to specify the model, and what the response contains. It is complete for its complexity level.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage for the parameter. The description adds value by stating 'Model name (default: current model)', which clarifies the parameter's meaning and default behavior beyond the schema's type definition.
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 'List all studies in a model' using a specific verb (list) and resource (studies) in context. This distinguishes it from sibling tools like study_solve or study_cancel, which perform different actions.
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 explicit guidance on when to use this tool versus alternatives like study_solve or study_get_progress. While it is clear what it does, it offers no context for selection or exclusion of sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Solve a study (synchronous by default).
Args: study_name: Study to solve (None for all studies) model_name: Model name (default: current model) wait: If True, wait for completion; if False, return immediately timeout: Maximum wait time in seconds (only used if wait=True)
Returns: Solution status, or error message
| Name | Required | Description | Default |
|---|---|---|---|
| study_name | No | ||
| model_name | No | ||
| wait | No | ||
| timeout | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the behavior is partially disclosed: it solves a study, can wait or return immediately, and returns a solution status or error. However, it does not detail side effects, resource locking, or whether the study is modified.
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 uses a compact docstring format with Args and Returns sections. Every sentence is necessary and no word is wasted.
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?
The tool is simple with four optional parameters and no output schema. The description covers inputs and return value adequately, but does not specify the format of the solution status or potential error conditions.
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?
Since schema description coverage is 0%, the description fully explains each parameter: study_name (None for all studies), model_name (default current), wait (blocking toggle), timeout (only when wait=True). This adds essential meaning 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 solves a study synchronously by default. 'Solve a study' is a specific verb-resource pair, and 'synchronous by default' distinguishes it from the sibling study_solve_async.
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 explains the wait parameter, indicating that by default the tool waits for completion but can return immediately. This gives context for synchronous vs asynchronous usage, but does not explicitly name alternatives like study_solve_async or study_wait.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Start solving a study in the background (asynchronous).
Use study_get_progress to monitor progress and study_cancel to stop.
Args: study_name: Study to solve (None for all studies) model_name: Model name (default: current model)
Returns: Confirmation that solving started, or error message
| Name | Required | Description | Default |
|---|---|---|---|
| study_name | No | ||
| model_name | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It explains the async nature and that it returns a confirmation or error, but does not detail potential side effects, permissions, or state changes. Still, it covers the key behavioral traits adequately.
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 concise: three sentences plus an Args section. It front-loads the core purpose and immediately provides usage guidance. No unnecessary words, well-organized.
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 simplicity (2 optional parameters, no output schema), the description is complete. It explains the async workflow and references sibling tools (study_get_progress, study_cancel) to complete the lifecycle. No gaps remain.
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%, but the description includes an Args section that explains both parameters: study_name (study to solve, None for all) and model_name (default current model). This adds meaningful context, though model_name could elaborate on valid values or format.
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 'Start solving' and the resource 'study', and specifies the asynchronous mode. It distinguishes from sibling 'study_solve' by explicitly mentioning 'asynchronous', and references related tools for monitoring and cancellation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides immediate next steps: use study_get_progress for monitoring and study_cancel to stop. However, it does not explicitly state when to use this async version versus the synchronous study_solve, which would be helpful for decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Wait for the current solving operation to complete.
Args: timeout: Maximum time to wait in seconds (None for indefinite)
Returns: Final progress status
| Name | Required | Description | Default |
|---|---|---|---|
| timeout | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses blocking behavior and optional timeout, but lacks details on side effects, timeout expiry behavior, or safety when no operation is in progress.
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 one sentence plus args/returns, front-loaded and concise. However, a more structured format (e.g., bullet points) could improve readability.
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 parameter and no output schema, the description covers purpose and parameter. Missing info on return format, error behavior, and blocking duration limits, but is mostly adequate.
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%, but the description explains the only parameter timeout: 'Maximum time to wait in seconds (None for indefinite).' This adds meaningful context beyond the schema's type/null/default.
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 'Wait for the current solving operation to complete.' It uses a specific verb (wait) and resource (current solving operation), and distinguishes from related tools like study_solve_async and study_get_progress.
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 implies usage after starting an async solve, but does not explicitly state when to use versus alternatives like study_get_progress or how to handle multiple calls. No when-not guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get troubleshooting suggestions for common issues.
Common error types:
"geometry_build_failed": Geometry sequence failed to build
"mesh_failed": Mesh generation failed
"solver_no_convergence": Solver did not converge
"memory_error": Out of memory
"license_error": COMSOL license issues
Args: error_type: Type of error encountered context: Additional context about the error
Returns: Troubleshooting suggestions
| Name | Required | Description | Default |
|---|---|---|---|
| error_type | Yes | ||
| context | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description lacks details about side effects, prerequisites, or limitations. It only mentions returning suggestions, but no behavioral context beyond that.
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 well-structured with a list of error types and Args/Returns sections. The first sentence conveys the core purpose. Slightly redundant with schema but overall efficient.
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?
No output schema exists, yet the description only says 'Returns: Troubleshooting suggestions' without specifying format, examples, or how suggestions are provided. Incomplete for a diagnostic 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 schema has 0% description coverage, but the description lists common values for error_type, adding some meaning. However, context remains vague ('Additional context') and no format constraints are given.
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 provides troubleshooting suggestions for common issues, with a list of error types. It is unique among sibling tools, which focus on other COMSOL operations.
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 over alternatives, or when not to use it. Usage is implied only when encountering errors.
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.0comsol_connectcomsol_disconnectcomsol_startcomsol_statusdatasets_listdocs_getdocs_listgeometry_add_blockgeometry_add_circlegeometry_add_cylindergeometry_add_featuregeometry_add_rectanglegeometry_add_spheregeometry_boolean_differencegeometry_boolean_uniongeometry_buildgeometry_creategeometry_get_boundariesgeometry_importgeometry_listgeometry_list_featuresmesh_createmesh_infomesh_listmodel_clonemodel_createmodel_create_componentmodel_inspectmodel_listmodel_list_componentsmodel_loadmodel_removemodel_savemodel_save_versionmodel_set_currentmodeling_best_practicesmultiphysics_addparam_descriptionparam_getparam_listparam_setparam_sweep_setuppdf_list_modulespdf_searchpdf_search_statusphysics_addphysics_add_electrostaticsphysics_add_heat_transferphysics_add_laminar_flowphysics_add_solid_mechanicsphysics_boundary_selectionphysics_configure_boundaryphysics_get_availablephysics_get_guidephysics_interactive_setup_flowphysics_interactive_setup_heatphysics_listphysics_list_featuresphysics_removephysics_set_materialphysics_setup_flow_boundariesphysics_setup_heat_boundariesresults_evaluateresults_export_dataresults_export_imageresults_exports_listresults_global_evaluateresults_inner_valuesresults_outer_valuesresults_plots_listsolutions_liststudy_cancelstudy_get_progressstudy_liststudy_solvestudy_solve_asyncstudy_waittroubleshootTools are well-grouped by prefixes (model_, geometry_, physics_, etc.) with distinct actions, but some overlap exists between generic and specific physics adders (physics_add vs physics_add_electrostatics) and between boundary condition setup tools (physics_boundary_selection vs physics_configure_boundary). These overlaps are partially mitigated by detailed descriptions.
All tools follow a consistent verb_noun pattern using snake_case (e.g., model_create, geometry_add_block, physics_add_heat_transfer). No mixed conventions or unpredictable deviations are observed.
With 78 tools, the count is far beyond the typical well-scoped range of 3-15. While COMSOL is a complex domain, this many tools may overwhelm an agent and increase selection difficulty. A more streamlined set focusing on core operations would be preferable.
The tool set covers the full simulation lifecycle: model creation/manipulation, geometry construction (including boolean operations and import), physics setup (multiple interfaces, boundary conditions, materials), meshing, solving (including async and progress tracking), and results evaluation/export. Minor gaps include lack of independent material definition tools beyond physics assignment.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
MCP server for building and testing AI agents with multi-model experimentation and insights.
MCP server for AI dialogue using various LLM models via AceDataCloud
MCP Server for an Agent Task Marketplace
MCP server unifying ERPs, CRMs, APIs and knowledge base for Claude, ChatGPT and Gemini.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/Zhangyoupeng1996/Codex_MCP_Comsol'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
