Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@CST Studio Orchestrator MCP Create a 50 ohm microstrip patch antenna at 2.4 GHz"
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.
An open-source Model Context Protocol (MCP) server that turns CST Studio Suite into a unified AI-controllable simulation environment.
This project exposes CST Studio Suite to AI agents and automation clients. It supports 3D electromagnetic modeling, antenna and RF workflows, solver setup, result extraction, PCB/SI helpers, and direct CST Design Studio schematic control for field-circuit co-simulation through project.schematic.
177 MCP tools for CST automation across modeling, antennas, materials, ports, mesh, solvers, simulation, results, PCB/SI, optimization, VBA, and schematic workflows.
Connected mode on Windows with CST Python libraries for live control of CST Studio Suite.
Offline mode for generating CST VBA scripts when CST is not available.
Design Studio schematic tools for RLC components, external ports, net connections, schematic inspection, object discovery, and generic RemoteObject calls.
Generic schematic bridge for CST's runtime project.schematic interface, including objects such as Block, Net, ExternalPort, CircuitProbe, SchematicLayout, SimulationTask, ParameterSweep, and Optimizer.
Built-in CST VBA reference data and guardrails for raw VBA execution.
Related MCP server: COMSOL MCP Server
Most CST automation examples focus on 3D Microwave Studio history commands. CST Design Studio and schematic workflows are less visible because schematic actions do not reliably appear in the 3D History List.
This fork adds a practical bridge for Design Studio:
project.schematic.Block
project.schematic.Net
project.schematic.ExternalPort
project.schematic.SchematicLayoutOn CST Studio Suite 2025.2, the generic schematic tools can enumerate 125 project.schematic members and call methods on runtime remote objects directly.
Specialized tools:
cst_schematic_create_rlc creates a resistor, inductor, or capacitor.
cst_schematic_create_external_port creates a schematic external port.
cst_schematic_connect connects block or port pins into a named net.
cst_schematic_list lists schematic blocks and nets.
Generic bridge tools:
cst_schematic_list_objects lists public members exposed by project.schematic.
cst_schematic_object_methods lists methods on one schematic object.
cst_schematic_call calls project.schematic.<object_name>.<method_name>(*args, **kwargs).
Example generic call:
{
"object_name": "Block",
"method_name": "GetNumberOfPorts",
"args": []
}git clone https://github.com/guardianer9-debug/cst-studio-orchestrator-mcp.git
cd cst-studio-orchestrator-mcp
pip install -e ".[dev]"{
"mcpServers": {
"cst-studio-orchestrator": {
"command": "cst-studio-orchestrator-mcp",
"env": {
"CST_PATH": "D:\\CST2025",
"CST_WORK_DIR": "D:\\cst_projects",
"PYTHONPATH": "D:\\CST2025\\AMD64\\python_cst_libraries"
}
}
}
}The legacy command names mcp-cst-studio and cst-field-circuit-mcp are also kept for compatibility.
Connected mode requires:
Windows
CST Studio Suite installed
CST Python libraries available on PYTHONPATH
Python 3.10+
Example:
$env:PYTHONPATH="D:\CST2025\AMD64\python_cst_libraries;$env:PYTHONPATH"
python -c "import cst.interface; print('CST available')"
cst-studio-orchestrator-mcpWhen CST is unavailable, most modeling tools return VBA scripts that can be run manually in CST Studio Suite. The generic schematic reflection tools require connected mode because they depend on CST runtime remote objects.
pip install -e ".[dev]"
pytest -q
ruff check src testsCurrent local validation:
535 passed
ruff: All checks passedThis project is derived from RFingAdam/mcp-cst-studio and keeps the original AGPL-3.0-or-later license. This fork adds CST Design Studio schematic automation and a generic project.schematic RemoteObject bridge for broader CST Studio Suite orchestration, including antennas, RF/EM workflows, PCB/SI, and field-circuit co-simulation.
See NOTICE for attribution details.
AGPL-3.0-or-later. CST Studio Suite itself is a separate commercial product from Dassault Systemes/SIMULIA and is not bundled or redistributed by this project.
Add a discrete (lumped) port between two points. Used for circuit-level excitation with a defined impedance.
| Name | Required | Description | Default |
|---|---|---|---|
| x1 | Yes | X coordinate of the start point (mm) | |
| x2 | Yes | X coordinate of the end point (mm) | |
| y1 | Yes | Y coordinate of the start point (mm) | |
| y2 | Yes | Y coordinate of the end point (mm) | |
| z1 | Yes | Z coordinate of the start point (mm) | |
| z2 | Yes | Z coordinate of the end point (mm) | |
| impedance | No | Port impedance in ohms (default 50) | |
| port_type | No | Excitation type (default SParameter) | SParameter |
| port_number | Yes | Port number (1-999) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full burden of behavioral transparency. It only states the basic action and purpose, omitting critical traits such as whether it overwrites existing ports, required prerequisites (e.g., open project, geometry existence), side effects, or return values. This is insufficient for safe invocation.
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, front-loaded with the primary action and followed by usage context. It is concise and to the point, but could benefit from a slight expansion to include behavioral details without significant bloat.
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 9 parameters and no output schema, the description lacks essential context such as prerequisites (e.g., project must be open, points must be on a surface), the effect on the simulation model, error conditions, or that port numbers must be unique. The tool's complexity demands more complete information.
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 100% coverage with descriptions for all 9 parameters. The description does not add any extra meaning beyond the schema, so a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool adds a discrete (lumped) port between two points for circuit-level excitation with defined impedance. It effectively distinguishes from waveguide, Floquet, and other port types by specifying 'lumped' and 'circuit-level', providing high clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions the tool is 'Used for circuit-level excitation with a defined impedance,' giving context for when to use it. However, it does not explicitly state when not to use it or provide alternatives compared to sibling tools like cst_add_waveguide_port, reducing guidance somewhat.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add a field monitor at a specific frequency to the CST project. Field monitors must be defined before running a simulation to capture field distributions, far-field patterns, surface currents, or power flow at the desired frequency.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | Custom name for the monitor. If omitted, a name is auto-generated from the type and frequency, e.g. 'e-field (f=2.45)'. | |
| frequency | Yes | Monitor frequency in GHz. | |
| monitor_type | Yes | Type of field monitor to add. Options: Efield (electric field), Hfield (magnetic field), Powerflow (Poynting vector), Current (volume current), Powerloss (loss density), Farfield (radiation pattern), Surfacecurrent (surface current density). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It explains what field monitors capture (field distributions, far-field patterns, etc.) but does not disclose side effects like project tree modifications or any requirements like needing an open project.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no unnecessary information. Front-loaded with the core purpose, maximizing information density.
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 a simple 3-parameter tool, the description adequately covers purpose and usage context. It could mention what happens after addition (e.g., monitor appears in tree) but is sufficiently complete for agent 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 schema covers 100% of parameters with descriptions. The tool description adds minimal extra semantics (e.g., 'at a specific frequency' is already clear from schema). Baseline 3 is appropriate as the description does not significantly enhance 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 'Add' and the resource 'field monitor', specifying it is at a specific frequency. It distinguishes itself from sibling tools which deal with ports, antennas, 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 provides explicit context that monitors must be defined before running a simulation, implying when to use this tool. It does not, however, mention when not to use it or suggest alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add a fixed mesh point at specific coordinates for precise field sampling. Ensures the mesh contains a node exactly at the specified location for accurate field probing.
| Name | Required | Description | Default |
|---|---|---|---|
| x | Yes | X coordinate in mm | |
| y | Yes | Y coordinate in mm | |
| z | Yes | Z coordinate in mm | |
| name | No | Optional name for the fixed mesh point |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description only mentions adding a fixed point but lacks details on side effects, permissions, what happens if coordinates already exist, or return values.
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 succinct sentences with no wasted words; purpose and benefit are front-loaded.
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 creation tool, but lacks details on constraints (e.g., coordinate bounds, mesh requirements) and does not specify return behavior, which might be relevant.
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 100%; description adds no new meaning beyond 'at specific coordinates' and coordinate units (mm) which are already in schema. The 'name' parameter's description is 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?
Description clearly states the tool adds a fixed mesh point at coordinates, and distinguishes it from siblings like cst_add_mesh_refinement by specifying it ensures a node exactly at a location for precise field sampling.
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 precise field sampling and accurate field probing, but does not explicitly state when to use versus alternatives like mesh refinement, nor when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add a Floquet port for periodic structures such as frequency selective surfaces, metamaterials, and phased arrays.
| Name | Required | Description | Default |
|---|---|---|---|
| modes | No | Number of Floquet modes to include (default 2) | |
| orientation | Yes | Orientation of the Floquet port (zmin or zmax) | |
| port_number | Yes | Port number (1-999) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Only states 'Add a Floquet port' without disclosing side effects, prerequisites (e.g., periodic boundary needed), constraints (port number uniqueness), or return values. Minimal 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?
Single sentence, front-loaded with purpose. No wasted words, but could include more useful details without losing 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?
No output schema exists, yet description does not hint at return value or success indicators. Lacks prerequisites, post-conditions, and behavioral traits. Incomplete for a tool with 3 parameters and no annotations.
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 100% and already describes each parameter. Description adds no extra meaning beyond schema (e.g., does not explain the physical significance of 'modes' or 'orientation'). Baseline 3 is appropriate as description does not reduce ambiguity.
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 explicitly states 'Add a Floquet port' and lists example applications (FSS, metamaterials, phased arrays). This clearly distinguishes it from other port types like discrete, waveguide, or multipin ports, and from the advanced Floquet port settings tool (cst_set_floquet_port_advanced).
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 via 'for periodic structures...' but no explicit when-to-use or when-not-to-use. Does not mention alternatives or compare with sibling port tools. Guidance is present but not comprehensive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add a lumped R, L, C, or RLC element between two points. Value is in ohms for R, henries for L, farads for C.
| Name | Required | Description | Default |
|---|---|---|---|
| x1 | Yes | X coordinate of the first terminal (mm) | |
| x2 | Yes | X coordinate of the second terminal (mm) | |
| y1 | Yes | Y coordinate of the first terminal (mm) | |
| y2 | Yes | Y coordinate of the second terminal (mm) | |
| z1 | Yes | Z coordinate of the first terminal (mm) | |
| z2 | Yes | Z coordinate of the second terminal (mm) | |
| name | Yes | Unique name for the lumped element | |
| value | Yes | Element value (ohms for R, henries for L, farads for C) | |
| element_type | Yes | Type of lumped element |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description bears the full burden of disclosing behavioral traits. It does not mention any side effects (e.g., modifying the project, creating an object in the 3D model), requirements (e.g., an open project), or limitations. The description is minimal and lacks 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 two sentences, succinct and to the point, with no redundant information. Every word serves a 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 the absence of an output schema, the description does not explain what the tool returns (e.g., an object reference, success message). The behavioral context is lacking, especially for a creation tool that modifies the project state.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage, so the description adds limited value beyond schema descriptions. It clarifies the units for value (ohms, henries, farads), which is already present in the schema, but does not add new semantic meaning for other parameters.
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 ('Add') and the resource ('lumped R, L, C, or RLC element'), and specifies the connection between two points. However, it does not differentiate from the similar sibling tool 'cst_schematic_create_rlc', which may cause confusion about which tool to use.
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 'cst_schematic_create_rlc' or other creation tools. There are no prerequisites, context, or exclusions mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add local mesh refinement to a specific solid. This creates finer mesh around critical geometry features like feed points, gaps, or thin layers.
| Name | Required | Description | Default |
|---|---|---|---|
| solid | Yes | Solid name to refine mesh around | |
| component | Yes | Component name containing the solid | |
| refinement_factor | No | Refinement factor — mesh cells are divided by this value (default 2.0) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It mentions creating finer mesh but lacks details on prerequisites, destructive behavior, or interaction with other mesh settings.
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 action and no fluff. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Moderate complexity with sibling mesh tools, but description does not explain interaction with other mesh settings or output. No output schema, but description suffices for basic use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for all parameters. The description adds context ('around critical geometry features') but does not significantly enhance understanding 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?
Description clearly states the tool adds local mesh refinement to a specific solid, with examples of when it's used (feed points, gaps, thin layers). This distinguishes it from sibling tools like global mesh settings.
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 context for when to use (around critical geometry features) but does not explicitly state when not to use or mention alternatives among sibling mesh tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add a waveguide port with multiple mode monitoring for higher-order mode analysis. Used for multimode waveguides, mode converters, and structures where higher-order propagating modes need to be captured.
| Name | Required | Description | Default |
|---|---|---|---|
| x_max | Yes | X-axis maximum coordinate of the port aperture (mm) | |
| x_min | Yes | X-axis minimum coordinate of the port aperture (mm) | |
| y_max | Yes | Y-axis maximum coordinate of the port aperture (mm) | |
| y_min | Yes | Y-axis minimum coordinate of the port aperture (mm) | |
| z_max | Yes | Z-axis maximum coordinate of the port aperture (mm) | |
| z_min | Yes | Z-axis minimum coordinate of the port aperture (mm) | |
| num_modes | No | Number of modes to monitor (1-10, default 1) | |
| orientation | Yes | Face of the bounding box where the port is placed | |
| port_number | Yes | Port number (1-999) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions the multimode monitoring feature but does not disclose side effects (e.g., modifies project tree), prerequisites (e.g., an open project), or any behavioral traits beyond the action itself.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, directly to the point, with no extraneous information. Key purpose and usage are front-loaded.
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 9 parameters, no output schema, and no annotations, the description explains purpose and use case but omits details about what happens after creation (e.g., port added to simulation), return value, or integration with solver. 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?
Schema description coverage is 100%, so baseline is 3. The description does not add parameter-level detail beyond the schema; it only provides high-level context about multimodal monitoring.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Add') and resource ('waveguide port with multiple mode monitoring'), and distinguishes from the sibling 'cst_add_waveguide_port' by explicitly mentioning multimode capability.
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 specifies typical use cases ('multimode waveguides, mode converters, and structures where higher-order propagating modes need to be captured'), providing clear context but lacking explicit when-not-to-use or alternative tool references.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add a plane wave excitation source. Defines an incident plane wave with given direction and polarization for scattering / RCS analysis.
| Name | Required | Description | Default |
|---|---|---|---|
| phi | Yes | Azimuth angle of incidence in degrees (0-360) | |
| e_phi | No | Phi component of the polarization vector (default 0) | |
| theta | Yes | Elevation angle of incidence in degrees (0-180) | |
| e_theta | No | Theta component of the polarization vector (default 1) | |
| polarization | Yes | Polarization type |
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 only states the basic action without detailing side effects, prerequisites (e.g., a project must exist), or whether it modifies existing sources. The description lacks behavioral 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 two sentences covering purpose and context. It is front-loaded and efficient, though some additional structural details (e.g., parameter grouping) could be added without bloat.
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 has no output schema and is a setup action. The description covers the basic purpose but lacks workflow context (e.g., how it interacts with other sources, solver requirements). Adequate but has 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?
Schema coverage is 100% with all parameters having descriptions. The overall description adds little beyond summarizing the schema, but it does not introduce new meaning. Baseline 3 is appropriate for high 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 it adds a plane wave excitation source for scattering/RCS analysis, which distinguishes it from other port/ excitation tools among siblings. The verb 'add' and resource 'plane wave' are specific. However, it could be slightly more explicit about distinguishing from other plane wave setups.
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 scattering/RCS analysis but does not provide explicit guidance on when to use this tool versus alternatives (e.g., discrete ports, waveguide ports). No when-not or alternative mentions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add a waveguide port for S-parameter excitation. Defines a port face on the boundary of the simulation domain for guided-wave excitation. IMPORTANT: The port plane should be at or near the edge of the model geometry. Ground planes and substrates must NOT extend past the port plane in the port's orientation direction, or VBA execution may hang. For microstrip feeds: place the port at the end of the feed line where the ground/substrate terminates. Use Coordinates='Free' for ports not aligned to the bounding box. Valid orientations: xmin/xmax/ymin/ymax/zmin/zmax.
| Name | Required | Description | Default |
|---|---|---|---|
| x_max | Yes | X-axis maximum coordinate of the port aperture (mm) | |
| x_min | Yes | X-axis minimum coordinate of the port aperture (mm) | |
| y_max | Yes | Y-axis maximum coordinate of the port aperture (mm) | |
| y_min | Yes | Y-axis minimum coordinate of the port aperture (mm) | |
| z_max | Yes | Z-axis maximum coordinate of the port aperture (mm) | |
| z_min | Yes | Z-axis minimum coordinate of the port aperture (mm) | |
| coordinates | No | Coordinate mode. 'Free' allows arbitrary placement using the specified ranges (required for microstrip/coplanar ports). 'Full' maps the port to the full bounding-box face. 'Picks' uses previously picked geometry faces. Default: 'Free'. | Free |
| mode_number | No | Number of modes to consider (default 1) | |
| orientation | Yes | Face of the bounding box where the port is placed | |
| port_number | Yes | Port number (1-999) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses a critical behavioral trait: VBA execution may hang if geometry rules (ground/substrate extension) are violated. It also specifies valid orientations and coordinate modes. However, it does not mention side effects like port overwriting or limits.
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 purpose sentence, followed by important usage notes (IMPORTANT), specific feed advice, and parameter details. While concise, each sentence adds value. Slightly longer but justified by complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 10 parameters (8 required) and no output schema, the description covers the tool's purpose, key geometry constraints, coordinate modes, and orientation meanings. It does not specify return values (e.g., success confirmation), but this is acceptable without output schema. It adequately differentiates from sibling port 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?
Schema coverage is 100%, baseline 3. The description adds meaning beyond schema by explaining why 'Coordinates=Free' is essential for microstrip/coplanar ports and that orientation maps to bounding-box faces. It also relates parameters to geometry constraints, providing context not 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 tool adds a waveguide port for S-parameter excitation, defining a port face. It distinguishes from sibling tools like discrete, lumped, and Floquet ports by specifying 'waveguide port' and detailing geometry considerations. The verb 'Add' and resource 'waveguide port' 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 provides explicit usage guidance: port plane at/near model edge, ground/substrate termination constraints, microstrip feed placement, and use of 'Coordinates=F ree' for non-aligned ports. It does not explicitly compare to alternative port types (e.g., discrete ports), but the context from sibling tools and the specific name imply when to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Analyze antenna impedance match quality across frequency bands using S-parameter data. Exports S11 from a completed simulation, computes VSWR and return loss per frequency point, detects resonances, and provides resonance-based design recommendations (e.g. shift resonance up/down, widen bandwidth). Returns per-band worst/best VSWR, match quality classification, nearest resonance info, and actionable design guidance. Read-only — does not modify the model.
| Name | Required | Description | Default |
|---|---|---|---|
| z0 | No | Reference impedance in ohms (default: 50). | |
| port | No | Port number (default: 1). | |
| bands | Yes | Frequency bands to analyze impedance for. | |
| sample_frequencies_ghz | No | Specific frequencies (GHz) to report detailed impedance. If omitted, band edges and center are used. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for behavioral disclosure. It explicitly states the tool is read-only and does not modify the model. It details the analysis steps (export S11, compute VSWR, detect resonances) and lists return values. Minor omission: does not clarify what happens if no simulation data exists or if S-parameters are unavailable.
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 four sentences that efficiently convey the tool's purpose, actions, and outputs. It front-loads the main purpose and follows with specific computations and return values. No redundant or irrelevant 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?
The tool has no output schema, so the description compensates by listing key return items (worst/best VSWR, match quality, resonance info, design guidance). It mentions the prerequisite of a completed simulation. However, it does not describe the exact output structure, error conditions, or behavior with missing data. Minor gaps but sufficient for typical use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all four parameters. The description does not add new semantic information beyond the schema; it only provides overall context. For example, sample_frequencies_ghz is described in the schema as 'Specific frequencies to report detailed impedance' and the description does not elaborate further.
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 analyzes antenna impedance match quality across frequency bands using S-parameter data. It lists specific computations (S11, VSWR, return loss, resonances) and outputs (per-band VSWR, match quality, resonance info, design recommendations). This distinguishes it from related sibling tools like cst_get_impedance or cst_get_vswr which only return raw 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 after a completed simulation and states it is read-only. However, it does not explicitly differentiate this tool from alternatives like cst_get_impedance or cst_matching_* tools. There is no guidance on when not to use it or prerequisites beyond 'from a completed simulation'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a planar bowtie antenna. Generates two triangular arms with a discrete port at the feed gap.
| Name | Required | Description | Default |
|---|---|---|---|
| flare_angle | No | Flare half-angle of each arm in degrees (default 60) | |
| arm_length_mm | No | Arm length in mm (auto-calculated from frequency if omitted) | |
| frequency_ghz | Yes | Design center frequency in GHz |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist. The description discloses the creation action but omits side effects (e.g., whether it modifies existing geometry or requires subsequent simulation setup). It does not contradict any annotations since none are provided.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core action. Every word is necessary and contributes to understanding. No superfluous content.
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 geometry-creation tool with three parameters and no output schema, the description covers the basic purpose but lacks information about what happens to the model state or return values. It is minimally complete but could mention that the discrete port is automatically created.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%. The tool description adds context about the port and arms, but the parameter descriptions in the schema already explain flare angle, arm length, and frequency adequately. The description does not introduce new semantic value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates a planar bowtie antenna with two triangular arms and a discrete port. Among sibling antenna creation tools, it is distinguished by specifying 'planar bowtie' and the geometry details.
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 dipole, patch, or horn antennas. No prerequisites or contextual hints provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a half-wave dipole antenna at a target frequency. Generates two wire arms with a discrete port at the feed gap.
| Name | Required | Description | Default |
|---|---|---|---|
| frequency_ghz | Yes | Design center frequency in GHz | |
| wire_radius_mm | No | Wire radius in mm (default 0.5) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It explains the basic creation but omits any side effects, prerequisites, or impact on existing geometry. It is minimally 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?
Two concise sentences, no redundancy. Essential information is front-loaded. Every word serves a 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?
For a creation tool with no output schema, the description is adequate. It could briefly mention the outcome (e.g., antenna object added to project), but the current content is sufficient given the sibling 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 100%, so the description adds no extra meaning beyond what the schema already provides. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (Create), the specific resource (half-wave dipole antenna), and key details (two wire arms, discrete port). It distinguishes among sibling antenna 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?
The description implies usage when a dipole antenna is needed but provides no guidance on when to avoid this tool or which alternative to use in different scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create an axial-mode helical antenna for circular polarization. Generates helix coil, ground plane, and feed.
| Name | Required | Description | Default |
|---|---|---|---|
| num_turns | No | Number of helix turns (default 10) | |
| ground_type | No | Ground plane shape (default circular) | circular |
| frequency_ghz | Yes | Design center frequency in GHz |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions creating components but does not indicate whether it modifies existing geometry, requires an open project, automatically adds ports, or has any destructive side effects. Key behavioral context is 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?
Two concise sentences that are front-loaded with the purpose. No unnecessary words or repetition.
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 creation tool without an output schema, the description lacks important context: coordinate system, units, effect on existing geometry, port creation, or return value. Given the tool's complexity, more detail is needed for a 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?
All three parameters (num_turns, ground_type, frequency_ghz) are described in the schema (100% coverage). The description adds overall context but does not enhance understanding beyond the schema's own descriptions, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it creates an axial-mode helical antenna for circular polarization and lists the generated components (helix coil, ground plane, feed). This distinguishes it from other antenna types like cst_antenna_dipole or cst_antenna_spiral.
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 circular polarization but does not explicitly state when to use a helix over alternatives like spiral antennas. No guidance on when not to use or which tool to choose instead is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a pyramidal horn antenna for a target frequency and gain. Generates the waveguide section, flared horn, and waveguide port.
| Name | Required | Description | Default |
|---|---|---|---|
| a | No | Waveguide broad-wall dimension in mm (auto-calculated if omitted) | |
| b | No | Waveguide narrow-wall dimension in mm (auto-calculated if omitted) | |
| gain_dbi | No | Target gain in dBi (default 15) | |
| frequency_ghz | Yes | Design center frequency in GHz |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It states what is created but does not disclose side effects, prerequisites (e.g., open project), or whether it overwrites existing objects. Some behavioral context is 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 a single concise sentence that covers key aspects. It could be better structured with front-loaded information, but it is not verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of antenna creation, the description is brief. It lacks information on return values, prerequisites, and error conditions. For a tool with many siblings, more context would help.
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 100% with each parameter described. The description adds 'target frequency and gain' which maps to frequency_ghz and gain_dbi, but does not elaborate on a and b beyond what the schema already states. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as creating a pyramidal horn antenna for a target frequency and gain, listing the generated components (waveguide section, flared horn, waveguide port). This distinguishes it from other antenna types in the sibling 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 use when a pyramidal horn antenna is needed, but it does not provide explicit when-to-use or when-not-to-use guidance, nor does it mention alternatives among sibling antenna tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create an Inverted-F antenna (IFA) suitable for mobile devices. Generates ground plane, radiating arm, shorting pin, and feed.
| Name | Required | Description | Default |
|---|---|---|---|
| frequency_ghz | Yes | Design center frequency in GHz | |
| ground_width_mm | No | Ground plane width in mm (default 40) | |
| ground_length_mm | No | Ground plane length in mm (default 100) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description lists generated geometry components, but lacks details about port creation, excitation, material assignments, or side effects. Without annotations, the burden is higher; the description is adequate but not exhaustive.
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 fluff: first states purpose and context, second clarifies generated components. Efficient and well-structured.
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 creation tool with three parameters and no output schema or annotations, the description covers the essential behavior. It names generated components, which is sufficient for basic usage. Could mention relationship to simulation setup, but 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?
Schema coverage is 100%, so description adds limited value. It mentions generated components but does not elaborate on parameter usage beyond schema defaults. Baseline of 3 is appropriate as description is not essential for 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 tool creates an Inverted-F antenna (IFA) for mobile devices, listing generated components. It uses a specific verb and resource, distinguishing it from many sibling antenna tools like dipole, patch, 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 IFA vs other antenna types. No prerequisites, context, or exclusions provided. Among many sibling tools, an agent would lack decision criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a quarter-wave monopole antenna over a ground plane. Generates a vertical wire element, ground plane, and feed port.
| Name | Required | Description | Default |
|---|---|---|---|
| frequency_ghz | Yes | Design center frequency in GHz | |
| wire_radius_mm | No | Wire radius in mm (default 0.5) | |
| ground_radius_mm | No | Ground plane radius in mm (auto-calculated if omitted) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explains what is generated (wire, ground plane, feed port) but does not disclose side effects, such as whether it modifies an existing project or requires a project to be open. With no annotations, more detail on behavior would be helpful.
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 that convey the essential purpose and components. No filler words or 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?
For a creation tool with no output schema, the description adequately covers what the tool does. However, it could mention that it adds objects to the current project or specify return values, but overall it's 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?
Schema has 100% coverage, so parameters are already documented. The description mentions frequency, wire radius, and ground radius but adds no new information beyond the schema. It does not explain the auto-calculation for ground radius, which is implied.
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 creates a quarter-wave monopole antenna over a ground plane, specifying the vertical wire element, ground plane, and feed port. This differentiates it from other antenna tools like cst_antenna_dipole or cst_antenna_patch.
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 other antenna templates. No prerequisites or context provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a rectangular microstrip patch antenna with calculated dimensions for a target frequency. Supports inset, microstrip, and probe feed types. Generates substrate, ground plane, patch, feed structure, waveguide port, boundaries, and field monitors.
| Name | Required | Description | Default |
|---|---|---|---|
| tan_d | No | Substrate loss tangent (default 0.02) | |
| epsilon_r | No | Substrate relative permittivity (default 4.4 — FR-4) | |
| feed_type | No | Feed method (default inset) | inset |
| frequency_ghz | Yes | Design center frequency in GHz | |
| ground_size_factor | No | Ground plane size = factor * patch size (default 2.0) | |
| substrate_height_mm | No | Substrate thickness in mm (default 1.6) |
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 lists generated components (substrate, ground plane, patch, feed structure, waveguide port, boundaries, field monitors), providing good context about what the tool creates. However, it does not mention potential destructive actions or permissions needed.
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 consists of two concise sentences, front-loading the main purpose and including a clear list of generated elements. No superfluous information is present.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema and annotations, the description adequately covers what the tool does and generates. It mentions all key aspects: frequency-based dimension calculation, feed types, and generated components. However, it could detail how the tool interacts with the CST environment (e.g., creating a new model or modifying an existing one).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the parameter descriptions are already complete. The tool description adds minimal additional meaning beyond noting that patch dimensions are calculated and listing feed types. It does not enhance understanding beyond what the schema provides, resulting in a baseline score.
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 creates a rectangular microstrip patch antenna with calculated dimensions for a target frequency. It specifies supported feed types and lists what components are generated, distinguishing it from other antenna tools like cst_antenna_dipole or cst_antenna_horn.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions supported feed types but does not provide explicit guidance on when to use this tool versus alternatives or when not to use it. Sibling tools indicate many antenna types, but the description implies usage for rectangular patch antennas without detailing selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a Planar Inverted-F Antenna (PIFA) for compact wireless devices. Generates ground plane, top patch, shorting wall, and feed.
| Name | Required | Description | Default |
|---|---|---|---|
| frequency_ghz | Yes | Design center frequency in GHz | |
| patch_width_mm | No | Patch width in mm (auto-calculated if omitted) | |
| ground_width_mm | No | Ground plane width in mm (default 40) | |
| ground_length_mm | No | Ground plane length in mm (default 100) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must disclose behavior. It states it creates and generates components, but lacks details on side effects, permissions required, or whether it modifies existing geometry. For a creation 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?
Two efficient sentences, front-loaded with purpose and a clear list of generated components. 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?
No output schema, but description does not mention return value or post-creation state. Also no mention of prerequisites like open project. Incomplete for a tool with 4 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 coverage is 100%, so baseline is 3. Description does not add extra context about parameters beyond the schema's 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?
Clearly states it creates a PIFA antenna, specifying the type and its components (ground plane, patch, shorting wall, feed). Distinguishes from sibling antenna tools like dipole or patch.
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 use for compact wireless devices, but no explicit when to use vs alternatives. With many sibling antenna templates, more guidance would help.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a slot antenna in a ground plane. Generates the ground plane with a resonant slot and microstrip feed.
| Name | Required | Description | Default |
|---|---|---|---|
| frequency_ghz | Yes | Design center frequency in GHz | |
| slot_width_mm | No | Slot width in mm (auto-calculated if omitted) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes the creation action but does not disclose potential side effects (e.g., if it modifies existing geometry, requires certain coordinate systems, or whether it can be called multiple times). No annotations provided, so the description carries full burden.
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, efficient and free of extraneous 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?
Lacks mention of return value or success indication. For a creation tool with no output schema, description should briefly state what the tool returns (e.g., object handle). Otherwise 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 100%, so description adds limited value. However, it mentions 'auto-calculated if omitted' for slot_width_mm, which supplements the schema 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 creating a slot antenna in a ground plane, with generation of ground plane, slot, and microstrip feed. It uses specific verbs and resource names, distinguishing it from other antenna types like bowtie or dipole.
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., when a slot antenna is preferred over a patch antenna). No prerequisites or context provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a wideband Archimedean spiral antenna. Generates two spiral arms with a discrete port feed at the center.
| Name | Required | Description | Default |
|---|---|---|---|
| num_turns | No | Number of spiral turns (default 5) | |
| freq_low_ghz | Yes | Low end of operating band in GHz | |
| freq_high_ghz | Yes | High end of operating band in GHz |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only states creation without disclosing side effects (e.g., whether it modifies existing geometry, requires a project, or what happens to unsaved changes). This lacks important 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?
Two concise sentences with no unnecessary words. The information is front-loaded and every part is relevant.
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?
Output schema is missing, so expected return is unclear. The description does not mention project context or post-creation state. However, for a simple antenna creation tool, it covers the essential purpose. Could benefit from noting the dependence on an existing project.
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?
All three parameters have descriptions in the schema (100% coverage). The tool description adds no extra detail beyond the schema; 'wideband' and 'discrete port feed' are general but not parameter-specific. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create a wideband Archimedean spiral antenna') and specifies key characteristics (two arms, discrete port feed at center). It distinguishes from other antenna templates in the sibling 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 choose this tool over others (e.g., dipole, patch). The description implies usage for wideband spiral antennas, but does not compare with alternatives or mention prerequisites like an active CST project.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a Vivaldi (tapered slot) antenna on a dielectric substrate. Generates substrate, exponential taper metallisation, and feed.
| Name | Required | Description | Default |
|---|---|---|---|
| epsilon_r | No | Substrate relative permittivity (default 2.2 — Rogers) | |
| frequency_ghz | Yes | Design center frequency in GHz | |
| substrate_height_mm | No | Substrate thickness in mm (default 1.6) | |
| taper_length_factor | No | Taper length in wavelengths (default 3) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the tool generates substrate, taper, and feed, but does not specify side effects, required project state, or whether existing objects are overwritten. With no annotations, this is minimal but not misleading.
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 consists of two concise sentences with no redundant information. It efficiently communicates the tool's purpose and key outputs.
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 creates a complex antenna structure with four parameters and no output schema, the description lacks details such as whether a port is automatically added, default material units, or return value behavior. It covers the basics but is not fully self-contained.
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 100%, so the schema already documents each parameter's meaning. The description adds context about exponential taper and feed but does not enhance parameter understanding beyond the schema, justifying the baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it creates a Vivaldi antenna, specifying the key components (substrate, taper, feed). Among many sibling antenna tools, it uniquely identifies the antenna type, so the agent can distinguish it.
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 other antenna tools (e.g., when to choose Vivaldi over patch or dipole). No prerequisites or context for selection 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 Yagi-Uda antenna with a reflector, driven element, and configurable number of directors. Generates wire elements and a discrete port feed.
| Name | Required | Description | Default |
|---|---|---|---|
| frequency_ghz | Yes | Design center frequency in GHz | |
| num_directors | No | Number of director elements (default 3) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden for behavioral disclosure. It notes that the tool 'generates wire elements and a discrete port feed,' but fails to mention prerequisites (e.g., an open project), side effects, or any constraints. The behavioral information 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 extremely concise—only two sentences. The first sentence front-loads the main purpose, and the second adds essential detail. Every word earns its place with no redundancy or 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?
For a simple creation tool with two parameters and no output schema, the description is nearly complete. It explains what the tool creates and its key elements. However, it omits any mention of return value or effect on the CST project (e.g., 'creates the antenna in the active project'), which would be helpful but is 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?
Schema coverage is 100%, so the baseline is 3. The description adds the phrase 'configurable number of directors' which mirrors the num_directors parameter, but does not provide additional meaning beyond what the schema already states (e.g., frequency_ghz is described as 'Design center frequency in GHz'). No deeper semantics are added.
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 function: 'Create a Yagi-Uda antenna with a reflector, driven element, and configurable number of directors.' It uses a specific verb and resource, and the detail about wire elements and discrete port feed distinguishes it from sibling antenna creation tools like dipole or patch.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like other antenna types. The description does not include any 'when-to-use' or 'when-not-to-use' context, leaving the agent to rely solely on the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Calculate progressive phase weights to steer the main beam to a specified angle. Returns phase weights and VBA to set port phases in CST.
| Name | Required | Description | Default |
|---|---|---|---|
| spacing_mm | Yes | Inter-element spacing in mm | |
| num_elements | Yes | Number of elements | |
| scan_phi_deg | No | Desired scan angle phi in degrees (default 0) | |
| frequency_ghz | Yes | Operating frequency in GHz | |
| scan_theta_deg | Yes | Desired scan angle theta in degrees from broadside |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description indicates the tool returns phase weights and VBA, suggesting no destructive side effects, but does not explicitly state if it modifies the CST project. Without annotations, this is adequate 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?
Single sentence with two clear clauses, front-loading the main action and output. 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 calculation tool, the description explains the purpose and output sufficiently. However, it lacks details like whether the VBA is returned as a string or applied directly, and no output schema is provided.
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 100% with clear parameter descriptions. The description adds minimal value by mentioning output, but no additional parameter 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 the tool calculates progressive phase weights for beam steering to a specified angle, with explicit output of phase weights and VBA. This distinguishes it from sibling tools like array creation or analysis.
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 array tools). The description implies it is for setting phase weights after array creation but does not state prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a circular antenna array by placing elements at equal angular intervals around a circle of given radius.
| Name | Required | Description | Default |
|---|---|---|---|
| radius_mm | Yes | Array circle radius in mm | |
| num_elements | Yes | Number of elements (2-64) | |
| frequency_ghz | Yes | Design frequency in GHz (for wavelength reference) | |
| element_component | No | Component name of the element to replicate (default Antenna) | Antenna |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided. The description is minimal and does not disclose behavioral traits such as whether the tool modifies existing geometry, requires an open project, or has any side effects. It only states what it does, not how it behaves 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 a single, clear, front-loaded sentence. It contains no filler words and directly conveys the essential action. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with 4 parameters and no output schema. The description adequately explains the array creation, but it could specify that the operation takes place in the current CST project and that the result is a new array object. It is minimally sufficient but not fully 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 coverage is 100%, with each parameter having a description. The tool description adds some context (e.g., 'replicate' for element_component, 'wavelength reference' for frequency_ghz), but it does not significantly enhance understanding beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates a circular antenna array, specifying the method 'by placing elements at equal angular intervals around a circle of given radius'. This uniquely identifies its purpose and distinguishes it from sibling tools like cst_array_linear and cst_array_planar.
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. It lacks prerequisites, constraints, or notes on when it's appropriate. Usage is implied by the tool name and description, but no comparative or contextual advice is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compute the array factor analytically for a linear or planar array. Returns AF(theta) in dB, half-power beamwidth, first null beamwidth, peak sidelobe level, and directivity.
| Name | Required | Description | Default |
|---|---|---|---|
| array_type | No | Array type (default linear) | linear |
| num_elements | Yes | Number of elements | |
| scan_angle_deg | No | Scan angle in degrees from broadside (default 0) | |
| amplitude_weights | No | Amplitude weights per element (default uniform) | |
| spacing_wavelengths | Yes | Inter-element spacing in wavelengths (d/lambda) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description bears full burden. It transparently states returns (AF, beamwidths, SLL, directivity) but omits behavioral details like assumptions (isotropic elements, no coupling) and computational limits. Adequate but lacking full disclosure.
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: first states purpose, second lists outputs. Extremely concise with no filler. Information is front-loaded and each sentence is purposeful. Exceptional structure.
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 compensates by listing all return values. However, it lacks detail on output format (e.g., how AF(theta) is returned, units of beamwidths) and does not address edge cases. Still fairly complete for a simple analytic 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 coverage is 100%, so baseline is 3. Description adds context by mentioning linear/planar arrays (mapping to array_type) and returns, but does not deepen understanding of parameters beyond schema. No contradiction.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific verb 'Compute' and resource 'array factor' for linear or planar arrays. It lists returns (AF in dB, beamwidths, SLL, directivity), clearly distinguishing from siblings like cst_array_linear (creates array) and cst_array_beam_steering (steers beam).
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 use for analytic computation ('analytically') but does not explicitly state when to prefer this over alternatives like full-wave simulation or other array analysis tools (e.g., cst_array_mutual_coupling). Missing guidance on limitations (e.g., assumes isotropic elements).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Analyse whether grating lobes exist for a given element spacing and maximum scan angle. Returns safe spacing and grating lobe angles.
| Name | Required | Description | Default |
|---|---|---|---|
| max_scan_angle_deg | No | Maximum scan angle from broadside in degrees (default 60) | |
| spacing_wavelengths | Yes | Inter-element spacing in wavelengths (d/lambda) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description states it 'analyzes' and 'returns' results, implying a read-only operation without side effects. However, it does not explicitly confirm non-destructive behavior or disclose any computational constraints.
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, efficiently communicating the tool's function, inputs, and outputs without any extraneous information. Front-loaded with the core 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?
For a tool with two parameters and no output schema, the description provides sufficient context to understand the basic operation. However, it lacks details on the return format or assumptions, and could be more complete given no annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers both parameters with descriptions (100% coverage). The tool description adds no extra meaning beyond the schema, so baseline score of 3 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 identifies the tool's purpose: analyzing grating lobes given element spacing and scan angle. It distinguishes from sibling tools by specifying a unique function not covered by other array tools like beam steering or array factor calculation.
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. The description implies use for grating lobe analysis but lacks prerequisites, alternatives, or context where it should not be used.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a linear antenna array by replicating an element along a chosen axis. Uses Transform.Translate to produce copies named Element_1 through Element_N.
| Name | Required | Description | Default |
|---|---|---|---|
| axis | No | Array axis (default x) | x |
| spacing_mm | Yes | Inter-element spacing in mm | |
| num_elements | Yes | Number of elements (2-64) | |
| frequency_ghz | Yes | Design frequency in GHz (for wavelength reference) | |
| element_component | No | Component name of the element to replicate (default Antenna) | Antenna |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the method (Transform.Translate) and naming convention, but does not reveal important behaviors: whether it modifies the original element, creates a new assembly, or requires pre-existing elements. Without annotations, more detail is needed for full 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 sentences, front-loaded with purpose. No wasted words. Efficiently conveys the core action and a key implementation detail.
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 creation action but lacks context about prerequisites (e.g., element component must exist), output, and side effects. No output schema, but given complexity, more behavioral context is expected for 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 100%, so the baseline is 3. The description adds minimal extra meaning beyond the schema; it mentions 'along a chosen axis' and naming convention, but does not elaborate on parameter formats or dependencies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates a linear antenna array by replicating an element along an axis, which distinguishes it from circular or planar array tools. However, it does not explicitly contrast with sibling tools like cst_array_circular or cst_array_planar.
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 cst_array_circular or cst_array_planar. No prerequisites are mentioned (e.g., existence of an element component). The description only states what it does, not when to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Set up a multi-port S-parameter simulation in CST for mutual coupling extraction between array elements.
| Name | Required | Description | Default |
|---|---|---|---|
| num_ports | Yes | Total number of ports in the array | |
| port_numbers | No | Explicit port numbers to include (default 1..num_ports) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It indicates a setup action, which is non-destructive, but does not mention side effects (e.g., whether it modifies existing ports or runs simulation). This is adequate 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?
Single sentence that is front-loaded with the core action and purpose. No wasted words; efficient and clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple two-parameter schema with good descriptions and no output schema, the description covers the tool's setup purpose well. However, it could mention that it does not run the simulation itself, but this is a minor gap.
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 100% with both parameters described. The description adds minimal extra meaning beyond the schema (e.g., 'multi-port' aligns with num_ports). Baseline 3 applies; no significant enrichment.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Set up a multi-port S-parameter simulation'), the object ('in CST'), and the specific purpose ('for mutual coupling extraction between array elements'). It distinguishes itself from sibling tools like cst_array_beam_steering or cst_array_compute_factor.
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 given on when to use this tool versus alternatives. There are many array-related siblings (e.g., cst_array_beam_steering, cst_array_compute_factor), but the description does not provide any context for choosing this tool over them.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a 2D planar antenna array with rectangular or triangular lattice. Replicates an element in X and Y using Transform.Translate.
| Name | Required | Description | Default |
|---|---|---|---|
| num_x | Yes | Number of elements along X | |
| num_y | Yes | Number of elements along Y | |
| lattice | No | Lattice type (default rectangular) | rectangular |
| spacing_x_mm | Yes | Inter-element spacing along X in mm | |
| spacing_y_mm | Yes | Inter-element spacing along Y in mm | |
| frequency_ghz | Yes | Design frequency in GHz (for wavelength reference) | |
| element_component | No | Component name of the element to replicate (default Antenna) | Antenna |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the tool replicates elements using Transform.Translate, which is a key behavioral trait. However, it does not elaborate on side effects (e.g., whether existing components are modified) or required permissions. Since no annotations are provided, the description partially fulfills the transparency burden.
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 two sentences, front-loading the key purpose and method. No unnecessary words or 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?
For a tool with 7 parameters and no output schema, the description explains the core concept (2D planar array, lattice types, replication via transform). It could be more explicit about the resulting model structure (e.g., a component group), but it is mostly complete given the context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters. The description adds no extra meaning beyond implying that num_x/num_y control replication and lattice selects type. This meets the baseline but does not enhance 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 it creates a 2D planar antenna array with rectangular or triangular lattice and mentions using Transform.Translate. It distinguishes itself from linear or circular array siblings, but does not explicitly contrast with those alternatives.
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 other array creation tools like cst_array_linear or cst_array_circular. It does not mention prerequisites such as the existence of an element component or how to prepare the model.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Design amplitude taper weights for sidelobe control. Supports uniform, cosine, Hamming, Hanning, Blackman, Taylor, and Chebyshev window functions.
| Name | Required | Description | Default |
|---|---|---|---|
| taper_type | Yes | Window/taper type | |
| num_elements | Yes | Number of elements | |
| sidelobe_level_db | No | Desired peak sidelobe level in dB (negative, default -25). Used for Taylor and Chebyshev only. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description only states purpose. Does not disclose behavioral traits such as side effects (e.g., modifying project state), return values, permissions, or integration steps. Significant gap for a design 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?
Two sentences, no fluff, efficiently communicates purpose and supported options. Front-loaded with verb and resource.
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 clear purpose, the description lacks details on output (no output schema), how the tool integrates into a workflow (e.g., does it modify the project or return weights?), and dependencies. Incomplete for practical agent 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 100% with clear parameter descriptions. Description reiterates supported taper types, which are already in the enum, and notes that sidelobe_level_db is for Taylor/Chebyshev (also in schema). Adds minimal extra meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Explicitly states 'Design amplitude taper weights for sidelobe control', which is a specific verb-resource pair. Lists supported window types, distinguishing it from sibling array tools like beam steering or factor computation.
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 designing tapers, but no explicit when-to-use or when-not-to-use guidance compared to siblings like cst_array_beam_steering. The list of supported types helps choose a taper, but lacks exclusionary context.
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 an existing solid in CST Studio. The solid is specified as 'Component:SolidName'.
| Name | Required | Description | Default |
|---|---|---|---|
| solid | Yes | Solid reference as 'Component:SolidName' (e.g. 'Antenna:Patch') | |
| material | Yes | Material name to assign |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It only states the basic action without mentioning side effects, error conditions (e.g., non-existent solid), or whether the operation is reversible. This is insufficient for an agent to anticipate the tool's 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 a single, concise sentence that is front-loaded with the primary action. It contains no unnecessary words, but could be slightly expanded for clarity without harming 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?
The tool has low complexity (2 required parameters) and no output schema. The description covers the basic operation but lacks details on what happens if the material does not exist, if the solid is invalid, or any confirmation of success. It is 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?
Both parameters have descriptions in the schema (100% coverage). The description does not add significant new meaning beyond the schema; it reiterates the solid format. The baseline is 3 since schema coverage is high and no additional semantics are provided.
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 (assign) and the resource (material to an existing solid in CST Studio). It also specifies the format for the solid reference as 'Component:SolidName', which distinguishes this tool from related tools like cst_create_material or cst_delete_material.
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 have an existing solid and want to assign a material. However, it does not explicitly state when to use this tool versus alternatives (e.g., creating a new material, modifying material properties), nor does it provide conditions for use or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Unite/add two solids together. The result replaces solid1 with the combined volume of both shapes.
| Name | Required | Description | Default |
|---|---|---|---|
| solid1 | Yes | First solid (result kept here) in "Component:Solid" format | |
| solid2 | Yes | Second solid (merged into first) in "Component:Solid" format |
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 states that the result replaces solid1, which is useful, but lacks details on side effects, permissions required, or whether the operation is destructive (e.g., original solids are modified). 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 a single sentence that is direct and concise. It contains no unnecessary words or 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 simplicity of the tool (two parameters, no output schema), the description is minimally adequate. It explains the core function and side effect (replaces solid1), but lacks information on return values, error conditions, or preconditions. For a straightforward operation, this is acceptable 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?
Schema description coverage is 100%, with each parameter described in the schema. The description adds that 'solid1' is replaced, which is already implied by the schema description 'result kept here'. Thus, the description adds marginal extra value. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Unite/add') and the resource ('two solids'), and specifies the result ('replaces solid1'). It distinguishes from sibling boolean tools by using 'add', but could be more precise about the operation being a union.
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 cst_boolean_intersect or cst_boolean_subtract. The description implies it performs a union but does not provide context for selection or exclusion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Insert solid2 into solid1. Solid2 is embedded within solid1, maintaining both material regions at the overlap.
| Name | Required | Description | Default |
|---|---|---|---|
| solid1 | Yes | Host solid in "Component:Solid" format | |
| solid2 | Yes | Solid to insert in "Component:Solid" format |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries full burden. It states 'maintaining both material regions' but does not clarify if the operation is destructive to solid1, whether solid2 remains independently selectable, or what happens to material assignments. The term 'embedded' is ambiguous.
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 sentences convey the essential operation without extraneous information. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is adequate for a simple two-parameter tool with no nested objects or output schema. However, it lacks details about return values, side effects on the scene, or error conditions, which would be helpful for a boolean 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 coverage is 100% with clear parameter descriptions ('Host solid', 'Solid to insert'). The description adds slight nuance ('Insert solid2 into solid1') but does not substantially improve understanding 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 action ('Insert solid2 into solid1') and the result (maintaining both material regions). It distinguishes from sibling boolean operations by implying a non-destructive insertion, though it could explicitly differentiate from cst_boolean_add or cst_boolean_intersect.
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 over alternatives like cst_boolean_add, cst_boolean_intersect, or cst_boolean_subtract. The description lacks usage context, prerequisites, or scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Intersect two solids. Only the overlapping volume is kept, replacing solid1. Solid2 is deleted.
| Name | Required | Description | Default |
|---|---|---|---|
| solid1 | Yes | First solid in "Component:Solid" format | |
| solid2 | Yes | Second solid in "Component:Solid" format |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It explicitly states that solid1 is replaced and solid2 is deleted, which is good transparency for a boolean operation. Minor missing details like irreversibility or return value, but adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with key actions, and contains zero wasted words. Highly 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?
Given no output schema, the description explains the operation's effect on inputs. It might benefit from mentioning return value or logging, but overall complete for a simple boolean 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 coverage is 100%, with each parameter having descriptive format info. The description adds nothing beyond the schema, so baseline 3 is appropriate. No need for extra 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?
The description clearly states the tool intersects two solids, keeps the overlapping volume, and specifies the effects on solid1 and solid2. It distinctly differentiates from sibling boolean operations like add, insert, and subtract.
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 implicitly indicates usage for intersection operations, but no explicit guidance on when to use versus alternatives is provided. However, the sibling names are distinct enough to infer the differences.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Subtract solid2 from solid1. The overlapping volume of solid2 is removed from solid1. Solid2 is deleted.
| Name | Required | Description | Default |
|---|---|---|---|
| solid1 | Yes | Solid to subtract from in "Component:Solid" format | |
| solid2 | Yes | Solid to subtract (removed) in "Component:Solid" format |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that solid2 is deleted as a side effect, which is valuable. However, it does not mention whether solid1 is modified in place or if a new object is created, nor does it discuss error conditions or prerequisites. With no annotations, the burden is on the description, and it partially meets 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: three short sentences, each adding distinct information (operation, effect on solid1, side effect on solid2). No wasted words, and the most critical information is front-loaded.
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 subtract operation with a complete input schema, the description covers the core action and side effect. It could be slightly more explicit about whether the operation modifies solid1 in place, but overall it is sufficient for an agent to use 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?
Schema coverage is 100%, and the parameter descriptions in the schema are clear. The tool description adds no additional semantic information beyond restating the roles (subtract from vs. subtract). Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the operation: subtract solid2 from solid1, and explains the effect. However, it does not explicitly differentiate from sibling boolean operations like add, insert, or intersect, leaving some ambiguity for an agent choosing between them.
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., cst_boolean_add, cst_boolean_intersect). The description only states what it does, not when it is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Close the currently open CST project and release its resources.
| 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 carry the full burden. It mentions 'release its resources' but does not specify side effects: e.g., whether unsaved changes are lost, behavior if no project is open, or if calling multiple times is safe. This lack of detail leaves significant ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that immediately conveys the action. It is front-loaded, but could briefly mention prerequisites or consequences without being verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema or annotations, the description is the sole source. It covers the basic action but misses edge cases (e.g., error handling, state expectations like 'project must be open'). This is adequate but not fully complete for an agent to use robustly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist (schema coverage 100%), so the description does not need to add parameter info. Baseline for 0 params is 4, and the description appropriately omits parameter details.
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 ('Close the currently open CST project') and its effect ('release its resources'). It distinguishes from sibling tools like cst_open_project, cst_create_project, and cst_save_project by specifying the current project and resource release.
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. Usage is implied from the purpose (close when done with project), but no exclusions or context such as 'call after saving' or 'do not call if no project is open'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Advanced eigenmode solver configuration for higher-order modes. Use this for waveguide mode analysis, cavity resonator design, and filter characterization where fine control over mode count, frequency targeting, and solver order is needed.
| Name | Required | Description | Default |
|---|---|---|---|
| accuracy | No | Solver accuracy target (default 1e-6) | |
| num_modes | No | Number of eigenmodes to compute (1-50, default 5) | |
| solver_order | No | Solver order 1-3 for higher accuracy (default 1) | |
| frequency_estimate_ghz | No | Frequency estimate in GHz to target specific modes (optional) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states it is a configuration tool and mentions parameters, but does not disclose any side effects, whether it modifies global state, or if it is destructive. For a 'configure' action, basic behavioral expectations are not communicated.
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: first defines the tool, second provides application context. No filler or redundancy. 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?
For a configuration tool with 4 parameters, the description covers the key differentiators (advanced, higher-order, fine control). It omits return values but no output schema exists. With sibling tools, the advanced focus is clear. Slightly lacking in behavioral context, but adequate overall.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description mentions 'mode count, frequency targeting, and solver order' which map to parameters, but adds minimal interpretive value beyond the 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 this is for 'Advanced eigenmode solver configuration' and lists specific applications (waveguide, cavity, filter) that require 'fine control over mode count, frequency targeting, and solver order.' While it distinguishes from a basic solver, it does not explicitly name the sibling tool 'cst_configure_eigenmode_solver' for contrast.
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 explicit contexts for use: 'waveguide mode analysis, cavity resonator design, and filter characterization where fine control...needed.' This implies when to prefer this advanced version over a basic solver, but lacks explicit when-not-to-use or alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Configure the eigenmode solver. Computes resonant frequencies and field distributions of cavity structures. Used for filter design, resonator characterization, and Q-factor extraction.
| Name | Required | Description | Default |
|---|---|---|---|
| f_min | No | Lower frequency bound in GHz — modes below this are skipped (default 0) | |
| accuracy | No | Solver accuracy target (default 1e-6) | |
| number_of_modes | No | Number of eigenmodes to compute (default 5) |
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 describes the tool as configuring the solver and computing results, which implies a non-destructive setup action. However, it does not disclose prerequisites, side effects (e.g., overwriting existing settings), or any additional behavioral traits beyond the primary 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?
Two sentences efficiently convey action and purpose. No wasted words, but could benefit from a slightly more structured format (e.g., bullet points or separate sections for parameters and usage). Still, it is concise and front-loaded.
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 configuration tool with 3 parameters and no output schema, the description is minimally adequate. It explains the general purpose but lacks details on return values, prerequisites, or interaction with other tools. Given the simplicity, a score of 3 is appropriate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (all parameters documented in the schema). The description adds no parameter-specific information beyond what the schema already provides. Per guidelines, baseline is 3 when coverage is high and description adds no extra meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool configures the eigenmode solver, computes resonant frequencies and field distributions, and lists specific use cases (filter design, resonator characterization, Q-factor extraction). This distinguishes it from other solver configuration tools like cst_configure_frequency_domain_solver.
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 (filter design, etc.) but does not explicitly state when to use this tool over alternatives or when not to use it. No exclusions or alternative tools are mentioned, which is a gap given the many sibling solver tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Configure the frequency domain solver. Best for narrowband problems, resonant structures, and when field distributions at specific frequencies are needed. Supports interpolated, discrete, and general-purpose sweep types.
| Name | Required | Description | Default |
|---|---|---|---|
| f_max | Yes | Maximum frequency in GHz | |
| f_min | Yes | Minimum frequency in GHz | |
| samples | No | Number of frequency samples (default 1001) | |
| accuracy | No | Solver accuracy / residual target (default 1e-6) | |
| sweep_type | No | Frequency sweep type (default Interpolated) | Interpolated |
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 of behavioral disclosure. It only states 'Configure the frequency domain solver' without explaining side effects (e.g., whether it overwrites previous settings, requires a running project, or affects other solvers). The description adds limited behavioral context beyond what the input schema already conveys.
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 sentences that front-load the core action ('Configure the frequency domain solver') and immediately provide usage context. No redundant or 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?
The description covers the tool's purpose, best use cases, and supported sweep types, which is sufficient for a configuration tool with self-describing parameters. However, it lacks details about the tool's effect (e.g., whether it validates inputs, fails silently, or requires a project to be open). Given the absence of annotations and output schema, a bit 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 description coverage is 100%, and the parameter descriptions in the schema are clear. The tool description does not add additional meaning to parameters beyond stating sweep types, which are already enumerated in the schema. For a tool with full schema coverage, a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose ('Configure the frequency domain solver') and distinguishes from sibling solvers by specifying typical use cases: 'Best for narrowband problems, resonant structures, and when field distributions at specific frequencies are needed.' This directly differentiates it from time domain solver and other solver 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?
The description explicitly provides guidance on when to use the tool ('Best for narrowband problems, resonant structures...') and mentions supported sweep types, giving context for selection. However, it does not explicitly state when not to use it or list alternatives, though the 'best for' phrasing implicitly excludes broadband or transient problems.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Advanced Integral Equation solver configuration for electrically large structures. Provides control over preconditioner, MLFMM acceleration, and low-frequency stabilization for installed antenna performance and large-platform RCS analysis.
| Name | Required | Description | Default |
|---|---|---|---|
| mlfmm | No | Enable Multi-Level Fast Multipole Method for large problems (default true) | |
| accuracy | No | Iterative solver residual target (default 1e-3) | |
| max_iterations | No | Maximum number of solver iterations (default 1000) | |
| preconditioner | No | Preconditioner type (default ILU) | ILU |
| low_frequency_stabilization | No | Enable low-frequency stabilization for broadband problems (default false) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavioral traits. It describes the tool as a configuration interface for solver settings, which suggests it modifies solver parameters rather than performing destructive actions. However, it does not explicitly state that it modifies project state or describe side effects. The description is adequate but lacks explicit behavioral 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—two sentences that cover purpose, target domain, and key features. Every word serves a purpose; no unnecessary repetition. It is front-loaded with the main action and quickly provides differentiating details.
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 rich schema and no output schema, the description effectively explains the tool's role among many solver config tools. It could be improved by explicitly contrasting with the basic integral equation solver or mentioning that it sets advanced options. Overall, it is complete enough for an AI to understand the tool's purpose and scope.
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?
All 5 parameters are fully described in the schema (100% coverage). The description adds value by grouping parameters (preconditioner, MLFMM, low-frequency stabilization) and linking them to the target use case (electrically large structures), enhancing the semantic context beyond schema 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 it is an advanced configuration for the Integral Equation solver, targeting electrically large structures. It mentions specific features (preconditioner, MLFMM, low-frequency stabilization) and use cases (installed antenna, large-platform RCS). However, it does not explicitly differentiate from the sibling tool cst_configure_integral_equation_solver, which likely serves as the basic version.
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 context (electrically large structures, specific applications) but does not offer explicit guidance on when to use this tool versus alternatives. There is no mention of when not to use it or comparison to other solver configurations like cst_configure_frequency_domain_solver. Usage is implied rather than direct.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Configure the integral equation (IE) solver. Best for electrically large, open-boundary problems like antenna placement on vehicles, RCS computation, and EMC/EMI analysis where volume meshing would be impractical.
| Name | Required | Description | Default |
|---|---|---|---|
| accuracy | No | Iterative solver residual target (default 1e-3) | |
| max_iterations | No | Maximum number of solver iterations (default 1000) |
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. It merely states to configure the solver, but does not mention whether this modifies the project state, requires prior setup, or has any side effects. The agent is left uninformed about the tool's impact.
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 sentences that front-load the purpose and then provide usage guidance. Every word serves a purpose 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 configuration tool with two optional parameters and no output schema, the description covers purpose and usage context adequately. It could mention that the tool modifies the current project's solver settings, but overall it is sufficiently complete given the tool's simplicity.
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 100% with explicit descriptions for both parameters (accuracy, max_iterations) including defaults. The tool description adds no additional parameter context beyond the schema, so baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool configures the integral equation (IE) solver and provides specific use cases (antenna placement, RCS, EMC/EMI) that distinguish it from other solver configuration tools among 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 gives clear context on when to use this solver ('electrically large, open-boundary problems where volume meshing would be impractical'), implicitly advising against use for small or enclosed problems. However, it does not explicitly mention alternative solvers.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Configure the solver for planar multilayer structures. Optimised for antenna-on-PCB, frequency selective surfaces (FSS), and radome analysis using the frequency domain solver with multilayer-specific settings.
| Name | Required | Description | Default |
|---|---|---|---|
| f_max | Yes | Maximum frequency in GHz | |
| f_min | Yes | Minimum frequency in GHz | |
| sweep_type | No | Frequency sweep type (default Interpolated) | Interpolated |
| num_samples | No | Number of frequency samples (default 501) |
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 the tool 'configures' settings but does not disclose behavioral traits such as side effects, prerequisites (e.g., open project, existing multilayer structure), or whether the configuration is persistent. This is insufficient for a configuration 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 concise at 25 words and efficiently communicates the core purpose. It is front-loaded with key info. However, a bit more structure (e.g., separated usage context) could improve clarity without adding 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?
Given the tool's complexity (multilayer solver configuration) and no output schema or annotations, the description is incomplete. It does not explain prerequisites, what configuration is applied, or how to verify the setup. For a configuration tool, 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 already provides descriptions for all 4 parameters (100% coverage), including defaults and enumerations. The description adds no additional parameter semantics beyond listing use cases. Baseline 3 is appropriate as schema does the heavy lifting.
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 tool configures the solver for planar multilayer structures, listing specific applications (antenna-on-PCB, FSS, radome) and specifying the frequency domain solver. This clearly differentiates it from sibling tools like cst_configure_frequency_domain_solver, which is more general.
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 planar multilayer structures but does not provide explicit guidance on when to use this tool vs alternatives (e.g., cst_configure_eigenmode_solver, cst_configure_time_domain_solver). No when-not-to-use or exclusions are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Configure the time domain (transient) solver. This is CST's flagship solver for broadband simulations — it excites the structure with a pulse and computes S-parameters, fields, and farfield across the entire frequency range in a single run.
| Name | Required | Description | Default |
|---|---|---|---|
| accuracy | No | Accuracy level in dB — solver stops when energy has decayed to this level (default -40) | |
| max_time_steps | No | Maximum number of time steps; 0 means automatic (default 0) | |
| excitation_type | No | Excitation signal shape (default Gaussian) | Gaussian |
| fixed_impedance | No | Reference impedance in ohms when normalization is enabled (default 50) | |
| stimulation_port | No | Port number used for excitation (default 1) | |
| normalize_to_fixed_impedance | No | Normalize S-parameters to a fixed reference impedance (default true) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries burden. It discloses excitation method and outputs (S-params, fields, farfield) but does not mention prerequisites, potential issues, 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?
Two concise sentences, front-loaded with purpose, no wasteful words. Second sentence adds valuable behavioral context.
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 main outputs. Lacks information on prerequisites (e.g., open project, defined ports) and typical usage flow. Adequate for a configure 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?
All 6 parameters have descriptions in the input schema (100% coverage). The description does not add any additional meaning or usage context beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it configures the time domain solver and distinguishes it from frequency domain by describing broadband pulse excitation and single-run computation of S-parameters, fields, and farfield across the entire frequency range.
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 use for broadband simulations needing S-params/fields/farfield but does not explicitly state when to use over frequency domain or list prerequisites. Context is clear but lacks exclusions or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the current CST Studio connection status, including mode (connected/offline), CST availability, version, and work directory.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description clearly states the return content (mode, availability, version, work directory). Since no annotations are provided, the description carries full burden. It discloses that it is a read-only operation (get status), which is sufficient. Could add that it does not modify any 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?
Single sentence that is front-loaded with the core action ('Get the current CST Studio connection status') and then details what is included. 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 getter with no parameters and no output schema, the description is complete. It explains the purpose and the output fields. Nothing missing.
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 defined, so baseline 4 applies. The description does not need to add parameter information. Schema coverage is 100% (no params).
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?
Describes exactly what the tool does: get CST Studio connection status. Lists specific information included (mode, availability, version, work directory). Clearly distinct from sibling tools which are about modifying or analyzing CST projects.
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. However, as a status checker, it's implicitly used to verify connection before performing other CST operations. Could be improved by stating that it should be called before any CST operations that require an active connection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Single-objective optimization with explicit inequality constraints. Example: minimize S11 subject to gain > 8 dBi and bandwidth > 100 MHz.
| Name | Required | Description | Default |
|---|---|---|---|
| method | No | Trust Region | |
| objective | Yes | ||
| parameters | Yes | ||
| constraints | Yes | ||
| max_evaluations | No |
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 only states it performs optimization with constraints, but does not disclose potential side effects (e.g., modifying project parameters, running simulations) or any destructive behavior. The example is illustrative but not sufficient for 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 one sentence and an example. It is front-loaded and contains no unnecessary words. Every part contributes to understanding the tool's core function.
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 complex tool (5 parameters, nested objects, no output schema), the description is too sparse. It lacks information about expected outcomes, prerequisites, side effects, or return values. The example provides context but does not cover the full scope of 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 description coverage is 0%, meaning the description must compensate. It gives an example that loosely maps to parameters but does not explain the meaning, structure, or usage of parameters such as objective, constraints, or parameters array. The description adds minimal value over 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 performs single-objective optimization with explicit inequality constraints, and provides a specific example (minimize S11 subject to constraints). This effectively distinguishes it from unconstrained (cst_optimizer) and multi-objective (cst_multi_objective_optimizer) 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 constrained single-objective problems via the example, but does not explicitly state when to use this tool versus alternatives like cst_optimizer or cst_multi_objective_optimizer. No when-not or exclusion criteria are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a parametric analytical curve in CST Studio using expressions of parameter t.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Curve name | |
| t_max | Yes | Parameter t maximum value | |
| t_min | Yes | Parameter t minimum value | |
| x_expr | Yes | X expression as function of t (e.g. 'cos(t)') | |
| y_expr | Yes | Y expression as function of t (e.g. 'sin(t)') | |
| z_expr | Yes | Z expression as function of t (e.g. 't') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. The description only states the action; it does not disclose side effects, prerequisites (e.g., open project), or behavior like overwriting or creating a curve object.
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?
A single sentence that is concise and front-loaded. It is efficient for a simple tool, though it lacks structure or sections.
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 6 parameters and no output schema, the description is minimal. It does not explain return behavior, provide examples, or give context about the CST environment. The schema covers parameter meanings but not usage 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 100%, so baseline is 3. Description adds 'using expressions of parameter t' which reinforces schema but does not provide new meaning beyond what the parameter descriptions already state.
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 'Create', the resource 'parametric analytical curve', and the method 'using expressions of parameter t'. It is specific and distinguishes from sibling creation 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 guidance on when to use this tool versus alternatives (e.g., cst_create_face_from_curves). No exclusions or prerequisites mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create an anisotropic material with per-axis permittivity, permeability, and loss tangent values. Used for crystals, metamaterials, and composite substrates.
| Name | Required | Description | Default |
|---|---|---|---|
| mu_x | Yes | Relative permeability along X | |
| mu_y | Yes | Relative permeability along Y | |
| mu_z | Yes | Relative permeability along Z | |
| name | Yes | Material name | |
| tan_d_x | No | Electric loss tangent along X | |
| tan_d_y | No | Electric loss tangent along Y | |
| tan_d_z | No | Electric loss tangent along Z | |
| epsilon_x | Yes | Relative permittivity along X | |
| epsilon_y | Yes | Relative permittivity along Y | |
| epsilon_z | Yes | Relative permittivity along Z |
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 only says 'create' but does not specify if the material is stored in a project, requires an open project, or has any side effects. The burden is not fully met.
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 that are concise and front-loaded: first sentence states the action and parameters, second sentence provides use cases. 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 no output schema and no annotations, the description is fairly complete for a creation tool. It covers what the tool does and the key parameters. However, it lacks context about project dependencies (e.g., whether a project must be open) or return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds a summary of parameter types (permittivity, permeability, loss tangent) but does not provide additional constraints, relationships, or examples beyond what the schema already contains.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates an anisotropic material with per-axis properties, and mentions specific use cases (crystals, metamaterials, composite substrates). This distinguishes it from other material creation tools like isotropic materials (cst_create_material) or special materials.
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 typical applications but does not explicitly state when to use this tool versus alternatives (e.g., isotropic materials, ferrites). No 'when not to use' or exclusion criteria are provided, leaving the agent to infer from the name and parameters.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a rectangular brick (box) in CST Studio.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Solid name (e.g. 'Substrate') | |
| x_max | Yes | X range maximum | |
| x_min | Yes | X range minimum | |
| y_max | Yes | Y range maximum | |
| y_min | Yes | Y range minimum | |
| z_max | Yes | Z range maximum | |
| z_min | Yes | Z range minimum | |
| material | No | Material name | PEC |
| component | Yes | Component name (e.g. 'Antenna') |
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 only states the action without mentioning side effects, permissions, or whether the component must already exist. For a creation tool, this is insufficient 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 a single, clear sentence with no unnecessary words. It is front-loaded and efficient, though slightly under-specified for completeness.
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 absence of an output schema and annotations, the description falls short. It does not mention the active project requirement, material defaults, or that the brick is a solid shape. The completeness is adequate for a trivial tool but could provide 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?
All 9 parameters have descriptions in the input schema (100% coverage), so the description adds no additional meaning beyond the schema. Baseline of 3 is appropriate as the schema already documents the parameters adequately.
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 specifies the action ('Create') and the object ('rectangular brick (box)'), and the tool name includes 'brick', distinguishing it from sibling tools like 'create_cylinder' or 'create_sphere'. It effectively communicates its purpose, though it could add more context about the environment.
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., extrusions, other primitives) or any prerequisites (e.g., active project, existing component). The description lacks contextual clues for appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a Cole-Cole dispersive material. Generalisation of the Debye model with a distribution parameter alpha (0-1) that broadens the relaxation spectrum. Used for biological tissues, soil, and broadband absorbers.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Material name (e.g. 'Muscle Tissue') | |
| alpha | Yes | Distribution parameter (0 = Debye, 1 = max broadening) | |
| epsilon_inf | Yes | High-frequency (optical) permittivity limit | |
| delta_epsilon | Yes | Static permittivity increment (eps_s - eps_inf) | |
| relaxation_time_ps | Yes | Relaxation time in picoseconds |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description explains the physical behavior (broadening of relaxation spectrum via alpha) and model generalization, providing good transparency about what the tool does without mentioning side effects or destructive actions, which is adequate for a creation 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 very concise: three sentences covering purpose, model generalization, and typical use cases. 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 5 required parameters, no output schema, and no annotations, the description adequately explains the tool's purpose and parameter significance. It does not specify return values or side effects, but for a creation tool, the context is largely 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 input schema has 100% coverage with descriptions for each parameter. The description adds physical context (e.g., alpha range 0-1, relaxation time in ps) that enhances understanding beyond the 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?
The description clearly states 'Create a Cole-Cole dispersive material' and explains it's a generalization of the Debye model with alpha parameter. It also lists specific use cases (biological tissues, soil, broadband absorbers), distinguishing it from other material creation tools like Debye or Drude.
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 materials with broadened relaxation spectra and lists example applications, but it does not explicitly state when to use this vs. other dispersive material models (e.g., Debye, Lorentz) or provide any 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.
Create a cone or truncated cone in CST Studio.
| Name | Required | Description | Default |
|---|---|---|---|
| axis | Yes | Cone axis | |
| name | Yes | Solid name | |
| center_x | No | Center X coordinate | |
| center_y | No | Center Y coordinate | |
| center_z | No | Center Z coordinate | |
| material | No | Material name | PEC |
| component | Yes | Component name | |
| range_max | Yes | Axis range maximum | |
| range_min | Yes | Axis range minimum | |
| top_radius | Yes | Top radius (0 for pointed cone) | |
| bottom_radius | Yes | Bottom radius |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden for behavioral disclosure. It fails to mention any constraints, edge cases (e.g., top_radius > bottom_radius), or what happens with invalid inputs, making it severely lacking.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that communicates the core function without extraneous 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 complexity (11 parameters, 7 required) and no output schema, the description is far too brief. It does not explain parameter roles, coordinate system, material handling, or provide any usage context beyond the basic shape.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so each parameter has a clear description. The tool description adds nothing beyond the schema, but the baseline is 3 since the schema already provides adequate documentation.
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 cone or truncated cone in CST Studio,' which clearly identifies the tool's purpose and distinguishes it from sibling shape creation tools like cylinders or bricks.
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., cylinder, extruded polygon). There is no mention of context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a cylinder in CST Studio. Use inner_radius=0 for a solid cylinder.
| Name | Required | Description | Default |
|---|---|---|---|
| axis | Yes | Cylinder axis | |
| name | Yes | Solid name | |
| center_x | No | Center X coordinate | |
| center_y | No | Center Y coordinate | |
| center_z | No | Center Z coordinate | |
| material | No | Material name | PEC |
| component | Yes | Component name | |
| range_max | Yes | Axis range maximum | |
| range_min | Yes | Axis range minimum | |
| inner_radius | No | Inner radius (0 for solid) | |
| outer_radius | Yes | Outer radius |
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 only states 'Create a cylinder' which implies object creation, but does not disclose any behavioral traits such as whether it modifies existing components, requires a specific project state, or has any side effects. The inner_radius tip is minimal. For a tool with no annotations, more transparency is 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?
The description is extremely concise: two short sentences. The first states the purpose, the second adds a crucial usage tip. No fluff or redundancy. Every sentence 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 11 parameters (6 required) and no output schema or annotations, the description is sparse. It does not explain coordinate context, typical component setup, or how parameters interact. However, schema descriptions cover all parameters, so the essential details are present. The description could be more helpful for a complex tool but 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?
With 100% schema description coverage, the baseline is 3. The description adds the tip 'Use inner_radius=0 for a solid cylinder,' which repeats the existing parameter description. It does not add new semantic meaning beyond the schema definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool creates a cylinder in CST Studio, which is a specific verb-resource pair. However, it does not differentiate from sibling creation tools like cst_create_brick or cst_create_cone, relying solely on the name for distinction. A clearer purpose with differentiation would merit a 5.
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 only includes a note about using inner_radius=0 for a solid cylinder, which is a parameter hint rather than usage context. No when/when-not or alternative tools 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 frequency-dependent dielectric material using the Debye relaxation model. Models polar dielectrics where permittivity decreases with frequency: eps(w) = eps_inf + delta_eps/(1 + jw*tau). Used for biological tissues, water, polymers, and soil.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Material name (e.g. 'Wet Soil') | |
| order | No | Debye model order (1 or 2) | |
| tan_d | No | Optional static loss tangent | |
| epsilon_inf | Yes | High-frequency (optical) permittivity limit | |
| delta_epsilon | Yes | Static permittivity increment (eps_s - eps_inf) | |
| relaxation_time_ps | Yes | Relaxation time in picoseconds |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It explains the physical model but omits operational details such as whether the material is added to the project's material library, if it requires an open project, or any side effects. The description is scientifically informative but lacks operational 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 two sentences long, front-loaded with the purpose and model. It includes the formula efficiently without any extraneous information. Every sentence contributes meaning.
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 (6 parameters, no output schema), the description provides the scientific model and typical uses but does not specify the return value or operational context (e.g., does it return a material handle?). It is complete in the domain sense but lacks practical context for an AI agent to anticipate side effects or prerequisites.
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 100% with descriptions for all parameters. The description adds significant value by providing the Debye model equation, which clarifies the physical meaning of epsilon_inf, delta_epsilon, and relaxation_time_ps. This goes beyond the schema's basic descriptions, aiding 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?
Description specifies the verb 'Create', the resource 'frequency-dependent dielectric material', and the model 'Debye relaxation model'. The inclusion of the mathematical formula and application examples (biological tissues, water, polymers, soil) clearly distinguishes this tool from sibling material creation tools like Cole-Cole or Drude.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions typical applications (biological tissues, water, polymers, soil) but does not explicitly state when to use this tool versus alternatives like cst_create_cole_cole_material or cst_create_drude_material. It lacks exclusions or comparative guidance, which is needed given the number of sibling material creation tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a Drude metal model material for plasmonic and metamaterial simulations. Models free-electron metals: eps(w) = 1 - wp^2 / (w^2 + jgammaw). Used for gold, silver, aluminium in optical/THz frequency ranges.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Material name (e.g. 'Drude Gold') | |
| plasma_freq_ghz | Yes | Plasma frequency in GHz | |
| collision_freq_ghz | Yes | Collision (damping) frequency in GHz |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility for behavioral disclosure. It only states that it creates a Drude material; it does not mention side effects (e.g., whether it overwrites existing materials, permissions required, or how the material is stored). The formula is informative but insufficient for agent understanding of the operation's impacts.
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 two sentences: purpose followed by formula. It is front-loaded with the core action and resource. Every sentence adds meaningful information without redundancy or unnecessary detail.
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 adequately explains the creation purpose and model. However, it does not cover post-creation behavior (e.g., return value, whether the material can be assigned) or prerequisites. For a simple creation tool, this is minimally viable but 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 schema covers all three parameters with clear descriptions. The description adds value by providing the Drude model formula, which connects the parameters (plasma_freq_ghz, collision_freq_ghz) to their physical roles (wp, gamma). This context goes beyond the schema's basic naming, earning a score above baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates a Drude metal model material for plasmonic and metamaterial simulations. It specifies the verb 'Create' and the resource 'Drude metal model material'. The formula and typical usage (gold, silver, aluminium) distinguish it from other material creation tools like Debye or Lorentz models, which have different mathematical forms.
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 free-electron metals in optical/THz ranges by providing the Drude model formula and examples. However, it does not explicitly state when not to use this tool or name alternative tools (e.g., cst_create_debye_material) for different material behaviors. The guidance is adequate but indirect.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create an elliptical cylinder in CST Studio.
| Name | Required | Description | Default |
|---|---|---|---|
| axis | Yes | Cylinder axis | |
| name | Yes | Solid name | |
| center_x | No | Center X coordinate | |
| center_y | No | Center Y coordinate | |
| center_z | No | Center Z coordinate | |
| material | No | Material name | PEC |
| x_radius | Yes | Radius in local X direction | |
| y_radius | Yes | Radius in local Y direction | |
| component | Yes | Component name | |
| range_max | Yes | Axis range maximum | |
| range_min | Yes | Axis range minimum |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description lacks behavioral details beyond creation. It does not mention whether the tool requires an open project, creates a solid, or any side effects. With no annotations, the description should provide more 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 very concise with one sentence, no redundant information, and gets straight to the point.
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 11 parameters and no output schema or annotations, the description is too minimal. It does not explain how the elliptical cylinder is defined or the role of key parameters like x_radius and y_radius.
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 100% with clear parameter descriptions. The tool description adds no additional meaning beyond the schema, remaining at the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Create' and resource 'elliptical cylinder', distinguishing it from the sibling tool cst_create_cylinder which creates circular cylinders. However, it does not explicitly call out this differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus other shape creation tools (e.g., cst_create_cylinder, cst_create_brick). Context signals such as prerequisites or typical workflow steps are absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Extrude a 2D polygon profile into a 3D solid in CST Studio.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Solid name | |
| height | Yes | Extrusion height | |
| points | Yes | List of [x, y] coordinate pairs forming the profile polygon | |
| material | No | Material name | PEC |
| component | Yes | Component name |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, and the description does not disclose behavioral aspects such as whether the operation is destructive, requires existing geometry, or what side effects occur. 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 is a single, direct sentence with no superfluous words. It is front-loaded and 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?
Despite having 5 parameters and no output schema, the description lacks critical context such as extrusion direction, axis, or any special behaviors. It is insufficient for a complete understanding of 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?
The input schema covers 100% of parameters with descriptions, so the tool description does not need to add much. However, it adds no extra meaning beyond the schema (e.g., extrusion direction, polygon closure requirements), warranting a baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Extrude' and the resource '2D polygon profile into a 3D solid', and specifies the domain 'in CST Studio'. It effectively distinguishes from sibling creation tools like cst_create_brick or cst_create_cylinder.
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 vs alternatives, nor any prerequisites or conditions. The description lacks context for appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a planar face from one or more closed curves in CST Studio.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Face/solid name | |
| component | Yes | Component name | |
| curve_names | Yes | List of curve names to form the face boundary |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavior. It only says 'create a planar face' without explaining prerequisites (curves must exist and be closed), outcome, or side effects on the 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 extremely concise (one sentence) but lacks important details for a geometry creation tool. It earns points for front-loading but loses for being under-specified.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 3 required parameters and no output schema or annotations, the description fails to explain prerequisites, the resulting face's properties, or how it integrates into the model workflow.
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 100%, so baseline is 3. The description adds no extra semantic meaning beyond the parameter names and descriptions already 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 tool creates a planar face from closed curves, using a specific verb and resource. It distinguishes from sibling geometry creation tools like cst_create_brick or cst_create_cylinder.
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 cst_create_brick or cst_create_extrude. Lacks when-not and alternative suggestions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a ferrite material with gyrotropic permeability tensor (Polder model). Essential for circulators, isolators, and phase shifters. The Polder tensor describes the anisotropic magnetic response of a magnetised ferrite (Pozar Ch. 9.1).
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Material name (e.g. 'YIG Ferrite') | |
| epsilon_r | Yes | Relative permittivity of the ferrite | |
| linewidth_oe | Yes | Ferromagnetic resonance linewidth in Oersted | |
| field_direction | No | Direction of the applied bias field | z |
| applied_field_ka_m | No | Applied DC bias magnetic field in kA/m | |
| saturation_magnetization_ka_m | Yes | Saturation magnetisation in kA/m (4piMs) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explains the physical model used (Polder tensor) but does not disclose side effects or operational behaviors such as requiring an open project, whether it overwrites existing materials, or any destructive actions. With no annotations, the description carries full burden and provides moderate 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 with three sentences. Each sentence serves a purpose: stating the action and model, listing typical applications, and providing a reference. No unnecessary words or 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 has 6 parameters, no output schema, and no annotations, the description adequately explains what the tool does and the underlying physics. It provides sufficient context for selection. However, it could mention prerequisites (e.g., project must exist) or post-creation steps, but overall it is relatively complete for a material creation 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 coverage is 100% with good parameter descriptions. The description adds value by providing the physical context of the parameters (gyrotropic permeability, Polder model), helping the agent understand the significance of parameters like saturation magnetization and linewidth beyond their syntax.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates a ferrite material with a specific gyrotropic permeability tensor (Polder model). It distinguishes from other material creation tools by naming the physical model and providing context with typical applications and a reference.
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 for ferrite materials requiring anisotropic magnetic response and mentions applications (circulators, isolators, phase shifters). However, it does not explicitly state when to use this tool over alternatives like other material creation tools, nor does it provide conditions or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a lofted solid between two or more 2D profiles in CST Studio.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Solid name | |
| material | No | Material name | PEC |
| profiles | Yes | List of profiles, each a list of [x, y] coordinate pairs | |
| component | Yes | Component name |
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 basic operation without mentioning side effects (e.g., whether it overwrites existing solids), prerequisites (e.g., profiles must be planar), or constraints. This is insufficient for a creation 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 a single, concise sentence that efficiently conveys the core purpose. It is front-loaded and contains no fluff. However, it could be slightly improved by incorporating key parameter hints without losing 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 complexity of the operation (lofting between multiple 2D profiles) and the lack of output schema and annotations, the description is incomplete. It does not explain profile requirements (closed?, 2D?), behavior on invalid input, or return value. More details are needed for confident 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 100% with descriptions for all 4 parameters, so the baseline is 3. The tool description adds no additional meaning beyond the schema, neither clarifying parameter relationships nor providing example values or formatting details.
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 lofted solid between two or more 2D profiles', specifying the verb (create), resource (lofted solid), and distinguishing details (between two or more 2D profiles). This differentiates it from sibling tools like cst_create_extrude (single profile along path) or cst_create_brick (box).
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 lofted solid is needed, but does not provide explicit guidance on when to use it over alternatives like extrusion or other solid creation tools. No when-not or alternative recommendations are given, which is a gap given the many sibling create tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a Lorentz oscillator dispersive material. Models resonant dielectric behaviour near absorption bands: eps(w) = eps_inf + delta_eps * w0^2 / (w0^2 - w^2 + jgammaw). Used for glass, crystals, and optical materials.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Material name (e.g. 'Optical Glass') | |
| epsilon_inf | Yes | High-frequency permittivity limit | |
| delta_epsilon | Yes | Oscillator strength (permittivity increment) | |
| damping_freq_ghz | Yes | Damping (collision) frequency in GHz | |
| resonant_freq_ghz | Yes | Resonant frequency in GHz |
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 describes the mathematical model but does not disclose behavioral aspects such as whether it modifies existing materials, requires permissions, or has 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 two sentences, includes the formula, and is front-loaded with the primary purpose. Minor improvement could be simplifying the formula presentation.
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 sibling material creation tools, the description does not provide enough guidance on when to use Lorentz vs. other models. It mentions use cases but lacks comparative context for an AI agent to decide.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already covers all parameters with descriptions (100% coverage), but the description adds value by providing the equation that contextualizes the parameters (e.g., resonant frequency, damping).
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 function: 'Create a Lorentz oscillator dispersive material' and provides the mathematical formula, distinguishing it from sibling material creation tools like Debye or Drude 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 mentions use cases ('glass, crystals, and optical materials') but does not explicitly compare to alternatives or state when not to use it, leaving the agent to infer appropriate contexts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a lossy metal material in CST Studio. Lossy metals model finite conductivity skin-effect losses, essential for accurate loss calculations in connectors, waveguides, and PCB traces.
| Name | Required | Description | Default |
|---|---|---|---|
| mu | No | Relative permeability (mu_r) | |
| name | Yes | Material name (e.g. 'Lossy Copper') | |
| conductivity | Yes | Electric conductivity in S/m (e.g. 5.8e7 for copper) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must convey behavioral traits. It explains the physics ('finite conductivity skin-effect losses') but does not disclose side effects, whether it overwrites existing materials, prerequisites, or potential errors. Key behavioral aspects 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 two sentences long, no wasted words. Front-loaded with the action, then adds contextual value. Every sentence 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's simplicity (3 params, no output schema), the description adequately explains what it creates and why. It is nearly complete, though it could mention the result (e.g., material added to the project). Still, it meets the needs for this level of complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds general context but does not elaborate on parameter usage (e.g., how to choose mu or conductivity). It does not add significant meaning beyond the schema's own parameter 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 lossy metal material' with a specific verb and resource. It distinguishes from sibling material creation tools by specifying 'lossy metal' and provides typical application contexts (connectors, waveguides, PCB traces).
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 cases for loss calculations but does not explicitly state when to use this tool versus alternatives like cst_create_material or cst_create_drude_material. No when-not-to-use or exclusionary guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new material with electromagnetic properties in CST Studio. Specify relative permittivity (epsilon), relative permeability (mu), electric and magnetic loss tangents, and conductivity.
| Name | Required | Description | Default |
|---|---|---|---|
| mu | No | Relative permeability (mu_r) | |
| name | Yes | Material name (e.g. 'MySubstrate') | |
| color_b | No | Blue colour component (0-1) | |
| color_g | No | Green colour component (0-1) | |
| color_r | No | Red colour component (0-1) | |
| epsilon | No | Relative permittivity (epsilon_r) | |
| tan_d_e | No | Electric loss tangent (tan delta_e) | |
| tan_d_m | No | Magnetic loss tangent (tan delta_m) | |
| conductivity | No | Electric conductivity in S/m | |
| transparency | No | Transparency (0 = opaque, 1 = fully transparent) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description lacks details on side effects or prerequisites (e.g., whether a project must be open, if it overwrites existing materials, or what the return value is). Given no annotations, the description should disclose more 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 two sentences, direct, and to the point. No unnecessary 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 description covers core functionality, it lacks context about the type of material (isotropic, frequency-independent) and potential implications. With 10 parameters and no output schema, 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 100% with descriptions for all parameters. The description merely lists the parameter types but does not add significant meaning beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates a new material with electromagnetic properties and lists the key properties (epsilon, mu, loss tangents, conductivity). However, it does not explicitly differentiate this from sibling tools like cst_create_anisotropic_material or cst_create_debye_material, which might create materials with different behavior.
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. For example, it does not state that this is for simple isotropic materials, nor does it suggest using other tools for frequency-dependent or anisotropic materials.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a 3D polygon curve in CST Studio.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Curve name | |
| points | Yes | List of [x, y, z] coordinate triples |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the full burden of behavioral disclosure. It only says 'Create', implying a write operation, but does not mention side effects, requirements (e.g., open project), or any constraints. The agent cannot infer safety or impact.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no fluff. It is concise, but the brevity sacrifices completeness.
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 creation tool with no output schema and no annotations, the description is insufficient. It does not explain what a 'polygon curve' is (open/closed), coordinate system units, or whether the tool requires an active project. The agent lacks key context for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema fully documents the parameters. The description adds no additional meaning beyond the schema, missing an opportunity to explain format, units, or constraints like coordinate system.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates a 3D polygon curve in CST Studio, specifying the verb and resource. However, it does not distinguish this tool from siblings like cst_create_polygon_extrude or cst_create_analytical_curve, missing an opportunity to clarify when to use this specific tool.
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 vs. alternatives. The description lacks context about prerequisites, typical use cases, or exclusions, 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.
Create a polygon and extrude it along an axis in CST Studio. Convenience tool combining polygon profile creation and extrusion.
| Name | Required | Description | Default |
|---|---|---|---|
| axis | No | Extrusion axis | z |
| name | Yes | Solid name | |
| height | Yes | Extrusion height | |
| points | Yes | List of [x, y] coordinate pairs forming the polygon | |
| material | No | Material name | PEC |
| component | Yes | Component name |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully convey behavior. It only states the tool creates and extrudes a polygon, but does not disclose whether it modifies existing geometry, whether extrusion is additive or subtractive, how components are managed, or units/coordinate system assumptions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two efficient sentences that convey the core purpose without any redundant or vague wording. 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?
Given the tool is a combination of two operations, the description could explain how the extrusion relates to the polygon (e.g., is height applied along axis after creation?). No output schema exists, but the schema covers inputs sufficiently. Some missing context about material default (PEC) and typical use in antenna design could help.
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 100%, so baseline is 3. The description adds no additional meaning beyond the schema parameter descriptions (e.g., points, height, axis). It does not provide examples or clarify relationships between parameters.
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 polygon and extrude it along an axis in CST Studio' as a 'convenience tool combining polygon profile creation and extrusion.' It distinguishes this from siblings like cst_create_polygon3d (polygon only) and cst_create_extrude (generic extrusion) by explicitly combining both 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 mentions it is a 'convenience tool' but provides no guidance on when to use this vs. the separate polygon and extrusion tools, nor any prerequisites or constraints. No when-not-to-use or alternative recommendations are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new CST Studio Suite project file. In connected mode the project is created directly; in offline mode a VBA script is returned for manual execution.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Full file path for the new project, e.g. 'C:/cst_projects/MyAntenna.cst'. | |
| project_type | No | CST project type. One of: MWS (Microwave Studio), EMS (EM Studio), PS (Particle Studio), MPS (Mphysics Studio), CS (Cable Studio), DS (Design Studio), PCB (PCB Studio). | MWS |
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 the dual-mode behavior (direct creation vs VBA script return), which is key. However, it omits important behavioral details: what happens if the path already exists (overwrite? error?), required user permissions, or any side effects. These gaps reduce transparency 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?
Two sentences, each serving a distinct purpose: first states the primary action, second explains mode-dependent behavior. No repetition, no filler words. The most important info ('Create project') is front-loaded.
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 two-parameter tool with no output schema, the description covers the essential: what it does, parameters (via schema), and mode behavior. However, it lacks specifics about return values (beyond VBA script), error handling, or path constraints. Given the context, it is largely complete but could address a few edge cases.
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 describes both parameters with examples and default values (100% coverage). The description adds little beyond the schema, merely restating the path example and project types. With high schema coverage, the baseline is 3; the description does not provide additional semantic value (e.g., constraints on path, format rules).
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 creates a CST project file with specific verb 'Create' and resource 'CST Studio Suite project file'. It distinguishes between connected and offline modes, providing clear scope. No sibling tool has a similar purpose (e.g., cst_open_project opens existing projects), ensuring uniqueness.
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?
Description explains the main use case (creating a project) and provides context about the two operational modes (connected vs offline). However, it does not explicitly state when not to use (e.g., if a project already exists, might need to overwrite) or point to an alternative (cst_open_project for existing projects). Still, the mode distinction offers useful guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a sphere in CST Studio.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Solid name | |
| radius | Yes | Sphere radius | |
| center_x | No | Center X coordinate | |
| center_y | No | Center Y coordinate | |
| center_z | No | Center Z coordinate | |
| material | No | Material name | PEC |
| segments | No | Number of segments (0=auto) | |
| component | Yes | Component name |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only states the basic action. It does not disclose important behavioral details such as default material, coordinate system, or interaction with existing geometry.
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 sentence—and front-loaded. However, it could be slightly more informative without adding 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 an 8-parameter tool with no output schema and no annotations, the description is too sparse. It lacks details about shape behavior, constraints (e.g., radius must be positive), and integration with other CST 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 100%, so baseline is 3. The description adds no additional meaning beyond what is already in the schema parameters (e.g., radius, center coordinates, material).
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 'Create a sphere in CST Studio' clearly states the action (create) and resource (sphere). Among sibling tools, it uniquely identifies the shape, distinguishing it from other creation tools like cst_create_brick or cst_create_cylinder.
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., other shape creation tools like cst_create_cylinder for cylindrical objects). There is no mention of prerequisites or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a material with temperature-dependent electromagnetic properties. Specify base properties and temperature coefficients for thermal-electromagnetic co-simulation.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Material name (e.g. 'Thermal FR-4') | |
| epsilon_r | Yes | Relative permittivity at reference temperature | |
| conductivity | Yes | Electric conductivity in S/m at reference temperature | |
| reference_temp_c | No | Reference temperature in degrees Celsius | |
| temp_coeff_conductivity | No | Temperature coefficient of conductivity (fractional per K) | |
| temp_coeff_epsilon_ppm_k | No | Temperature coefficient of permittivity in ppm/K |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It states the tool creates a material but does not disclose details about validation, side effects, or default behaviors beyond what the parameters imply. It adds moderate 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?
Two concise sentences. The first sentence states the primary purpose, and the second tells what to specify. No extraneous information, well-front-loaded.
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 detailed input schema and no output schema, the description adequately covers the tool's purpose and key usage. It could mention that it creates a new material object or the reference temperature, but overall it is complete for its complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description only says 'Specify base properties and temperature coefficients', which adds little beyond the parameter descriptions in the schema. No additional semantic value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates a material with temperature-dependent electromagnetic properties, specifying base properties and temperature coefficients. It distinguishes this from sibling material creation tools by focusing on temperature dependence and thermal-electromagnetic co-simulation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description indicates usage for thermal-electromagnetic co-simulation and specifying base properties and coefficients. It implies when to use this tool versus generic material creation tools but does not explicitly list alternatives 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.
Create a torus in CST Studio.
| Name | Required | Description | Default |
|---|---|---|---|
| axis | Yes | Torus axis | |
| name | Yes | Solid name | |
| center_x | No | Center X coordinate | |
| center_y | No | Center Y coordinate | |
| center_z | No | Center Z coordinate | |
| material | No | Material name | PEC |
| component | Yes | Component name | |
| inner_radius | Yes | Minor radius (tube radius) | |
| outer_radius | Yes | Major radius (center to tube center) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description must disclose behavioral traits, but it only states the action. It does not mention side effects, prerequisites (e.g., component existence), or error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The single sentence is concise and front-loaded with the action. However, it lacks structure like a secondary sentence for context, but it is not verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 9 parameters and no output schema, the description is too minimal. It does not explain dependencies (e.g., component must exist), geometry constraints, or typical usage patterns.
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 100%, with each parameter having a description (e.g., 'Minor radius (tube radius)'). The tool description adds no extra semantic value beyond the schema, earning the baseline score.
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 torus, a specific geometric shape, distinguishing it from other creation tools like brick or cylinder. The verb-resource combination is clear 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?
No guidance is provided on when to use this tool versus alternatives (e.g., other shape creation tools). The description gives no context for appropriate use cases or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a bondwire / wire between two points in CST Studio.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Solid name | |
| end_x | Yes | End point X | |
| end_y | Yes | End point Y | |
| end_z | Yes | End point Z | |
| radius | Yes | Wire radius | |
| start_x | Yes | Start point X | |
| start_y | Yes | Start point Y | |
| start_z | Yes | Start point Z | |
| component | Yes | Component name |
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 only says 'create', implying mutation, but lacks details on whether it modifies existing geometry, coordinate system units, error conditions, or side effects. This is insufficient for a creation 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 a single clear sentence, concise and front-loaded. However, it could include slightly more context (e.g., coordinate system) 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 the schema covers all parameters and no output schema exists, the description should ideally mention what the tool returns (if anything) and when to use it among many sibling creation tools. It is minimally adequate but lacks these completions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with each parameter briefly described in the schema. The description adds no additional meaning beyond the schema, so baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates a 'bondwire / wire between two points' in CST Studio, using a specific verb and resource. It distinguishes from sibling tools that create other shapes (e.g., brick, cylinder).
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 vs. alternatives like cst_create_brick or cst_create_extrude. There is no discussion of prerequisites, coordinate systems, 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.
Delete a material from the current CST project.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Name of the material to delete |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description states deletion but does not disclose side effects (e.g., impact on objects using the material, irreversibility). With no annotations, the description carries full burden but 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?
Extremely short at one sentence, which is concise but lacks necessary details for a destructive tool. Could be considered under-specified.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Simple tool with one parameter and no output schema, but description omits prerequisites, error conditions, and consequences, making it incomplete.
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 100% with parameter description 'Name of the material to delete'. The description adds no additional meaning beyond the schema, earning baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the action (delete) and resource (material), with scope (current CST project). It clearly distinguishes from sibling tools like cst_create_material (create), cst_list_materials (list), 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 delete, prerequisites (e.g., material must exist), or alternatives. Among many material-related siblings, no context is provided for choosing this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a design parameter from the CST project. The parameter must not be referenced by other parameters or geometry.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Name of the parameter to delete. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It discloses the destructive action and the precondition about references, which is essential behavioral information.
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, no waste, purpose stated first. Efficient and clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple delete operation with one parameter and no output schema, the description provides all necessary context: what it does and a critical precondition.
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 100% and the parameter description in schema ('Name of the parameter to delete') is identical to what the tool description implies. No additional semantic value added.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Delete' and the resource 'design parameter from the CST project'. It is specific and distinct from sibling tools like cst_delete_material or cst_delete_port.
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 includes a crucial usage condition: parameter must not be referenced by others. This implicitly guides when to use, but lacks explicit when-not-to-use or alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a port by its port number.
| Name | Required | Description | Default |
|---|---|---|---|
| port_number | Yes | Port number to delete (1-999) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It only states 'delete a port' without disclosing behaviors like irreversibility, permissions needed, or error handling when port doesn't exist.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One concise sentence with no wasted words. Efficiently communicates the core 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?
For a simple delete operation with one parameter and no output schema, the description is largely complete. It could mention what happens if the port doesn't exist, 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?
Schema coverage is 100%, and the description mirrors the parameter's schema description without adding new semantics. Baseline 3 is appropriate as no additional value is provided.
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 'Delete a port by its port number' clearly states the action (delete), resource (port), and method (by port number). It is specific and distinguishes from sibling tools like cst_add_discrete_port.
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., what if multiple ports share the number, or need to delete a range). No prerequisites or post-conditions mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete simulation results from the current CST project. This prevents the 'Results May Get Incompatible With Model' dialog that blocks automation when modifying a model with existing results. Call before making parameter or geometry changes on a project that has been solved.
| 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 carries the full burden. It discloses that deleting results prevents a disruptive dialog, which is a key behavioral trait. It implies destructiveness (deletion) and automation impact. More detail on persistence or side effects would push it higher, but it's sufficient for a one-action 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 extremely concise: two sentences with no wasted words. The first sentence states the action and primary effect; the second provides context. Perfectly front-loaded and 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?
Given zero parameters and no output schema, the description fully covers the tool's purpose, when to use it, and the behavioral outcome. Nothing essential is missing. The context (automation, model modification) is fully addressed.
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 schema coverage is 100% (empty object). The description doesn't need to add parameter info. Baseline 4 is appropriate as there is no information missing.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it deletes simulation results from the current CST project and explicitly explains the purpose: to prevent the 'Results May Get Incompatible With Model' dialog that blocks automation. It distinguishes itself from sibling delete tools (e.g., cst_delete_material, cst_delete_port) by specifying the resource and context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage guidance: 'Call before making parameter or geometry changes on a project that has been solved.' It tells exactly when to invoke the tool. It lacks explicit 'when not to use' or alternatives, but the context is adequately clear, earning a 4.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find and dismiss any visible CST dialog windows (error popups, 'Results Incompatible' dialogs, solver warnings). Returns the title and text content of each dialog before dismissing it. Use this to unblock CST when a modal dialog is preventing further automation. Uses Win32 API on Windows.
| Name | Required | Description | Default |
|---|---|---|---|
| read_only | No | If true, only read dialog content without dismissing. Default: false (read and dismiss). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Even without annotations, the description discloses key behaviors: it finds and dismisses dialogs, returns title and text, supports a read-only mode, and uses Win32 API on Windows. This is transparent about its functionality and platform dependency.
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 three tight sentences covering action, output, and usage context. Every sentence adds essential information 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 fully covers the tool's purpose, behavior, and usage context. There are no obvious 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?
The only parameter (read_only) is described clearly with its meaning and default: 'If true, only read dialog content without dismissing. Default: false (read and dismiss).' This adds value beyond the schema's basic type/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 the tool finds and dismisses visible CST dialog windows, listing specific examples (error popups, 'Results Incompatible', solver warnings) and noting it returns title/text before dismissing. This distinguishes it from siblings that focus on modeling, simulation, or project management tasks.
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 says 'Use this to unblock CST when a modal dialog is preventing further automation.' This provides a clear use case. It does not mention when not to use or mention alternatives, but the specialized nature makes the guidance sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Evaluate current antenna simulation results against performance goals. Exports S-parameter data and checks VSWR (or return loss) against per-band targets. Read-only — does not modify the model. Returns pass/fail per band, worst VSWR, and detected resonances.
| Name | Required | Description | Default |
|---|---|---|---|
| port | No | Port number for S-parameter (default: 1). | |
| bands | Yes | Frequency bands to evaluate. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It explicitly states read-only, does not modify the model, exports S-parameter data, and returns pass/fail, worst VSWR, and resonances. However, 'exports S-parameter data' could imply writing to disk, which may be a side effect not fully clarified.
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?
Three concise sentences, front-loaded with purpose. No unnecessary words. Each 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?
Given no output schema, the description adequately covers inputs, behavior, and outputs. It could be more specific about the return format, but overall it provides sufficient context for an agent to understand the tool's function.
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 100%, so parameters are well-documented in the schema. The description adds minimal extra meaning beyond stating targets per band, which aligns with the vswr_target field. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool evaluates antenna simulation results against performance goals, specifically checking VSWR or return loss per band. It distinguishes itself from sibling tools like cst_get_vswr or cst_get_s_parameters by combining multiple evaluations and providing a pass/fail summary.
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 clear context for use (after simulation, read-only) but does not explicitly mention when not to use or suggest alternatives among the many sibling tools for specific metrics.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Execute raw VBA code in CST Studio Suite. The code is validated for safety (shell access, file I/O, and external process execution are blocked). In connected mode the code runs directly; in offline mode the validated script is returned for manual execution.
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | VBA code to execute in CST Studio. Must not contain shell commands, file I/O, or external process calls. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the full burden. It discloses safety blocks (shell access, file I/O, external processes) and explains behavior differences between connected and offline modes. It does not cover error handling or return values, but the main behavioral aspects are addressed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with purpose, and each sentence adds necessary detail without redundancy. It is efficient and well-structured.
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 parameter set and absence of output schema, the description covers key aspects: purpose, safety, and modes. It lacks information about return value or side effects like project modifications, but is otherwise complete for a single-parameter 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 coverage is 100%, but the description adds value by specifying that the code must not contain dangerous operations, supplementing the schema's 'VBA code to execute.' This provides practical guidance 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 'Execute raw VBA code in CST Studio Suite,' with a specific verb and resource. It distinguishes itself from sibling tools by mentioning safety validation and two execution modes, 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?
The description explains when to use the tool (to execute VBA code) and provides context about connected vs. offline modes. However, it does not explicitly state when not to use it or compare with alternatives like cst_vba_help or cst_list_vba_objects, which would further clarify usage boundaries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Export the current CST model (or a specific component) to a CAD format. Supports STL, SAT/ACIS, STEP, IGES, OBJ, and NASTRAN.
| Name | Required | Description | Default |
|---|---|---|---|
| format | Yes | Export format: stl, sat, stp (STEP), igs (IGES), obj, nas (NASTRAN). | |
| component | No | Optional component name to export. If omitted, the entire model is exported. | |
| file_path | Yes | Destination file path for the exported CAD file. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions exporting the 'current model' or a specific component and lists formats, but does not disclose behavior like file overwrite rules, authentication needs, or any side effects. Acceptable for a simple export but missing some details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no unnecessary words, all information is relevant and front-loaded.
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 no output schema and no annotations, the description adequately covers purpose, parameters, and scope. It lacks information on error behavior (e.g., file overwrite) but is sufficient for selection and basic 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 100% with descriptions for each parameter. The description adds context beyond the schema by clarifying 'current model (or a specific component)' and listing formats, which complements the enum values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Export' and the resource 'the current CST model (or a specific component)' to CAD formats. It lists supported formats, which distinguishes it from sibling export tools like cst_export_farfield or cst_export_touchstone.
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 (exporting a model or component to CAD) and lists formats, but does not explicitly mention when not to use or alternatives. The context is clear given sibling names, but lacks explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Export far-field radiation pattern data to a file. Requires a completed simulation with far-field monitor results.
| Name | Required | Description | Default |
|---|---|---|---|
| format | No | Export format: csv (comma-separated), ffs (CST far-field source), nsf (NSI near-to-far-field). | csv |
| file_path | Yes | Destination file path for the far-field data. | |
| frequency | Yes | Frequency in GHz for the far-field data to export. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It discloses the prerequisite but lacks details about file overwrite behavior, side effects (e.g., creation of file), or performance impact. The format information is in the schema, so the description is minimally adequate.
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 unnecessary words. The purpose is front-loaded, and the structure is 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?
The description provides the prerequisite but does not explain the output (file creation success), file handling behavior (overwrite, path requirements), or how this tool fits into a workflow relative to siblings like cst_get_farfield. Adequate but incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%; each parameter is already well-described. The tool description does not add meaning beyond repeating 'far-field radiation pattern data,' so it does not improve 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 verb 'Export' and the resource 'far-field radiation pattern data to a file', which is specific and distinct from sibling export tools (e.g., cst_export_cad, cst_export_touchstone) and getter tools (e.g., cst_get_farfield).
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 a clear prerequisite: 'Requires a completed simulation with far-field monitor results,' which guides when to use the tool. It does not explicitly mention alternatives or when not to use it, but the condition is helpful.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Export the current CST project or its geometry to another format such as STL, STEP, IGES, SAT, OBJ, or NASTRAN.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Destination file path for the exported file. | |
| format | Yes | Export format. One of: stl, sat, stp, igs, obj, nas. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose side effects. It mentions exporting but does not specify whether it overwrites existing files, requires an open project, or any other behavioral traits. More detail is needed 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?
Single sentence, concise, front-loaded with the main action. Every word is necessary and information-dense.
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 export tool with two required parameters. Mentions that it exports the 'current' project, which is contextual. However, lacks details on file overwrite behavior or path requirements (e.g., extension).
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 100%, so baseline is 3. The description adds a list of example formats, but these are already enumerated in the schema enum. No additional semantic value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the action 'Export', the resource 'current CST project or its geometry', and lists example formats. This distinguishes it from sibling export tools like cst_export_farfield and cst_export_result.
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?
Implicitly suggests use when exporting geometry or project to the listed formats, but no explicit guidance on when to use this versus alternatives like cst_export_cad or cst_export_touchstone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Export a simulation result to a file (CSV, Touchstone, or text). Specify the result tree path and desired output format. Useful for post-processing results in external tools like MATLAB or Python.
| Name | Required | Description | Default |
|---|---|---|---|
| format | No | Export file format. 'csv' for comma-separated values, 'touchstone' for Touchstone/SnP format (S-parameters only), 'txt' for space-separated text. | csv |
| output_file | Yes | Full file path for the exported file. | |
| result_path | Yes | CST result tree path to export, e.g. '1D Results\S-Parameters\S1,1' or 'Farfields\farfield (f=2.45)'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the full burden of behavioral disclosure. It omits details such as whether the operation is read-only, if it overwrites existing files, or any prerequisites (e.g., a prior simulation must exist). The description only states the action and formats.
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 two sentences. The first sentence states the core function, and the second provides a use case. No unnecessary words or repetition.
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 export tool with three well-documented parameters, the description is adequate but not rich. It does not explain the scope of results (e.g., 1D Results, Farfields) beyond what the schema implies, nor does it contrast with specialized export siblings. A complete description would mention the types of results exportable.
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 100%, so the schema already documents all parameters and their descriptions. The tool description adds no new semantic information beyond indicating that result path and output format are involved. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('Export'), resource ('simulation result'), and supported formats ('CSV, Touchstone, or text'). It differentiates from sibling tools like cst_export_farfield and cst_export_touchstone by being the general-purpose export tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions a use case ('post-processing results in external tools like MATLAB or Python') but does not provide explicit guidance on when to use this tool versus the specialized export siblings (e.g., cst_export_touchstone). No exclusions or alternative recommendations are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Export S-parameter simulation results to a Touchstone file. Requires a completed simulation with S-parameter data.
| Name | Required | Description | Default |
|---|---|---|---|
| format | No | Touchstone format: s1p (1-port), s2p (2-port), snp (n-port). | s2p |
| file_path | Yes | Destination file path for the Touchstone file. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears the full burden of behavioral disclosure. It only states the basic action and a prerequisite, omitting details such as whether the tool overwrites existing files, handles errors, or returns any status indication. This is insufficient for a mutation 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 only two sentences: one for purpose and one for prerequisite. No redundant words or information, making it efficient for an agent to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, and the description does not mention return values, error conditions, or success indication. While the core action and prerequisites are covered, the lack of error/return context leaves the agent without complete guidance for handling the operation's outcome.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes both parameters with 100% coverage (format enum with descriptions, file_path description). The description adds minimal semantic value beyond restating the purpose; it does not clarify parameter usage or constraints 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 specifies the verb 'Export', the resource 'S-parameter simulation results', and the target format 'Touchstone file'. It distinguishes itself from sibling export tools like cst_export_cad, cst_export_farfield, and cst_export_result by focusing specifically on S-parameter data and Touchstone format.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states a prerequisite ('Requires a completed simulation with S-parameter data'), providing clear context for when to use the tool. However, it does not explicitly list when not to use it or suggest alternatives among sibling export tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Extract axial ratio for circularly polarized antennas from a completed CST simulation. Axial ratio (AR) indicates the quality of circular polarization: AR=0 dB is perfect CP, AR<3 dB is acceptable. Can plot AR vs angle or vs frequency.
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | 'vs_angle' to plot AR vs theta at fixed frequency, 'vs_frequency' to plot AR vs frequency at fixed angle. | vs_angle |
| phi_cut | No | Phi angle (degrees) for the observation direction. | |
| frequency | Yes | Frequency in GHz at which to extract axial ratio. | |
| theta_cut | No | Theta angle (degrees) for the observation direction. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It correctly implies a read-only operation after simulation (no mention of state changes) and adds interpretive context (thresholds). It does not disclose output format (e.g., data vs plot), but the mention of 'plot' suggests visualization.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no filler. The first sentence states the core purpose; the second provides context and options. Every word serves a 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 the tool's specificity and the absence of an output schema, the description covers prerequisites (completed simulation), key parameters, and output interpretation. It could mention the need for farfield results or return format, but it remains sufficient for typical use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, but the description adds value beyond it: explaining what axial ratio means, when to use each mode (vs_angle vs vs_frequency), and the significance of thresholds. This helps the agent understand parameter choices.
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 extracts axial ratio from completed CST simulations, defines its meaning (CP quality) with thresholds (0 dB perfect, <3 dB acceptable), and distinguishes between plotting vs angle or frequency. This differentiates it from siblings like cst_get_gain or cst_get_farfield.
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 states 'from a completed CST simulation,' indicating post-simulation use. It does not explain when not to use or list alternatives, but the context of sibling tools and the specific function (axial ratio extraction) makes usage clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Calculate impedance bandwidth from S-parameter results. Finds the frequency range where S11 (or VSWR) meets the specified threshold. Returns center frequency, bandwidth in MHz, and fractional bandwidth percentage.
| Name | Required | Description | Default |
|---|---|---|---|
| port | No | Port number to compute bandwidth for. | |
| criterion | No | 'S11' to use return loss threshold, 'VSWR' to use VSWR threshold. | S11 |
| threshold_db | No | S11 threshold in dB for bandwidth computation. Common values: -10 dB (VSWR 2:1), -6 dB (VSWR 3:1), -15 dB (VSWR 1.4:1). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavior. It states the tool calculates from S-parameter results, implying dependence on existing data, but does not explicitly mention prerequisites, error handling for missing thresholds, or state changes. It provides the core logic but lacks depth on failure modes 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?
Two sentences that are direct and to the point. No redundant information. The description is front-loaded with the core action and efficiently covers the purpose, method, and outputs without excess.
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, the description adequately summarizes the three return values (center frequency, bandwidth in MHz, fractional bandwidth). However, it omits the return format structure, potential error conditions, and precise dependencies on simulation results, which would be helpful 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 100% with detailed parameter descriptions (e.g., threshold_db includes common values). The description adds minimal value beyond the schema, only reinforcing the threshold concept. Baseline of 3 is appropriate as the description does not significantly enhance 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?
Description clearly states the verb 'Calculate impedance bandwidth' and specifies the resource 'from S-parameter results'. It explicitly describes the task of finding frequency range based on S11 or VSWR threshold and lists the returned metrics. This effectively distinguishes it from sibling tools like cst_get_impedance or cst_get_s_parameters.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description provides no guidance on when to use this tool versus other antenna analysis tools. It does not mention prerequisites (e.g., requiring prior S-parameter simulation) or conditions for use. No comparison to siblings or scenarios is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Extract cross-polarization level and cross-polarization discrimination (XPD) from a completed CST simulation. Supports Ludwig-3, Ludwig-2, and circular polarization definitions. Requires a farfield monitor at the specified frequency.
| Name | Required | Description | Default |
|---|---|---|---|
| frequency | Yes | Frequency in GHz at which to extract cross-polarization. | |
| definition | No | Polarization definition to use. 'Ludwig3' is the most common for linear polarization, 'Ludwig2' for aperture antennas, 'circular' for CP antennas. | Ludwig3 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must cover behavioral traits. It mentions the prerequisite (farfield monitor) and supported definitions but does not disclose whether the tool is read-only, what happens if the monitor is missing, or any side effects. The return format and units are also omitted.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loading the purpose and outcome. It is concise, with no unnecessary words or repetition. 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?
Given no output schema, the description should hint at return values. It mentions extracting cross-polarization level and XPD but not the format or structure (e.g., dict, numeric values). The prerequisite is clear, but return details are missing, which is a gap for a data extraction 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 coverage is 100%, so the schema already describes both parameters. The description adds value by stating the prerequisite that frequency must correspond to an existing farfield monitor, but does not enhance parameter meaning beyond the schema's 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 the tool extracts cross-polarization level and XPD from a completed CST simulation. It specifies supported polarization definitions and the prerequisite of a farfield monitor. This distinguishes it from sibling tools like cst_get_gain or cst_get_axial_ratio.
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 context (completed simulation, farfield monitor required) but does not explicitly state when to use this tool versus alternatives like cst_get_axial_ratio or cst_get_farfield. No 'when not to use' guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Extract volume current distribution from a completed CST simulation at a specific frequency. Complements surface current extraction by providing current density inside dielectric or lossy volumes. Requires a current density monitor at the specified frequency.
| Name | Required | Description | Default |
|---|---|---|---|
| component | No | Optional: specific component to extract current for. If omitted, extracts for all components. | |
| frequency | Yes | Frequency in GHz at which to extract current distribution. |
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 the prerequisite (monitor at frequency) and that it works on completed simulations, but does not disclose other behavioral traits like potential performance impact, data format, or error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, concise and front-loaded. The first sentence immediately states the core purpose and scope, the second adds context. No unnecessary 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?
The description covers prerequisites and complementarity but lacks information about the return value (format/structure). Given no output schema, an AI agent might need to know what 'extract volume current distribution' returns (e.g., vector field data). Adequate but missing output 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?
Input schema has 100% description coverage for both parameters (frequency, component). The description adds minimal extra meaning beyond the schema, only restating the requirement for a current density monitor at the specified frequency. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool extracts volume current distribution from a completed CST simulation at a specific frequency. It explicitly distinguishes itself from surface current extraction by mentioning 'volume' and 'inside dielectric or lossy volumes', which differentiates it from sibling cst_get_surface_current.
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 provides a clear prerequisite ('requires a current density monitor at the specified frequency') and positions itself as complementary to surface current extraction. However, it does not explicitly state when not to use it or name alternatives beyond the surface current sibling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get antenna radiation efficiency from a completed CST simulation at a specific frequency. Returns total efficiency (including mismatch), radiation efficiency (excluding mismatch), and mismatch loss in dB.
| Name | Required | Description | Default |
|---|---|---|---|
| frequency | Yes | Frequency in GHz at which to extract efficiency. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided. The description mentions 'from a completed CST simulation,' implying a prerequisite. However, it does not disclose if the operation is read-only, any side effects, or required permissions. The behavioral disclosure is minimal but consistent with a getter 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 two sentences, front-loaded with the main action, and contains no extraneous information. Every word earns its place. It is optimally concise for a simple 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 the tool's simplicity (one parameter, no output schema, no nested objects), the description is fairly complete. It specifies the source (completed CST simulation), the frequency input, and the three output metrics. It could mention that the tool is read-only, but overall it provides adequate context 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 100% (one parameter with description). The description says 'at a specific frequency,' which aligns with the schema's description of 'Frequency in GHz at which to extract efficiency.' The description adds context about the returned values but does not significantly enhance parameter understanding 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's purpose: 'Get antenna radiation efficiency from a completed CST simulation at a specific frequency.' It specifies the verb (Get), resource (antenna radiation efficiency), and details the returned values (total efficiency, radiation efficiency, mismatch loss). This provides strong purpose clarity.
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 explicitly state when to use this tool versus alternatives like cst_get_efficiency_breakdown. It implies usage after a completed simulation but lacks guidance on choosing between efficiency-related siblings. This is a moderate gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a detailed efficiency breakdown with loss budget from a completed CST simulation. Returns radiation efficiency, total efficiency, and individual loss contributions (mismatch, conductor, dielectric). Useful for identifying dominant loss mechanisms in antenna designs.
| Name | Required | Description | Default |
|---|---|---|---|
| frequency | Yes | Frequency in GHz at which to extract efficiency breakdown. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that the tool returns detailed efficiency data including loss contributions, and implies a read-only operation. It does not describe error conditions but provides sufficient behavioral context for typical use.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no wasted words. The first sentence front-loads the purpose and output, and the second adds use-case context. Every sentence is informative.
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 one parameter, no output schema, and no annotations, the description provides adequate context: it names the outputs and use case. It could mention that the simulation must be completed, which is implied. Lacks details on output format but still fairly 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?
There is only one parameter (frequency) with full schema coverage. The description does not add meaning beyond the schema's 'Frequency in GHz at which to extract efficiency breakdown.' Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get a detailed efficiency breakdown with loss budget from a completed CST simulation.' It specifies the output (radiation efficiency, total efficiency, individual loss contributions) and distinguishes itself from sibling tools like cst_get_efficiency by emphasizing detail and loss budget.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions it is 'useful for identifying dominant loss mechanisms in antenna designs' but does not explicitly state when to use this tool versus alternatives (e.g., cst_get_efficiency for simpler efficiency). It implies a prerequisite (completed simulation) but does not explicitly exclude non-completed cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get far-field radiation pattern results from a completed CST simulation at a specific frequency. Returns gain, directivity, radiation efficiency, and beam widths. Requires a farfield monitor at the specified frequency.
| Name | Required | Description | Default |
|---|---|---|---|
| frequency | Yes | Frequency in GHz at which to extract the far-field pattern. | |
| monitor_name | No | Name of the far-field monitor. If omitted, defaults to 'farfield (f=<frequency>)' which is the CST auto-generated name. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description discloses the prerequisite and that it reads completed results. Does not mention error handling, performance, or that it is non-destructive. Acceptable but not exhaustive.
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 focused sentences: first states action and outputs, second states prerequisite. No wasted words, front-loaded.
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, description lists returned items but not format. For a read tool with simple parameters, this is nearly complete. Could specify that results are numeric arrays or scalar, but the listed items imply scalar values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers both parameters with descriptions. Description adds meaning: frequency unit (GHz), monitor default naming convention, and condition that a monitor must exist. Adds value 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?
Clearly states 'Get far-field radiation pattern results' with specific outputs (gain, directivity, efficiency, beam widths). Distinct from sibling tools like cst_get_gain or cst_get_radiation_pattern_3d by summarizing all far-field metrics.
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?
Explicit prerequisite: 'Requires a farfield monitor at the specified frequency.' Does not list when not to use or alternative tools, but the condition is helpful.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get antenna gain at a specific frequency from a completed CST simulation. Returns peak gain in dBi and the direction (theta, phi) of maximum gain. Requires a farfield monitor at the specified frequency.
| Name | Required | Description | Default |
|---|---|---|---|
| frequency | Yes | Frequency in GHz at which to extract gain. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Given no annotations, the description effectively discloses key behaviors: it reads gain from a completed simulation, requires a farfield monitor, and returns peak gain and direction. It is transparent about prerequisites and outputs, but does not mention potential errors if the monitor is 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 three sentences with no fluff: first sentence states purpose, second describes return, third gives a requirement. It is front-loaded and efficient, earning its keep.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read tool with one parameter and no output schema, the description sufficiently covers purpose, return value, and prerequisites. However, it could add clarity about the need for an exact frequency match to the farfield monitor and what happens if the monitor is absent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes the frequency parameter with complete coverage (100%). The tool description adds minimal value by stating 'at a specific frequency' and relating it to the output, but does not provide additional validation or format guidance 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 verb 'Get' and resource 'antenna gain' with specific conditions: 'from a completed CST simulation' and 'at a specific frequency'. It also specifies the output (peak gain in dBi and direction), distinguishing it from siblings like cst_get_efficiency or cst_get_bandwidth.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions the prerequisite of a farfield monitor, implying when not to use, but provides no explicit guidance on when to use this tool versus alternatives like cst_get_farfield or cst_get_radiation_pattern_3d. It lacks exclusionary context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compute group delay from S-parameter phase for a port pair. Group delay is defined as tau = -d(phase)/d(2pif) and represents the signal propagation delay through the device. Useful for UWB antenna and filter characterization.
| Name | Required | Description | Default |
|---|---|---|---|
| port_in | No | Input port number (excitation port). | |
| port_out | No | Output port number (observation port). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description should disclose behavioral traits. It states it computes from S-parameter phase, implying a read operation on existing data, but does not specify whether a prior simulation is required, if results are stored, or any side effects. Some transparency but incomplete 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?
Two sentences: the first succinctly defines the tool's action and formula, the second provides application context. No redundant or extraneous information. Front-loaded with 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?
The tool has only two parameters and no output schema. The description explains the core concept and use cases. However, it lacks details about the return value format (e.g., a single value or array) and any dependencies (e.g., requires solved project). Still, for its simplicity, it 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?
Schema coverage is 100% with descriptions for both parameters. The main description does not add additional semantic meaning beyond the schema's 'input port number' and 'output port number'. The baseline of 3 is appropriate as the schema already handles parameter documentation.
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 computes group delay from S-parameter phase for a port pair, defines the formula, and gives specific use cases (UWB antenna and filter characterization). It distinguishes itself from sibling tools like cst_get_s_parameter_phase by focusing on the derived metric.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions 'useful for UWB antenna and filter characterization' implying context, but does not explicitly state when to use this tool versus alternatives like cst_get_s_parameter_phase or cst_get_impedance. No exclusions or prerequisites are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get input impedance (Z-parameters) for a port from a completed CST simulation. Returns real and imaginary impedance vs frequency. Useful for matching network design and feed optimization.
| Name | Required | Description | Default |
|---|---|---|---|
| port | No | Port number to extract impedance for. |
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 prerequisites (simulation must be completed), limitations (one port at a time), or output format beyond 'real and imaginary impedance vs frequency'.
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?
Three concise sentences, front-loaded with the main action, each sentence serves a distinct purpose: action, output, use case. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a simple tool with full schema coverage, but missing preconditions (simulation must be completed, port must exist) and output details. With no annotations, slightly more context would improve 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 already covers the single 'port' parameter. The description adds value by noting the output type but does not add extra semantic meaning for the parameter. Baseline 3 due to 100% 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?
Clearly states it gets input impedance (Z-parameters) for a port from a completed CST simulation. Distinct from sibling tools like cst_get_s_parameters and cst_get_vswr.
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 matching network design and feed optimization but does not explicitly state when to use this tool vs alternatives like cst_analyze_impedance or cst_impedance_smith_transform.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get electromagnetic properties of a material from the bundled database. Returns epsilon_r, mu_r, conductivity, loss tangent, and usage notes.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Material name (e.g. 'Copper', 'FR-4', 'Rogers RO4003C') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It states what is returned (epsilon_r, mu_r, etc.) and implies a read-only operation via 'get'. However, it does not explicitly confirm it is non-destructive, requires no project context, or handles errors. Still, the verb and output specification provide 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?
The description is two sentences, front-loaded with the action verb, and every sentence adds value. No unnecessary 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 simplicity (1 param, no output schema), the description covers the primary purpose and return values. It could mention whether it works independently of an open project or the behavior for invalid material names, but it is mostly 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 schema coverage is 100% with a clear parameter description and examples. The tool description adds context about the return values but does not enhance the parameter semantics beyond what the schema provides. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets electromagnetic properties of a material from the bundled database, which is a specific verb-resource combination. It distinguishes itself from siblings like cst_list_materials (which lists names) and cst_create_material (which creates new materials) by focusing on retrieving properties.
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 retrieving properties of built-in materials but does not explicitly state when to use this tool versus alternatives like cst_list_materials or cst_load_material. No guidance on prerequisites or when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get current mesh statistics and settings. In connected mode this queries the live mesh data; in offline mode it returns the VBA to retrieve mesh info.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses mode-dependent behavior (connected vs offline) which is important. With no annotations, description carries full burden; it does not mention read-only nature, authorization needs, or performance implications, which are minor gaps.
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, no wasted words. Action stated upfront, mode clarification in second sentence. Perfectly structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a zero-parameter tool, but lacking output schema or detailed description of returned data (e.g., types of statistics). Could be more complete by listing example outputs.
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 is 4 per rules. Description adds meaning by explaining what is returned in each mode, fulfilling the requirement for zero-parameter tools.
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 'Get current mesh statistics and settings', specifying the resource and action. It distinguishes between connected and offline modes, adding precision. However, it could more explicitly differentiate from sibling tools like cst_get_mesh_quality.
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. The mode description hints at context, but does not mention when to prefer this over cst_get_mesh_quality or other mesh tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Extract mesh quality metrics including total cells, aspect ratios, and cells per wavelength. In connected mode this queries actual mesh statistics; in offline mode it describes what metrics would be returned.
| 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 the full burden. It discloses two behavioral modes (connected queries real data, offline describes expected metrics), but does not state whether this is a read-only operation, any side effects, or authentication requirements. The disclosure is moderate.
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, front-loaded with key capabilities, no redundant information. Could be slightly more specific about return format, 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?
The description covers the tool's purpose and two modes, but lacks details about output structure or what exactly 'mesh quality metrics' include beyond the examples. Given no output schema, more specificity would be beneficial for 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?
There are no parameters (schema coverage 100% with empty properties), so the baseline is 4. The description adds no parameter information, 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 description clearly states the tool extracts mesh quality metrics (total cells, aspect ratios, cells per wavelength), with a specific verb and resource. However, it does not differentiate from a similar sibling tool, cst_get_mesh_info, which could cause confusion.
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 differentiates connected vs offline mode, providing some context for when each mode applies. However, it offers no guidance on when to use this tool versus alternatives like cst_get_mesh_info, and no exclusions 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 value of a design parameter. Returns both the stored expression and the evaluated numeric value.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Name of the parameter to retrieve. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description partially carries the burden. It discloses the return format (expression and numeric value) but omits behaviors like error handling or 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?
Two concise sentences, front-loaded with the purpose. Every word adds value; 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 and no output schema, the description adequately explains the return values (expression and numeric value). Minor omission: no mention of error behavior when parameter is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes the 'name' parameter (coverage 100%). The description adds no additional meaning beyond the schema, meeting the baseline.
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 ('Get') and resource ('current value of a design parameter'). It distinguishes from sibling tools like 'cst_list_parameters' (which lists all) and 'cst_set_parameter' (which sets).
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 retrieving a specific parameter's value, but it does not explicitly state when to use this tool versus alternatives like 'cst_list_parameters' or handle error cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Extract an E-plane, H-plane, or custom radiation pattern cut from a completed CST simulation at a specific frequency. Returns gain vs angle for the selected plane. Requires a farfield monitor at the specified frequency.
| Name | Required | Description | Default |
|---|---|---|---|
| plane | No | Pattern cut plane. 'E' for E-plane (phi=0), 'H' for H-plane (phi=90), 'custom' for arbitrary cut. | E |
| phi_cut | No | Phi angle (degrees) for custom plane cut. Only used when plane='custom'. Default 0. | |
| frequency | Yes | Frequency in GHz at which to extract the pattern cut. | |
| theta_cut | No | Theta angle (degrees) for custom plane cut. Only used when plane='custom'. Default 90. |
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 extracts data from a 'completed' simulation (implying non-modifying), returns 'gain vs angle', and requires a farfield monitor. This gives good behavioral context, though it could explicitly state it is read-only.
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?
Three short sentences: action, return type, prerequisite. No wasted words. Every sentence is necessary and front-loaded.
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 no output schema, the description adequately explains the return ('gain vs angle') and the prerequisite. Given the tool's simplicity (extracting a pattern cut), the description covers all needed context for an AI 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 description coverage is 100%, so baseline is 3. The description adds the prerequisite requirement but does not significantly augment the parameter meanings already in the schema. For example, the schema already explains that plane='E' corresponds to phi=0. Thus, minimal added value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool extracts an E-plane, H-plane, or custom radiation pattern cut from a completed CST simulation at a specific frequency. It distinguishes itself from siblings like cst_get_farfield (which likely returns full 3D) by specifying it is a 'cut', i.e., a 2D slice.
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 a clear prerequisite: requires a farfield monitor at the specified frequency. It implicitly suggests use for 2D pattern cuts, but does not explicitly state when not to use it (e.g., for 3D patterns) or mention alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Export full 3D radiation pattern data from a completed CST simulation at a specific frequency. Returns gain values over the full sphere in spherical or Cartesian coordinates. Useful for antenna pattern visualization and integration with external tools. Requires a farfield monitor at the specified frequency.
| Name | Required | Description | Default |
|---|---|---|---|
| frequency | Yes | Frequency in GHz at which to extract the 3D pattern. | |
| coordinate | No | 'spherical' for (theta, phi, gain) output, 'cartesian' for (x, y, z, gain) output. | spherical |
| resolution_deg | No | Angular resolution in degrees for the exported pattern. Lower values give finer resolution but larger data. Typical values: 1, 2, 5, 10. |
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 discloses the tool is read-only (export) and requires a farfield monitor, but does not address error handling (e.g., missing monitor or incomplete simulation) or return data volume implications. Additional details on behavior beyond the basic action 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 four sentences, each providing essential information: purpose, output, use case, and prerequisite. No wasted words, and the core action is front-loaded.
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 explains what is returned ('gain values over the full sphere') but lacks specifics on output format (e.g., array, structure) or data size implications of resolution_deg. Given no output schema, more detail on return type is needed for full 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 100% with clear descriptions for all three parameters (frequency, coordinate, resolution_deg). The description adds minimal extra meaning beyond the schema, such as mentioning 'spherical or Cartesian coordinates' which already appears in the enum description. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool exports full 3D radiation pattern data at a specific frequency, specifying gain values over the full sphere in spherical or Cartesian coordinates. It distinguishes from sibling tools like cst_get_farfield or cst_get_pattern_cut by emphasizing 'full 3D' and 'over the full 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?
The description mentions a prerequisite ('Requires a farfield monitor at the specified frequency') and indicates usage for antenna pattern visualization and integration. However, it does not explicitly contrast with alternatives such as cst_get_farfield (for farfield data) or cst_get_pattern_cut (for a single cut), which could further guide selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a summary of all key simulation results from a completed CST simulation. Returns an overview of S-parameters, gain, efficiency, and impedance. Useful for a quick design evaluation without querying each result type individually.
| 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 carry the full burden. It communicates that the tool requires a 'completed CST simulation' and returns an overview, but it does not disclose whether it is read-only, if it has side effects, or any prerequisites beyond simulation 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 two sentences with no fluff. It starts with the action and resource, then lists return types, ending with use case. 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 tool with no parameters, no output schema, and many siblings, the description adequately covers what the tool does and when to use it. It lacks details on output format or limitations, but given the simple interface, it is sufficiently 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 no parameters, and schema description coverage is 100% (vacuously). The description adds no parameter information, which is appropriate given zero parameters. Baseline for 0 params is 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 identifies the tool's purpose: retrieving a summary of all key simulation results from completed CST simulations. It specifies the types (S-parameters, gain, efficiency, impedance) and contrasts it with siblings by emphasizing the consolidated overview approach.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states it is 'useful for a quick design evaluation without querying each result type individually,' which implies usage context. While it doesn't explicitly list exclusions or alternative tools, the sibling tools provide those alternatives, making the guidance clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check the status and progress of a running CST simulation. Returns information such as whether a simulation is running, progress percentage, mesh cell count, and current time step.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description states what is returned but does not mention side effects or behavior (e.g., read-only, requires active simulation). Additional context like 'does not modify simulation state' 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?
Two sentences, front-loaded with purpose and key return details. 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?
Tool is simple with no parameters or output schema. Description sufficiently covers purpose and return values, making it complete for an agent to understand 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?
No parameters exist; schema coverage is 100% (vacuously). Baseline score of 4 is appropriate as description adds no parameter info 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?
Clearly states the tool checks status and progress of a running CST simulation. Lists specific return information (running, progress, mesh, time step), distinguishing it from siblings like run, pause, stop, and solver info 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?
Implicitly indicates use after starting a simulation, but lacks explicit guidance on when not to use it or alternatives (e.g., cst_get_solver_info for solver-specific details). No exclusions mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Extract Smith chart formatted impedance data from a completed CST simulation. Computes normalized impedance from S11 reflection coefficient: Z = Z0*(1+S11)/(1-S11). Returns real and imaginary parts of the normalized impedance for Smith chart plotting.
| Name | Required | Description | Default |
|---|---|---|---|
| z0 | No | Reference impedance in Ohms for normalization. Typically 50 Ohms for most RF systems. | |
| port | No | Port number to extract Smith chart data for. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses the transformation formula (Z = Z0*(1+S11)/(1-S11)) and output (real and imaginary parts). It could mention error conditions (e.g., incomplete simulation), but the core behavior 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?
Two concise sentences with no wasted words. The key purpose is front-loaded, and the formula adds precise detail without verbosity.
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 the tool's function, prerequisites, and output type. It lacks detail on return structure (e.g., JSON format) but is sufficient given the parameter simplicity and lack of output schema.
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 100% with both parameters (z0, port) well-described. The description does not add additional meaning beyond the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool extracts Smith chart formatted impedance data from a completed CST simulation, using a specific verb and resource. It differentiates from sibling tools like cst_get_impedance and cst_impedance_smith_transform by specifying the output format and computation.
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 simulation completion ('from a completed CST simulation') but does not explicitly provide when-to-use vs. alternatives or when-not-to-use. No comparison with similar sibling tools is given, leaving some ambiguity for the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get current solver configuration and status. In connected mode this queries the active solver settings; in offline mode it describes expected parameters.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full responsibility for behavioral disclosure. It notes that behavior differs by mode (queries vs describes), which is helpful. However, it omits details like whether a connection is required, authentication needs, or side effects, leaving some ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences with clear structure. Every word adds value, and it is front-loaded with the action and key modes.
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, more detail about the return value (e.g., structure or fields) would improve completeness. The description says 'solver configuration and status' but doesn't specify what that includes, leaving the agent to infer.
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 no parameters, and the schema coverage is 100% (trivially). The description adds no extra parameter info because none are needed. Per guidelines, for zero parameters baseline is 4, and the description meets that standard.
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 retrieves solver configuration and status, with explicit distinction between connected and offline modes. This differentiates it from sibling tools like cst_get_mesh_info or cst_get_simulation_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 provides context on when to use the tool (connected vs offline mode), which helps decide applicability. However, it does not explicitly state when not to use it or mention alternatives, though the sibling list is extensive and this tool is unique.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Extract S-parameter phase response from a completed CST simulation. Returns the phase of the specified S-parameter vs frequency. Optionally unwraps the phase to remove 360-degree discontinuities. Useful for group delay analysis and phase-matching designs.
| Name | Required | Description | Default |
|---|---|---|---|
| unwrap | No | If true, unwrap the phase to remove 360-degree jumps. Useful for group delay computation. | |
| port_in | No | Input port number (excitation port). | |
| port_out | No | Output port number (observation port). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It indicates that the tool extracts data (read-only) and optionally unwraps phase, but it does not explicitly state that it does not modify any simulation state, require specific permissions, or have side effects. The description is adequate for a simple query but lacks explicit read-only confirmation.
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 only two sentences. The first sentence immediately conveys the core purpose, and the second adds optional functionality and use cases. No extraneous information is present.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description should ideally mention the return format (e.g., list of frequency and phase pairs) and units (degrees or radians). The number of parameters is small and well-documented, but the output is not described. For a data extraction tool, this is a noticeable gap.
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 100% coverage of parameters, but the description adds value by explaining the purpose of the 'unwrap' parameter (group delay analysis) and clarifying that 'port_in' is the excitation port and 'port_out' is the observation port. This semantic enrichment goes beyond the 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 extracts S-parameter phase response from a completed CST simulation, specifying the output (phase vs frequency) and optional unwrapping. This distinctly sets it apart from sibling tools like cst_get_s_parameters (which returns complex S-parameters) and cst_get_group_delay (which derives group delay).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions use cases ('group delay analysis and phase-matching designs') but does not explicitly state when not to use this tool or provide alternatives (e.g., using cst_get_s_parameters for magnitude/phase or cst_get_group_delay for group delay directly). It lacks guidance on prerequisite conditions (e.g., simulation must be completed).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Extract S-parameter results from a completed CST simulation. Returns S-parameter data (magnitude, phase, real/imaginary) for the specified port pair. In connected mode reads directly from the result tree; in offline mode returns VBA scripts and explains the CST result tree structure.
| Name | Required | Description | Default |
|---|---|---|---|
| format | No | Output format for S-parameter data. 'db' = magnitude in dB, 'mag' = linear magnitude, 'real_imag' = real and imaginary parts, 'phase' = phase in degrees. | db |
| port_in | No | Input port number (excitation port). | |
| port_out | No | Output port number (observation port). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; the description discloses dual-mode behavior and return content, but lacks information on prerequisites (e.g., simulation must be completed), error conditions, or side effects. It does not confirm 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 two efficient sentences: first defines the core purpose, second explains the two modes. Every sentence is meaningful 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 output schema, the description covers the tool's purpose, output data types, and operational modes. However, it lacks details on the structure of the returned data and error handling, which would be helpful 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 100%, and the description only paraphrases the format and port parameters already defined in the schema. It adds no new semantics or constraints beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool extracts S-parameter results from completed CST simulations, specifies the return data types (magnitude, phase, real/imaginary), and distinguishes it from the more specific sibling 'cst_get_s_parameter_phase' by being general-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?
The description implies usage after a completed simulation and explains two operational modes (connected vs offline), but does not explicitly state when to use this tool over alternatives like 'cst_get_s_parameter_phase' or other extraction tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Extract surface current density distribution from a completed CST simulation at a specific frequency. Useful for understanding current flow on antenna structures and identifying hot spots. Requires a surface current monitor at the specified frequency.
| Name | Required | Description | Default |
|---|---|---|---|
| component | No | Optional: specific component to extract current for. If omitted, extracts for all components. | |
| frequency | Yes | Frequency in GHz at which to extract surface current. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description adds behavioral context beyond the schema by specifying that the simulation must be completed and that a surface current monitor is required. However, it does not disclose whether the operation is read-only, side effects, or error conditions like missing monitors.
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 three concise sentences, front-loaded with the main purpose. Each sentence adds essential context without unnecessary fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, the description covers the main precondition (completed simulation, monitor) and purpose. However, it lacks details on the output format or return type, which would enhance 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 100%, providing baseline of 3. The description adds meaning for the 'frequency' parameter by linking it to a required monitor, but does not add extra information for 'component'. The added context is modest.
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 'extract' and the resource 'surface current density distribution', specifying the context of a completed CST simulation at a specific frequency. It differentiates from siblings like cst_get_current_distribution by focusing on surface current and requiring a monitor.
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 clear context for use (understanding current flow on antenna structures, identifying hot spots) and states a prerequisite (surface current monitor at the specified frequency). However, it does not explicitly compare to alternative tools like cst_get_current_distribution.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Extract time-domain port signal waveforms from a completed CST time-domain simulation. Returns incident, reflected, or transmitted signal vs time. Useful for UWB pulse analysis, time-domain reflectometry, and transient response evaluation.
| Name | Required | Description | Default |
|---|---|---|---|
| port | No | Port number for the signal. | |
| port_out | No | Output port number (only used when signal_type='transmitted'). Specifies which port receives the transmitted signal. | |
| signal_type | No | 'incident' for the excitation signal at the port, 'reflected' for the reflected signal, 'transmitted' for the signal received at another port. | reflected |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for behavioral transparency. It describes a read-like operation but does not explicitly confirm it is non-destructive, nor does it mention any side effects, authentication requirements, or error conditions (e.g., what happens if the simulation is not completed). The description is too brief for a tool lacking 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 highly concise at three short sentences. It front-loads the primary action and purpose, followed by the signal types and use cases. Every sentence adds value without redundancy or 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 moderate complexity and 100% schema coverage, the description provides a reasonable overview but misses key context: it does not explain the relationship between signal_type='transmitted' and the port_out parameter, nor does it describe the output format (beyond 'signal vs time') despite no output schema being present. It is functional but 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 already provides 100% coverage with descriptions for all three parameters. The tool description adds no additional semantic information beyond what the schema states, so it meets the baseline expectation but does not exceed 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 verb 'extract' and the resource 'time-domain port signal waveforms from a completed CST time-domain simulation'. It lists the three signal types (incident, reflected, transmitted) and provides example use cases. This level of specificity distinguishes it from sibling tools that focus on frequency-domain results like S-parameters or impedance.
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 stating 'from a completed CST time-domain simulation', but does not explicitly state when to use this tool versus alternatives (e.g., frequency-domain result tools). It lacks guidance on prerequisites or when not to use it, so the agent must infer context from the signal type and sibling names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get Voltage Standing Wave Ratio (VSWR) for a port from a completed CST simulation. VSWR indicates impedance matching quality: 1.0 is perfect match, <2.0 is generally acceptable. Can also be computed from S11: VSWR = (1+|S11|)/(1-|S11|).
| Name | Required | Description | Default |
|---|---|---|---|
| port | No | Port number to extract VSWR for. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the behavioral burden. It explains that VSWR is derived from S11 and provides the formula and interpretation. However, it does not disclose error handling, required solver, or whether the tool can be called mid-simulation. The condition 'completed simulation' is useful but not exhaustive.
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 two sentences plus a formula, all front-loaded. The first sentence states the main purpose, and subsequent sentences add relevant context about VSWR. 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?
The description lacks output details. It does not specify the type or format of the return value (e.g., single number vs. frequency-dependent curve), which is critical since no output schema is provided. The input is adequately described, but the missing output specification reduces 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 100%, so the schema already describes the 'port' parameter. The description adds no further semantics beyond the schema's definition, keeping the score at the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Get Voltage Standing Wave Ratio (VSWR) for a port from a completed CST simulation.' It specifies the resource (VSWR) and condition (completed simulation). However, it does not differentiate this tool from sibling get_* tools, missing explicit context on when to use this particular tool.
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 a completed simulation, providing a condition, but does not offer guidance on alternatives or when not to use it. No comparison to other tools or exclusion criteria are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Apply a reactive element transformation to an impedance on the Smith chart. Supports series L/C, shunt L/C, and transmission line operations. Returns transformed impedance, reflection coefficient, and VSWR. Pure Python computation.
| Name | Required | Description | Default |
|---|---|---|---|
| z0 | No | Reference impedance in ohms (default 50) | |
| value | Yes | Component value: L in nH, C in pF, or transmission line electrical length in degrees | |
| operation | Yes | Type of transformation to apply | |
| z_in_imag | Yes | Input reactance in ohms | |
| z_in_real | Yes | Input resistance in ohms | |
| frequency_ghz | Yes | Operating frequency in GHz |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses that computation is pure Python (no simulation), lists return values, and enumerates allowed operations. However, it does not describe behavior for invalid inputs or boundary conditions, which would be beneficial for agent decision-making.
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?
Three concise sentences with no filler. The most critical information (purpose, operations, returns, computation type) is front-loaded. Every sentence 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 no output schema, the description adequately lists return types. For a transform tool with moderate complexity (6 params, 5 required), the core functionality is covered. Missing are examples or details on parameter relationships, but it remains sufficient for most uses.
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 100%, so baseline is 3. The description adds value by specifying units for component values (L in nH, C in pF, electrical length in degrees) and clarifies that value depends on operation type, which goes beyond the schema's generic 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?
Clearly states the tool applies reactive element transformations on a Smith chart, lists specific operations (series L/C, shunt L/C, transmission line), and specifies outputs (transformed impedance, reflection coefficient, VSWR). This distinguishes it from sibling tools like impedance analysis or stub matching.
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., cst_matching_* tools). No prerequisites, limitations, or exclusions are mentioned, leaving the agent to infer appropriate context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Import a CAD file into CST Studio. Supports STEP (.stp/.step), IGES (.igs/.iges), STL (.stl), SAT/ACIS (.sat), DXF (.dxf), and OBJ (.obj) formats.
| Name | Required | Description | Default |
|---|---|---|---|
| format | Yes | CAD file format: stp (STEP), igs (IGES), stl, sat (ACIS), dxf, obj. | |
| component | No | Target component name for the imported geometry. | Import |
| file_path | Yes | Full path to the CAD file to import. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only states the basic action without disclosing behavioral traits such as whether it merges or replaces existing geometry, or if it creates a new component.
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 efficient sentences: first states the action, second lists supported formats. 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?
For a simple import tool, the description is adequate but has gaps. It does not mention what happens to existing data, nor does it explain the component parameter behavior. Without an output schema, more context on results would be 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?
Schema coverage is 100% with descriptions for all three parameters. The description adds context by listing supported formats, which is partially redundant with the enum in the schema. It does not significantly enhance parameter understanding 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 verb 'Import' and the resource 'a CAD file into CST Studio', and lists the supported formats. This distinguishes it from other import tools like cst_import_touchstone.
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 CAD files through the listed formats, but does not explicitly state when to use this tool versus alternatives (e.g., cst_import_touchstone) or provide any 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.
Import a Touchstone S-parameter file (.s1p, .s2p, .snp) into CST Studio for use as a reference or circuit element.
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | Yes | Full path to the Touchstone file (.s1p, .s2p, etc.). | |
| port_number | No | Port number to associate the imported data with. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for disclosing side effects, but it does not mention whether it modifies the project tree, overwrites existing data, or requires specific permissions. The phrase 'into CST Studio' is vague about the target location.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single, straightforward sentence with no filler. Every word is necessary and informative.
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 an import tool with no output schema, the description lacks details about the import's impact (e.g., component creation, project state). It is adequate but not thorough given the tool's potential complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (both parameters documented), and the description adds marginal value by mentioning file types and usage purpose. The port_number parameter is already explained in schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (import), resource (Touchstone S-parameter file with explicit extensions .s1p, .s2p, .snp), and intended use (as reference or circuit element). It effectively distinguishes from siblings like cst_export_touchstone.
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, prerequisites (e.g., open project), or conditions under which import should be avoided. The agent is left to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all available parametric antenna templates with descriptions and typical use cases. No arguments required.
| 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 carries full burden. It describes the tool as a read-only listing operation, which is non-destructive. However, it does not disclose potential behaviors like return format or performance implications, which is adequate but not exceptional.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the core purpose and includes useful detail about descriptions and use cases. Every word 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?
While the description covers the basic purpose, it omits details about the output format. Given no output schema, the description could have been more explicit about what the list contains (e.g., names, dictionaries) to fully prepare the agent. It is 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?
With zero parameters and 100% schema coverage, the schema is already complete. The description adds value by explicitly stating 'No arguments required,' confirming the parameterless invocation, which aligns with the 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 the tool lists all available parametric antenna templates with descriptions and typical use cases. The verb 'list' and the resource 'parametric antenna templates' are specific and distinguish it from sibling tools like specific antenna creation tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly notes that no arguments are required, providing clear usage guidance. While it doesn't explicitly contrast with other tools, the context of sibling antenna tools implies this is for browsing before selection, making it clear when to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List available ferrite materials from the bundled database. Returns name, permittivity, saturation magnetisation, linewidth, loss tangent, maximum frequency, and usage notes for each ferrite.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but the description accurately implies a read-only operation by stating it lists materials from the database; no side effects are disclosed, which is acceptable for a simple list.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with the action, and each word adds value; 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 parameters and no output schema, the description fully covers the tool's behavior and output, making it complete for a list 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?
No parameters exist, schema coverage is 100%, and the description adds value by detailing the return fields, exceeding the baseline for zero-parameter tools.
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 lists ferrite materials from the bundled database, with a specific verb and resource, and distinguishes from sibling tools like cst_list_materials and cst_create_ferrite_material.
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 as a retrieval tool, but no explicit guidance on when to use vs alternatives like cst_list_materials 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 available materials from the bundled material database. Optionally filter by category: 'metals', 'dielectrics', or 'substrates'. Returns name, key EM properties, and usage notes for each material.
| Name | Required | Description | Default |
|---|---|---|---|
| category | No | Filter by category: 'metals', 'dielectrics', or 'substrates' |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description indicates return content (name, properties, usage notes) but does not explicitly state it is a read-only operation with no side effects. Given no annotations, provides moderate transparency but could clarify data source or performance.
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-sentence structure. Front-loaded with core purpose, then adds filtering and return details. No unnecessary 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 list tool without output schema, description specifies return content (name, properties, notes). Lacks pagination or size hints but sufficient for typical use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema already fully describes the parameter with enum values. Description adds context by identifying the categories as material types, but no additional syntax or usage details beyond schema. Baseline 3 due to 100% 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?
Clearly states it lists available materials from a specific bundled database, with optional filtering by category. Distinguishes itself from sibling tools like cst_get_material_info (single material info) and cst_create_material (creation).
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 filtering options but no explicit guidance on when to use this versus sibling tools like cst_get_material_info or cst_list_ferrite_materials for specific material types.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all design parameters in the current CST project with their names, expressions, and evaluated numeric values.
| 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 carries full burden. It indicates read-only behavior (list) with no side effects, but provides no additional context beyond purpose, such as performance implications or permission requirements. The description is 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 a single, clear sentence that front-loads the verb and resource. Every word is necessary, with no redundancy or extra 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 (no parameters, no output schema), the description is fully complete. It covers what the tool does and what it returns, which is sufficient for an AI agent to understand its purpose 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?
The input schema has no parameters (schema coverage 100%), so the description does not need to add parameter details. However, it adds value by specifying the output context (names, expressions, values), which goes beyond the empty 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 lists all design parameters in the current CST project, specifying the returned information (names, expressions, numeric values). It uses a specific verb ('list') and distinguishes from siblings like cst_get_parameter (single get) and cst_set_parameter (set).
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 needing a full list of parameters, but lacks explicit guidance on when to use this tool versus alternatives like cst_get_parameter. No exclusions or prerequisites are mentioned, which is a minor gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all ports defined in the current CST project. Returns VBA to query port information, or a description in offline mode.
| 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. It discloses key behaviors: returns VBA code (not raw data) and describes offline mode behavior. This adds useful context beyond the schema.
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 efficient sentences: first states purpose with scope (current project), second explains return type in two modes. No unnecessary 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 zero-parameter list tool, the description fully covers purpose, return type (VBA or description), and context (offline mode). No gaps given the simplicity.
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 defined; schema coverage is 100% with zero params. Baseline is 4 as description is irrelevant here. No further explanation 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 description clearly states the tool lists all ports in the CST project, distinguishing it from sibling tools that add or delete ports. The verb 'List all' and resource 'ports' 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?
No explicit guidance on when to use vs alternatives. However, the tool's purpose is straightforward (listing), and the context of sibling tools implies it's for viewing ports. A minimal viable score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all available results in the CST result tree. Optionally specify a subtree path to narrow the listing. Useful for discovering what simulation results are available before extracting specific data.
| Name | Required | Description | Default |
|---|---|---|---|
| tree_path | No | Result tree path to list, e.g. '1D Results', '1D Results\S-Parameters', 'Farfields', '2D/3D Results'. Omit to list top-level result categories. |
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 implies a read-only operation (listing) but does not explicitly state it does not modify data or require permissions. The description is straightforward but lacks depth; a score of 3 is appropriate for a simple 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 two sentences, to the point, with no unnecessary words. It front-loads the purpose and adds usage context efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one optional parameter, no output schema), the description covers the purpose, usage context, and parameter. It could mention the return format (e.g., list of paths), but that is not critical. The description is nearly 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 coverage is 100% for the single parameter, so baseline is 3. The description adds context by stating the parameter is optional and used to narrow the listing, which is a minor addition. It does not provide substantial new 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 lists all available results in the CST result tree, with optional subtree filtering. The verb 'List' and resource 'CST result tree' are specific, and the mention of discovering results before extraction distinguishes it from sibling tools like cst_get_result_summary or cst_export_result.
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 says the tool is 'Useful for discovering what simulation results are available before extracting specific data,' providing clear context for when to use it. It does not mention when not to use or name alternatives explicitly, 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.
List available CST Studio VBA objects, optionally filtered by category. Returns object names with brief descriptions.
| Name | Required | Description | Default |
|---|---|---|---|
| category | No | Optional category filter. If omitted, all categories are returned. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It indicates a read-only query (list operation) with no side effects, but does not explicitly state safety, permissions, or limitations. The description is adequate but not thorough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with two clauses, efficiently communicating purpose, filtering, and output. 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 adequately covers the return format (names with descriptions) and filtering. It is complete enough for the agent to use effectively.
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 100%; the description adds minimal value by restating the filtering option. It does not elaborate on the category values or parameter behavior beyond what the schema provides. Baseline 3 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?
The description clearly states it lists CST Studio VBA objects, specifying optional filtering by category and noting the return of names with descriptions. This distinguishes it from sibling tools like cst_list_materials or cst_list_ports, 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?
The description implies usage for discovering available VBA objects, especially with filtering. However, it lacks explicit guidance on when not to use it or alternatives. Given the context, it provides clear context but no exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Load a material from the CST material library by its library name. The material is added to the project under the given name.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Name for the material in the project | |
| library_name | Yes | Name in the CST library (e.g. 'Copper (annealed)') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description does not disclose side effects like overwriting, permissions, or error handling, leaving behavioral aspects unclear.
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 efficient sentences with no wordiness, clearly communicating purpose and key operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a simple tool but lacks details on error handling or behavior when inputs are invalid or duplicate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers both parameters with descriptions; description reinforces 'library_name' and 'name' roles, adding slight context.
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 loads a material from the CST library and adds it to the project, distinguishing it from create material 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?
It implies usage for loading predefined materials, but lacks explicit alternatives 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.
Generate CST VBA code to create a lumped-element matching network. Each component (inductor, capacitor, resistor) is placed as a CST LumpedElement with specified series/shunt connection.
| Name | Required | Description | Default |
|---|---|---|---|
| components | Yes | List of lumped components in the network (ordered source to load) | |
| frequency_ghz | Yes | Design frequency in GHz | |
| port_impedance | No | Port reference impedance in ohms (default 50) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It only states what the tool does (generate code) without disclosing side effects, whether it executes the code, if it modifies existing components, or requires an open project. For a code-generation 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?
Description is a single concise sentence with no redundant phrases. It efficiently conveys the core function, though slight restructuring could improve clarity (e.g., separating the code generation aspect from the placement details).
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 or annotations, the description should explain what the generated code does, its format, or any prerequisites. It lacks information about execution context, return value, or integration with CST, leaving significant 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 covers 100% of parameters with descriptions; the description adds minimal extra meaning (e.g., placing components as LumpedElement with series/shunt). Baseline 3 is appropriate as no additional semantic insight is provided 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 generates CST VBA code to create a lumped-element matching network with explicit mention of components (inductor, capacitor, resistor) and placement as CST LumpedElement. This differentiates it from sibling tools like cst_matching_l_network or cst_matching_pi_network which target specific topologies.
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 matching network tools or lumped element tools). There is no mention of prerequisites, contexts, 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.
Design an L-section impedance matching network. Computes inductor and capacitor values for matching a source impedance to a load impedance at a given frequency. Supports lowpass and highpass topologies. Pure Python computation — no CST connection needed.
| Name | Required | Description | Default |
|---|---|---|---|
| topology | No | Network topology (default lowpass) | lowpass |
| z_load_imag | No | Load reactance in ohms (default 0) | |
| z_load_real | Yes | Load resistance in ohms | |
| frequency_ghz | Yes | Design frequency in GHz | |
| z_source_imag | No | Source reactance in ohms (default 0) | |
| z_source_real | Yes | Source resistance in ohms |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must handle behavioral disclosure. It explicitly states 'Pure Python computation — no CST connection needed,' which clarifies side effects (none) and independence from CST. It doesn't describe return format or error behavior, but the core behavior is well-covered.
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 three sentences, front-loaded with the primary purpose, and contains no redundant information. Every sentence adds value: purpose, computation, topologies, and independence from CST.
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 and no output schema, the description covers the essential aspects. It could mention that the tool returns L and C values, but this is implicit. Slight gap in output specification prevents a perfect score.
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?
All parameters have descriptions in the schema (100% coverage), so the description adds minimal extra meaning beyond contextualizing them as inputs for the matching network. The baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it designs an L-section matching network, computes inductor and capacitor values, and supports lowpass/highpass topologies. It differentiates from sibling tools like cst_matching_pi_network and cst_matching_t_network by specifying 'L-section' and noting no CST connection.
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 indicates topologies supported but does not explicitly state when to use this versus alternatives like pi, T, or stub networks. However, the sibling list suggests usage for L-network design, and the description is clear enough for an agent to infer context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Calculate microstrip transmission line characteristic impedance from physical dimensions using the Hammerstad-Jensen model with optional Kirschning-Jansen frequency dispersion correction. Pure Python computation.
| Name | Required | Description | Default |
|---|---|---|---|
| width_mm | Yes | Trace width in mm | |
| epsilon_r | Yes | Substrate relative permittivity | |
| height_mm | Yes | Substrate height (dielectric thickness) in mm | |
| thickness_mm | No | Conductor thickness in mm (default 0.035 = 1 oz copper) | |
| frequency_ghz | No | Frequency in GHz for dispersion correction (optional) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses it uses pure Python computation (no CST simulation side effects) and the specific model. However, does not describe the output format (e.g., impedance value in ohms) or any constraints. With no annotations, more detail 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?
Two concise sentences. First sentence covers purpose and model; second adds 'pure Python computation' as a key behavioral indicator. 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?
Missing information about return value (e.g., characteristic impedance in ohms) and error/range conditions. Since there is no output schema, the description should clarify what the tool returns. The tool is simple but incomplete without output details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. Description adds context about the Hammerstad-Jensen model and that frequency_ghz enables dispersion correction, but this is also implicit in the schema description. Adds minimal extra meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool calculates microstrip characteristic impedance using specific models (Hammerstad-Jensen, optional Kirschning-Jansen). Distinct from siblings like cst_analyze_impedance by highlighting pure Python computation, indicating no simulation dependency.
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., simulation-based impedance extraction). No prerequisites or when-not-to-use conditions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Design a Pi-section impedance matching network (C-L-C or L-C-L). Uses two back-to-back L-sections via a virtual resistance for controllable Q factor. Pure Python computation.
| Name | Required | Description | Default |
|---|---|---|---|
| q_factor | No | Desired loaded Q factor. Must be > sqrt(R_large/R_small - 1). If omitted, a default Q is chosen automatically. | |
| z_load_imag | No | Load reactance in ohms (default 0) | |
| z_load_real | Yes | Load resistance in ohms | |
| frequency_ghz | Yes | Design frequency in GHz | |
| z_source_imag | No | Source reactance in ohms (default 0) | |
| z_source_real | Yes | Source resistance in ohms |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
States 'Pure Python computation' but no annotations exist. Does not disclose side effects, output format, or if it modifies any data. Adequate but lacks depth for a computation-heavy 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?
Two sentences with no redundancy. Front-loaded with key purpose and method. Efficiently conveys essence.
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?
Lacks explanation of output (e.g., does it return component values?). Given no output schema, description should cover this. Basic topology info is present but incomplete for practical use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so parameters are already described. The description adds no extra meaning beyond the schema; mentions Q factor but that is also in schema. Baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it designs a Pi-section impedance matching network with specific topologies (C-L-C or L-C-L) and mentions the method (back-to-back L-sections). This is distinct from sibling tools like L-network or T-network.
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 use for controllable Q factor but does not explicitly state when to choose Pi over other matching networks (e.g., L-network or T-network). No exclusions or alternative guidance provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Design a quarter-wave transformer matching network. Supports single and multi-section designs with maximally flat (binomial) or Chebyshev impedance profiles. Pure Python computation.
| Name | Required | Description | Default |
|---|---|---|---|
| design | No | Multi-section design method (default maximally_flat) | maximally_flat |
| z_load | Yes | Load impedance in ohms | |
| z_source | Yes | Source impedance in ohms | |
| num_sections | No | Number of quarter-wave sections (1-4, default 1) | |
| frequency_ghz | Yes | Design center frequency in GHz |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of transparency. It discloses that computation is 'pure Python' (non-simulation based), which is helpful, but does not specify return values, constraints (e.g., frequency range validity), or side effects. More detail 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 very concise: two sentences with no redundant phrases. It front-loads the core purpose, then mentions key features. Every word serves a purpose, earning a high score.
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 no annotations, the description is moderately complete. It covers design capabilities but omits important context such as return value structure (e.g., section impedances, lengths), edge cases (e.g., unmatched loads), or usage in a simulation workflow. For a design tool, this leaves gaps for an AI 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 100% with clear parameter descriptions. The description adds minimal extra meaning beyond referencing 'maximally flat' and 'Chebyshev' (matching design enum) and 'single and multi-section' (matching num_sections). It does not elaborate on parameter semantics beyond what the schema provides, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool's purpose clearly: 'Design a quarter-wave transformer matching network.' It specifies supported features (single/multi-section, maximally flat/Chebyshev) and distinguishes it as a pure Python computation, setting it apart from sibling tools like cst_matching_stub or cst_matching_l_network.
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 quarter-wave transformer design but does not explicitly state when to use it over other matching tools (e.g., stub, L-network). It lacks guidance on prerequisites (e.g., real impedances only) or alternatives, leaving the agent to infer context from the tool name and sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Design a single-stub impedance matching network. Computes the stub length and distance from the load using Smith chart transmission-line matching. Pure Python computation.
| Name | Required | Description | Default |
|---|---|---|---|
| z0 | No | Characteristic impedance in ohms (default 50) | |
| stub_type | No | Stub termination type (default open) | open |
| z_load_imag | No | Load reactance in ohms (default 0) | |
| z_load_real | Yes | Load resistance in ohms | |
| frequency_ghz | Yes | Design frequency in GHz |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses 'Pure Python computation' (no CST interaction) and that it computes stub length and distance, but does not clarify whether results are returned, printed, or applied to a project. More detail on side effects or output method 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?
Three short, focused sentences with no redundancy. The first sentence states the purpose, the second details the computation method, and the third notes the implementation. 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 description omits output specification (units, format) and does not mention any prerequisites or return behavior. Given the 5 parameters and no output schema, the description should provide more details to ensure correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (all parameters documented). The description adds context that outputs are stub length and distance, but does not enhance parameter understanding beyond the schema. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Design a single-stub impedance matching network' and specifies it computes stub length and distance. Differentiates from sibling tools that handle other matching types (L-network, quarter-wave, etc.). The phrase 'Pure Python computation' further clarifies it is a standalone calculation.
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 single-stub matching but does not explicitly state when to use this tool over alternatives like cst_matching_l_network or cst_matching_quarter_wave. No exclusions or when-not-to-use are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Design a T-section impedance matching network (L-C-L). Dual of Pi-network, uses two back-to-back L-sections. Pure Python computation.
| Name | Required | Description | Default |
|---|---|---|---|
| q_factor | No | Desired loaded Q factor. Must be > sqrt(R_large/R_small - 1). If omitted, a default Q is chosen automatically. | |
| z_load_imag | No | Load reactance in ohms (default 0) | |
| z_load_real | Yes | Load resistance in ohms | |
| frequency_ghz | Yes | Design frequency in GHz | |
| z_source_imag | No | Source reactance in ohms (default 0) | |
| z_source_real | Yes | Source resistance in ohms |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. States 'Pure Python computation' indicating no side effects. However, doesn't disclose return format, error handling, or prerequisites.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with key information. 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?
No output schema, but description is adequate for a simple computation tool. However, it doesn't mention return values or integration with CST model, which could be important for the 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 has 100% coverage with descriptions for all 6 parameters. The description adds minimal extra meaning beyond the schema, just mentioning the L-C-L topology.
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 designs a T-section impedance matching network (L-C-L) and distinguishes from Pi-network. Mentions it's pure Python, no simulation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Mentions it's the dual of Pi-network, but doesn't explicitly guide when to choose this over Pi or other matching networks. Lacks when-to-use or when-not-to-use scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Set up a multi-objective optimization with weighted goals and optional constraints. Supports Pareto-front exploration using Genetic Algorithm or Particle Swarm methods.
| Name | Required | Description | Default |
|---|---|---|---|
| goals | Yes | List of optimization goals with weights. | |
| method | No | Optimization method (GA or PSO recommended for multi-objective). | Genetic Algorithm |
| parameters | Yes | ||
| constraints | No | Optional inequality constraints on results. | |
| max_evaluations | 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 core functionality (multi-objective, Pareto front, GA/PSO, optional constraints) but lacks details on side effects, prerequisites (e.g., active project), or return behavior. Does not contradict annotations (none exist).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no unnecessary words. Purpose is front-loaded. Every sentence adds value and earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex tool with no output schema, the description covers key aspects (goals, constraints, methods) but could be more complete by explicitly differentiating from cst_constrained_optimizer and noting that it modifies the project's optimization setup. Still, it provides sufficient context for an agent given the sibling 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 coverage is 60%; the description adds context by mentioning weighted goals and optional constraints, and explains the method parameter (GA/PSO for multi-objective). However, it does not elaborate on the 'parameters' array fields (min, max, name) which lack 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 the tool sets up a multi-objective optimization with weighted goals and constraints, supporting Pareto-front exploration using specific algorithms. It distinguishes from siblings like cst_optimizer (single-objective) and cst_constrained_optimizer (possibly single-objective with constraints).
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 for multi-objective optimization and mentions methods, but does not explicitly state when to use vs alternatives like single-objective optimizers. Context is clear, but no exclusions or 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.
Open an existing CST Studio Suite project. In connected mode the project is opened in the running instance; in offline mode a reference is stored for subsequent operations.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Full file path of the existing .cst project to open. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It explains connected vs offline mode but lacks detail on prerequisites, side effects, or error handling. Beyond schema, it adds mode context but not comprehensive 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?
Two efficient sentences with zero waste. Front-loaded with verb and resource, concise and structured effectively.
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 open operation, the description is fairly complete. It covers modes and parameter. Missing are return value (no output schema) and edge cases, but acceptable for this tool's simplicity.
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 100% with a clear description for the only parameter (path). The tool description adds no additional parameter meaning beyond what the schema provides, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool opens an existing CST Studio Suite project, distinguishing between connected and offline modes. Among siblings, cst_create_project and cst_close_project highlight the distinct 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?
The description implies when to use (opening an existing project) and mentions two modes, but does not explicitly note when not to use or reference alternatives like cst_create_project.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Set up an optimization in CST Studio. Define a goal (minimize, maximize, or target a specific value for a result), specify which parameters to vary with their bounds, and choose an optimization algorithm.
| Name | Required | Description | Default |
|---|---|---|---|
| method | No | Optimization algorithm. | Trust Region |
| goal_type | Yes | Optimization goal type. | |
| goal_value | No | Target value for 'target' goal type. Ignored for minimize/maximize. | |
| parameters | Yes | List of parameters to optimize with their min/max bounds. | |
| result_path | Yes | Result tree path to optimize, e.g. '1D Results\S-Parameters\S1,1' or '1D Results\S-Parameters\S2,1'. | |
| max_evaluations | No | Maximum number of solver evaluations. |
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 says 'set up' which implies configuration, but it is unclear if the tool actually starts the optimization or just prepares it. There is no mention of side effects, required project state, or return values.
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 sentences that front-load the purpose and key actions. Every sentence carries information without 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?
Despite having 6 parameters and no output schema or annotations, the description omits important context: whether the tool runs the optimization or just configures it, what the return value is, and prerequisites like an existing project. This leaves significant gaps for an AI 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?
Input schema has 100% description coverage. The description adds context like 'minimize, maximize, or target a specific value' for goal_type and 'choose an optimization algorithm' for method, but this largely overlaps with the schema descriptions. No additional meaning beyond schema for parameters like goal_value or max_evaluations.
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 up' and the resource 'optimization in CST Studio'. It lists the key actions: define goal, specify parameters, choose algorithm. However, it does not distinguish from sibling optimizer tools like cst_constrained_optimizer or cst_multi_objective_optimizer, which have similar 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 is provided on when to use this tool vs alternatives (e.g., constrained or multi-objective optimizers). There is no mention of prerequisites or context such as needing an open project or defined parameters.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Interpolate results between parameter sweep data points to estimate performance at a specific parameter value without running a new simulation.
| Name | Required | Description | Default |
|---|---|---|---|
| parameter | Yes | Name of the sweep parameter. | |
| result_path | Yes | Result tree path to interpolate. | |
| target_value | Yes | Parameter value at which to interpolate results. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must convey behavioral traits. It states the tool estimates performance via interpolation without running a simulation, which is helpful. However, it omits details like interpolation method, accuracy, or requirements (e.g., sweep data must exist).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core action and purpose. No unnecessary words or repetition.
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 explains the tool's purpose but does not specify what it returns (presumably interpolated results) or preconditions like a completed sweep. While the schema covers parameters, the lack of output schema detail and prerequisites limits 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 100% with descriptions for all three parameters (parameter, result_path, target_value). The description reinforces that interpolation is across sweep data points, adding context but not new parameter-level meaning. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: interpolating results from parameter sweep data to estimate performance at a specific parameter value, avoiding a new simulation. It distinguishes from sibling cst_parameter_sweep by emphasizing the interpolation over sweep execution.
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 a parameter sweep has been run, noting that no new simulation is needed. It provides clear context but lacks explicit when-not-to-use or alternative tools for related tasks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Set up a parameter sweep in CST Studio. The sweep runs the simulation multiple times, varying the specified parameter across a range of values.
| Name | Required | Description | Default |
|---|---|---|---|
| stop | Yes | Stop value of the sweep range. | |
| start | Yes | Start value of the sweep range. | |
| steps | Yes | Number of steps in the sweep (minimum 2). | |
| parameter | Yes | Name of the parameter to sweep. | |
| simulation_type | No | Solver type for the sweep. Defaults to Transient. |
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 sweep runs simulations multiple times, but does not clarify whether it both sets up and executes, whether it modifies project state, or how results are returned. It lacks details on side effects, asynchronous execution, or required prior setup.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core purpose, and contains no redundant information. It is appropriately sized for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool that sets up and runs simulations, the description omits crucial details: whether execution is synchronous, how to retrieve results, and what the output format is. Since no output schema exists, the description should provide more context on return values or side effects.
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 100% with descriptions for each parameter. The tool description adds no significant meaning beyond the schema; it does not explain step type (e.g., linear/logarithmic) or constraints beyond the schema's minimum steps.
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 parameter sweep and runs simulations multiple times. The verb 'set up' and resource 'parameter sweep' are specific. However, it does not differentiate from sibling tools like cst_parameter_interpolation or cst_sensitivity_analysis, which perform related but distinct 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 guidance on when to use this tool versus alternatives, such as cst_parameter_interpolation or cst_sensitivity_analysis. There is no mention of prerequisites (e.g., parameter must exist, project must be open) or context for typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Pause a currently running CST simulation. The simulation can be resumed later with cst_resume_simulation.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must carry full behavioral disclosure. It states the tool is non-destructive and reversible, but lacks details on timing or side effects. Adequate but not thorough.
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 that convey purpose and usage without any wasted words. Front-loaded with the main 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?
Given the tool's simplicity (no parameters, no output schema), the description covers essential context. It could mention return status, but this is minor for such a straightforward 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?
No parameters exist (schema coverage 100%), so the description does not need to add parameter info. Baseline of 4 is appropriate per guidelines.
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 ('Pause a currently running CST simulation') and distinguishes it from siblings by mentioning resumption with cst_resume_simulation, implying it is for temporary halts rather than termination.
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 says to use when simulation is running and provides a sibling for resuming. Does not explicitly describe when not to use, but the context is clear enough for a zero-parameter tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Calculate electromagnetic coupling between parallel PCB traces. Computes even/odd mode impedances, coupling coefficient, and near-end/far-end crosstalk estimates using coupled microstrip formulas. Pure calculation — no VBA or CST geometry is generated.
| Name | Required | Description | Default |
|---|---|---|---|
| epsilon_r | Yes | Substrate relative permittivity | |
| height_mm | Yes | Substrate height to reference plane in mm | |
| frequency_ghz | Yes | Operating frequency in GHz | |
| separation_mm | Yes | Edge-to-edge separation between traces in mm | |
| trace_width_mm | Yes | Width of each trace in mm | |
| coupling_length_mm | Yes | Parallel coupling length in mm |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full behavioral burden. It clearly states it is a pure calculation with no geometry generation, which is helpful. However, it does not disclose whether it modifies project state, requires prior setup, or any side effects. The read-only nature is implied but not explicitly 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 extremely concise: two sentences with no extraneous words. It front-loads the core purpose and adds a clarifying statement about no geometry generation. 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 computes complex quantities but has no output schema, and the description does not specify the format, structure, or units of the return value. For an agent to use this tool correctly, it needs to know what the output looks like. Additionally, prerequisites (e.g., existing PCB stackup or trace definitions) are not mentioned. The description is incomplete for practical use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the input schema already explains all 6 parameters. The description does not add additional parameter-specific meaning or usage tips. Baseline score of 3 is appropriate as the schema handles parameter documentation.
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 tool calculates electromagnetic coupling between parallel PCB traces, lists specific computed quantities (even/odd mode impedances, coupling coefficient, crosstalk), and clarifies it is a pure calculation with no geometry generation. This clearly distinguishes it from sibling tools that create or modify 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 it is used for analytical coupling calculations without creating geometry, but it does not explicitly state when to use this tool versus alternatives like cst_pcb_differential_pair or cst_array_mutual_coupling. No usage exclusions or alternative tool references are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a coplanar waveguide (CPW) to microstrip transition in CST Studio. Generates a tapered geometry that linearly tapers the center conductor width and gap over the transition length. Calculates CPW and microstrip impedances.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Name for the transition structure | |
| layer | Yes | Layer name (e.g. 'Top') | |
| component | No | CST component name | PCB |
| epsilon_r | No | Substrate relative permittivity | |
| height_mm | Yes | Substrate height to reference plane in mm | |
| cpw_gap_mm | Yes | CPW gap width in mm | |
| cpw_width_mm | Yes | CPW center conductor width in mm | |
| transition_type | No | Type of transition | cpw_to_microstrip |
| microstrip_width_mm | Yes | Microstrip trace width at the end of the transition in mm | |
| transition_length_mm | Yes | Length of the tapered transition in mm |
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 generating a tapered geometry and calculating impedances, but does not disclose potential side effects, required permissions, or whether it modifies existing geometry or creates new objects.
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 three sentences long, front-loaded with the main action, followed by taper details and calculation. Every sentence adds value, no unnecessary 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 complexity (10 parameters, transition design), the description covers the purpose and taper mechanism. It does not explain the output (no output schema) or the transition_type enum options, but it reasonably addresses the main behavior. Slightly more detail on output would improve 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?
The input schema has 100% coverage with descriptions for each parameter. The description adds value by explaining that the center conductor width and gap are linearly tapered, directly relating to parameters like cpw_width_mm, cpw_gap_mm, transition_length_mm, and microstrip_width_mm. It also mentions impedance calculation, adding domain 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 the tool creates a CPW-to-microstrip transition with a tapered geometry, specifying the linear taper of center conductor width and gap over transition length, and mentions impedance calculation. It is distinct from siblings like cst_pcb_create_trace which creates generic traces.
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 cst_pcb_create_trace or cst_pcb_differential_pair. It does not mention prerequisites, complementary tools, or suitable scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a ground or power plane with optional cutouts (split planes, isolation slots) in CST Studio. Generates a solid copper brick and subtracts cutout regions.
| Name | Required | Description | Default |
|---|---|---|---|
| layer | Yes | Layer name (e.g. 'GND', 'PWR') | |
| cutouts | No | Optional list of rectangular cutout regions | |
| width_mm | Yes | Plane width in mm (X dimension) | |
| length_mm | Yes | Plane length in mm (Y dimension) | |
| z_position | No | Z position of the plane bottom surface in mm | |
| thickness_mm | No | Copper thickness in mm (default 0.035 for 1oz) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must cover behavioral traits. It explains the construction method (brick minus cutouts) but omits details like whether existing geometry is affected, if the plane is created on a specific layer, or if undo support exists. It carries the burden adequately but not thoroughly.
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 front-load the core action and optional feature, with no filler. Every word 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?
Given 6 parameters with full schema and no output schema, the description is nearly complete. It explains the high-level process (brick + subtraction) and mentions optional cutouts. Lacks any mention of return values, but no output schema exists, so it's not required.
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 100%, so the description's role in adding parameter meaning is minimal. The description adds context like 'split planes' and 'isolation slots' but does not detail individual parameters beyond what the schema already provides. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it creates a ground or power plane with optional cutouts, explaining the mechanism of generating a solid copper brick and subtracting cutout regions. This distinguishes it from sibling tools like cst_pcb_create_trace (creates traces) or cst_create_brick (generic brick).
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 is provided. While the description implies it's for PCB ground/power planes, it does not differentiate from other PCB creation tools (e.g., when to use this vs cst_pcb_create_trace) or mention prerequisites like having a stackup defined.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a PCB layer stackup in CST Studio. Generates brick geometry for each layer (signal, ground, power, dielectric) positioned vertically with correct materials. Returns total thickness and layer positions.
| Name | Required | Description | Default |
|---|---|---|---|
| layers | Yes | Ordered list of layers from top to bottom. Example 4-layer: signal-dielectric-ground-dielectric(core)-power-dielectric-signal | |
| board_width_mm | Yes | Board width in mm (X dimension) | |
| board_length_mm | Yes | Board length in mm (Y dimension) |
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 discloses that it generates brick geometry and positions layers vertically, but does not mention side effects like whether it requires an open project, if it overwrites existing stackups, or how it modifies the project tree. The behavioral disclosure is adequate but incomplete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences with front-loaded purpose. Every sentence adds value with no fluff: the first states the verb-resource, the second details outputs. Perfectly structured.
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 (multi-layer stackup with materials) and the fact that there is no output schema, the description adequately covers inputs (layers array, board dimensions) and outputs (thickness, positions). It could be more complete by mentioning that layers are created as 3D objects in the project tree, but overall it provides sufficient context 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 100% with descriptions for all parameters. The description adds meaningful context beyond the schema by explaining that it generates brick geometry for each layer positioned vertically with correct materials and that it returns total thickness and layer positions. This adds value for an agent selecting parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates a PCB layer stackup, generates brick geometry for each layer, and returns total thickness and layer positions. It distinguishes itself from sibling tools like cst_pcb_create_ground_plane or cst_create_brick by specifying the unique function of layer stackup creation.
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, such as cst_pcb_import_gerber or cst_create_brick. It implies usage for stackup creation but lacks when-not or exclusionary language.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a PCB trace (microstrip, stripline, coplanar waveguide, or grounded CPW) in CST Studio. Optionally calculates trace width from a target impedance using Hammerstad-Jensen (microstrip) or Cohn (stripline) formulas.
| Name | Required | Description | Default |
|---|---|---|---|
| layer | Yes | Layer name where the trace is placed (e.g. 'Top') | |
| x_start | No | X coordinate of trace start (mm) | |
| y_start | No | Y coordinate of trace start (mm) | |
| width_mm | No | Trace width in mm. If impedance_target is specified, this is ignored and the width is calculated automatically. | |
| direction | No | Trace direction: 'x' for +X, 'y' for +Y, or angle in degrees from +X axis (e.g. '45') | x |
| epsilon_r | No | Substrate relative permittivity. Required when impedance_target is given. | |
| length_mm | Yes | Trace length in mm | |
| trace_type | Yes | Type of transmission line | |
| z_position | No | Z position of the trace bottom surface in mm. If omitted, defaults to 0 (top surface of the board). | |
| impedance_target | No | Target characteristic impedance in ohms. When specified, trace width is auto-calculated. Requires substrate_height_mm and epsilon_r. | |
| copper_thickness_mm | No | Copper thickness in mm (default 0.035 for 1oz) | |
| substrate_height_mm | No | Substrate height between trace and reference plane (mm). Required when impedance_target is given. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of behavioral disclosure. It mentions the impedance calculation behavior and required parameters for that, but does not disclose potential side effects, failure modes, or what happens upon creation (e.g., trace appears in model, no return value).
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 only two sentences, front-loading the core action and optional feature. Every word is essential and there is 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 large number of parameters and complete schema coverage, the description is adequate. It covers the main purpose and optional behavior, though it could mention what the tool returns or that the trace is added to the project.
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 100%, so all parameters are documented in the schema. The description adds some context by naming the formulas used for width calculation, but overall it does not significantly enhance understanding 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 creates a PCB trace and lists the specific types (microstrip, stripline, coplanar waveguide, grounded CPW). It also mentions the optional impedance-based width calculation, distinguishing it from other PCB creation tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide explicit guidance on when to use this tool versus alternatives. While it mentions optional features, it lacks context on prerequisites or scenarios where other tools might be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a PCB via (through, blind, or buried) in CST Studio. Generates the cylindrical via barrel with specified drill and pad dimensions. Pad and antipad diameters are validated and reported but the geometry covers the barrel only; add pads separately if needed.
| Name | Required | Description | Default |
|---|---|---|---|
| x | Yes | Via X position in mm | |
| y | Yes | Via Y position in mm | |
| name | No | Via name for the CST model (auto-generated if omitted) | |
| end_z | Yes | Z coordinate of the via end (bottom) in mm | |
| start_z | Yes | Z coordinate of the via start (top) in mm | |
| via_type | No | Via type | through |
| end_layer | Yes | Name of the ending layer (e.g. 'Bottom') | |
| start_layer | Yes | Name of the starting layer (e.g. 'Top') | |
| pad_diameter_mm | No | Annular pad diameter in mm | |
| drill_diameter_mm | No | Drill hole diameter in mm | |
| antipad_diameter_mm | No | Antipad (clearance) diameter in plane layers in mm |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description discloses key behavioral traits: only barrel geometry is created, pads added separately, and pad/antipad dimensions are validated and reported. This provides useful context beyond the tool name.
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 three sentences, each adding value. Front-loaded with the main 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?
For a tool with 11 parameters and no output schema, the description explains core behavior and limitations but omits return values or error conditions. Adequate but not fully 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?
Schema coverage is 100%, but the description adds context that pad and antipad diameters are validated but only the barrel is generated. This explains behavior beyond raw parameter descriptions, justifying above baseline.
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 creates a PCB via (through, blind, buried) and generates the barrel. It distinguishes from sibling tools like traces and ground planes by specifying via creation, though it does not explicitly differentiate from other via-related 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?
No explicit guidance on when to use this tool versus alternatives. The description implies use for via creation but lacks when-not or alternative recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a differential pair of PCB traces in CST Studio. Generates two parallel bricks separated by a gap and calculates the differential impedance using coupled-line theory (Zdiff = 2Z0(1-k)).
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Base name for the differential pair (e.g. 'USB_DP') | |
| layer | Yes | Layer name (e.g. 'Top') | |
| gap_mm | Yes | Gap between the two traces in mm | |
| x_start | No | X coordinate of the pair center start in mm | |
| y_start | No | Y coordinate of the pair center start in mm | |
| component | No | CST component name | PCB |
| epsilon_r | No | Substrate relative permittivity | |
| height_mm | No | Substrate height to reference plane in mm | |
| length_mm | Yes | Trace length in mm | |
| trace_width_mm | Yes | Width of each trace in mm | |
| target_impedance_diff | No | Target differential impedance in ohms |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses the creation and calculation behavior, but lacks details on side effects, required project state, destructiveness, or whether it modifies existing objects. Important traits like creating geometry in the active CST project are not mentioned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences. The first sentence clearly states the main purpose, and the second adds relevant technical context. No superfluous content.
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 (11 parameters, no output schema) and the presence of many sibling tools, the description is insufficient. It does not explain what the tool returns (e.g., the impedance value or just geometry), nor does it mention any prerequisites like an open project or required prior steps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with each parameter already described in the schema. The tool description does not add additional meaning beyond listing the parameters indirectly via the formula. Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates a differential pair of PCB traces, specifies the geometry (two parallel bricks separated by a gap), and mentions the impedance calculation. This distinguishes it from sibling tools like cst_pcb_create_trace (single trace) and other PCB structures.
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 a differential pair is needed, but does not explicitly state when to use this tool versus alternatives (e.g., single trace creation or other matching tools). No guidance on prerequisites or scenarios where this tool is not appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Import a Gerber/ODB++/DXF file for PCB analysis in CST Studio. Generates VBA for the CST Gerber import wizard. In offline mode, explains the import process and required settings.
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | Yes | Path to the Gerber file (.gbr, .ger, .gtl, .gbl, etc.) | |
| file_type | No | Import file format | gerber |
| layer_name | Yes | Target layer name in the CST model |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It adds some behavioral details (generates VBA, explains process in offline mode), but does not disclose important aspects like whether the operation is synchronous, if it modifies the project, error handling, or permissions required.
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, front-loaded with the primary purpose. No wasted words; efficient and clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the main functionality but could be more complete given the complexity of PCB import. Mentions VBA generation and offline mode, but lacks details on prerequisites, workflow, or what the VBA does.
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 100%, so the schema already describes all parameters. The description does not add meaning beyond what the schema provides (file types, layer name), so baseline 3 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?
The description clearly states the action (import), the resources (Gerber/ODB++/DXF files for PCB analysis), and distinguishes from siblings like cst_import_cad and cst_import_touchstone by specifying the file types and mentioning VBA generation and offline mode.
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., cst_import_cad, cst_import_touchstone). The mention of 'offline mode' is ambiguous and does not clarify usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List predefined PCB stackup templates with complete layer definitions. Includes standard 2/4/6-layer FR-4 and RF-grade Rogers stackups. Use the returned layer data directly with cst_pcb_create_stackup.
| Name | Required | Description | Default |
|---|---|---|---|
| filter | No | Optional filter string to match template names (e.g. '4-layer', 'Rogers', 'RF'). Case-insensitive. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It describes the tool as listing templates without side effects, but it does not mention prerequisites, performance, or whether the operation is read-only. The description is adequate for a simple retrieval but lacks deeper 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 two sentences long, front-loads the core purpose, and contains no redundant information. Every sentence 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?
The description mentions that returned data includes complete layer definitions and can be used with another tool, but with no output schema, it lacks details on the structure of the returned data. This is sufficient for a simple listing but 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 100% coverage for the single parameter 'filter', but the description adds value by providing concrete examples ('4-layer', 'Rogers', 'RF') and stating case-insensitivity, which aids correct invocation.
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 lists predefined PCB stackup templates with complete layer definitions and specifies the types (standard 2/4/6-layer FR-4 and RF-grade Rogers). It also mentions that the returned data can be used directly with cst_pcb_create_stackup, distinguishing it from other tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells the agent to use the returned layer data with cst_pcb_create_stackup, providing clear context for when to use this tool. However, it does not explicitly state when not to use it or mention alternatives, which is a minor gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a Substrate Integrated Waveguide (SIW) in CST Studio. Generates top and bottom copper planes with two rows of via fences forming the waveguide sidewalls. Calculates effective width, cutoff frequency, and guided wavelength using Cassivi et al. formulas.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Name for the SIW structure | |
| layer | Yes | Layer name (e.g. 'Top') | |
| x_start | No | X coordinate of the SIW start in mm | |
| y_start | No | Y coordinate of the SIW start in mm | |
| width_mm | Yes | SIW width (center-to-center of via rows) in mm | |
| component | No | CST component name | PCB |
| epsilon_r | No | Substrate relative permittivity | |
| height_mm | No | Substrate height in mm | |
| length_mm | Yes | SIW length in mm | |
| via_pitch_mm | Yes | Center-to-center via spacing along the length in mm | |
| via_diameter_mm | Yes | Via drill diameter in mm |
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 the structure generated and formulas used but does not describe side effects, permissions required, or whether the tool modifies existing objects. The description is insufficiently transparent for a complex creation 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 concise with two sentences: the first states the primary action, and the second provides key technical details. It is front-loaded and uses efficient language, though it could be slightly more structured without adding 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?
Given the tool has 11 parameters, no output schema, and no annotations, the description should provide more context. It lacks details on how the tool integrates with other CST processes, what it returns, or any assumptions about the simulation environment. This makes it incomplete for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with all parameters described, so the baseline is 3. The description adds minimal additional meaning beyond the schema, only noting that width is center-to-center and mentioning Cassivi formulas. It does not explain parameter relationships or provide deeper context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates a Substrate Integrated Waveguide (SIW) in CST Studio, with specific details about generating copper planes and via fences. This distinctly differentiates it from sibling tools like cst_pcb_create_trace or cst_pcb_via_fence, which serve 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?
The description implies usage for SIW creation but provides no explicit guidance on when to use this tool versus alternatives, nor does it mention prerequisites or limitations. For a domain-specific tool, the context is clear but lacks exclusions or comparison.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a row (or multiple rows) of vias along a path for isolation or Substrate Integrated Waveguide (SIW) construction. Generates an array of cylinders from start to end point with specified spacing.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Base name for the via fence | |
| rows | No | Number of parallel rows (1-3) | |
| x_end | Yes | X coordinate of the fence end in mm | |
| y_end | Yes | Y coordinate of the fence end in mm | |
| x_start | Yes | X coordinate of the fence start in mm | |
| y_start | Yes | Y coordinate of the fence start in mm | |
| component | No | CST component name | PCB |
| row_offset_mm | No | Lateral offset between rows for staggering in mm | |
| via_spacing_mm | Yes | Center-to-center spacing between vias in mm | |
| pad_diameter_mm | Yes | Via pad diameter in mm | |
| via_diameter_mm | Yes | Via drill diameter in mm |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It states it generates cylinders along a path, but lacks details on side effects, prerequisites, error handling, or impact on existing geometry. Basic behavior is covered but not deeply.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, short and front-loaded. Some redundancy between sentences (both mention arrays of vias), 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?
Given 11 parameters and no output schema, the description provides basic purpose and method but lacks usage guidance, behavioral constraints, and output details. Adequate for simple usage but incomplete for novice users.
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 100%, so baseline is 3. The description adds context about multiple rows and staggering, which are already in schema descriptions. No significant extra meaning 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?
The description clearly states the tool creates a row of vias for isolation or SIW construction, with specific verb and resource. It distinguishes from sibling tools like cst_pcb_create_via which creates single vias, and other PCB geometry tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions use cases (isolation, SIW) but does not explicitly state when to prefer this over alternatives or provide exclusion criteria. No direct comparison with 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.
Create a detailed PCB via model in CST Studio with parasitic inductance and capacitance estimates. Uses the Goldfarb model for via inductance and a simplified capacitance formula.
| Name | Required | Description | Default |
|---|---|---|---|
| x | Yes | Via X position in mm | |
| y | Yes | Via Y position in mm | |
| name | Yes | Via name for the CST model | |
| component | No | CST component name | PCB |
| end_layer | Yes | Name of the ending (bottom) layer | |
| epsilon_r | No | Substrate relative permittivity | |
| start_layer | Yes | Name of the starting (top) layer | |
| pad_diameter_mm | Yes | Annular pad diameter in mm | |
| barrel_plating_um | No | Barrel plating thickness in micrometers | |
| drill_diameter_mm | Yes | Drill hole diameter in mm | |
| board_thickness_mm | No | Board thickness in mm | |
| antipad_diameter_mm | Yes | Antipad (clearance) diameter in mm |
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 creating a model and estimating parasitics but omits side effects, prerequisites (e.g., existing stackup), whether it modifies existing models, and return values.
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 two sentences, no wasted words, and effectively communicates the core purpose and methodology.
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 has 12 parameters and no output schema, yet the description lacks information on return values, prerequisites, side effects, or how the model is integrated. This makes it incomplete for an agent to use confidently.
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 100%, so the baseline is 3. The description adds context about the models used but does not significantly augment the parameter meanings beyond the 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 creates a detailed PCB via model with parasitic estimates, specifying the Goldfarb model for inductance and a simplified capacitance formula. This distinguishes it from sibling tools like cst_pcb_create_via which likely only create 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 for detailed modeling with parasitics but does not explicitly state when to use this tool versus alternatives like cst_pcb_create_via. No when-to-use or when-not-to-use 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 information about the currently open CST project, including connection mode, project path, 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 carries the full burden. It implies read-only behavior ('Get information') but does not explicitly state that no modifications are made, nor does it describe error handling (e.g., what happens if no project is open) 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 a single sentence of 16 words, directly stating the purpose. It is front-loaded with the key action and resource, avoiding 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 the lack of output schema and annotations, the description provides a reasonable list of output fields (connection mode, project path, status). However, it does not describe the return format (e.g., JSON structure) or potential error conditions. For a simple getter, this is mostly sufficient but could be slightly more 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 tool has no parameters, so there is no need for the description to add meaning beyond the input schema. Schema coverage is 100% trivially, and the description appropriately omits param details.
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 information about the currently open CST project, specifying the exact pieces of info (connection mode, project path, status). This distinguishes it from siblings like cst_connection_status or cst_get_simulation_status which focus on specific aspects.
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 explicitly provide guidance on when to use this tool versus alternative siblngs. While it's clear that this is for general project info, it lacks indications such as 'Use this for an overview; for specific status details, use cst_get_simulation_status'. No when-not-to-use 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.
List items in the CST project navigation tree. Optionally specify a subtree path such as 'Components', 'Materials', 'Ports', 'Monitors', or 'Results'.
| Name | Required | Description | Default |
|---|---|---|---|
| tree_path | No | Navigation tree path to list, e.g. 'Components', 'Results', or '2D/3D Results'. Omit for the root tree. |
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. It states the tool lists items but does not mention expected behavior for invalid paths, whether the list is flat or hierarchical, or any side effects (likely none). The minimal disclosure leaves significant behavioral aspects unclear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no unnecessary words. It efficiently conveys the tool's function and optional parameter, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has one optional parameter, no output schema, and many siblings, the description adequately covers the main purpose and provides concrete path examples. It is complete enough for a simple listing tool but could mention that the output is a list of sub-items (e.g., names) and behavior for non-existent paths.
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 100% as the single parameter 'tree_path' has a description. The description adds example values (e.g., 'Components', 'Materials') which are helpful but largely redundant with the schema description. The baseline of 3 is appropriate as the description provides marginal added value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists items in the CST project navigation tree with a specific verb ('List') and resource. It provides example subtree paths, distinguishing it from siblings that focus on specific item types (e.g., ports, materials) or actions (e.g., creating simulations). However, it could be more precise about the scope (e.g., 'contents of the entire tree').
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 exploring the project tree by offering an optional subtree path. It gives examples of valid paths but lacks explicit guidance on when to use this tool versus alternative listing tools like cst_list_materials or cst_list_ports, and no when-not-to-use scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read solver log files and project status information from the current CST project. Returns solver running state and the contents of the most recent log file. Useful for diagnosing solver errors, checking simulation progress, and understanding what happened during a failed run.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description bears the full burden of behavioral disclosure. It states that the tool returns solver running state and log file contents, but does not address edge cases, authentication requirements, or potential side effects. Given it is a read-only operation, the description is adequate 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, consisting of two clear sentences that provide essential information without redundancy. Every sentence adds value: the first defines the action, the second explains utility.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read tool with no parameters and no output schema, the description fully covers what the tool does, what it returns, and its typical use cases. It mentions both the running state and log file contents, which is sufficient for an agent to understand the tool's functionality.
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 zero parameters, so there is no parameter information to add beyond what the schema provides. According to guidelines, this merits a baseline score of 4, and the description appropriately does not attempt to describe nonexistent parameters.
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 reads solver log files and project status information from the current CST project, specifying it returns solver running state and the most recent log file contents. This distinctively differentiates it from sibling tools like cst_get_solver_info or cst_get_simulation_status, which may return different data.
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 suggests it is useful for diagnosing solver errors and checking simulation progress, implying when to use it. However, it does not provide explicit guidance on when not to use it or contrast it with similar tools such as cst_get_solver_info or cst_get_result_summary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run an automated Nelder-Mead optimization loop to tune CST design parameters toward VSWR goals across specified frequency bands. Each iteration sets parameters, runs the solver, exports S11, and evaluates against targets. Uses silent VBA execution to avoid history bloat. Applies the best parameters permanently at the end. Connected mode only — requires a live CST session with a solvable project.
| Name | Required | Description | Default |
|---|---|---|---|
| port | No | Port number (default: 1). | |
| bands | Yes | Frequency bands with VSWR targets. | |
| parameters | Yes | Parameters to optimize with initial values and bounds. | |
| max_iterations | No | Maximum optimization iterations (default: 20). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden and does well: it discloses the use of Nelder-Mead, each iteration's steps (set parameters, run solver, export S11, evaluate), silent VBA execution to avoid history bloat, permanent application of best parameters, and connectivity requirement. Missing details on failure handling (e.g., optimization failure, state reversion) prevent a higher score.
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 at 5 sentences, each sentence adds value, and the most important information (purpose) is front-loaded. No unnecessary words or repetition.
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 (4 parameters, nested objects, no output schema), the description covers the optimization process, silent execution, permanent update, and connectivity requirement. However, it does not describe what the tool returns (e.g., optimized parameters, success status), which is needed since no output schema exists. This gap prevents a score of 5.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds no new information about parameters beyond what the schema provides. It explains the overall process but does not detail how each parameter (port, bands, parameters, max_iterations) affects the optimization, nor does it provide usage examples 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 runs a Nelder-Mead optimization loop to tune CST design parameters toward VSWR goals across specified frequency bands. It specifies the verb ('run'), resource ('CST design parameters'), and goal ('VSWR goals'), and distinguishes itself from sibling tools like cst_optimizer by being specialized for antenna VSWR tuning.
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 mentions the prerequisite of 'Connected mode only — requires a live CST session with a solvable project,' providing clear context on when the tool can be used. However, it does not provide guidance on when to prefer this tool over other optimizers (e.g., cst_optimizer) or when not to use it, which is a minor gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Resume a previously paused CST simulation. Use after cst_pause_simulation to continue from where it stopped.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description carries full burden. States it resumes and continues from where it stopped. Does not disclose error states or prerequisites, 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?
Two sentences, front-loaded with purpose, then usage guideline. No unnecessary words. Highly concise and well-structured.
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, no output schema, and simple behavior, the description is fully complete. It covers intent, prerequisites, and context among siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, and schema coverage is 100%. Baseline for 0 parameters is 4. Description adds no param info, but none 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 description clearly states 'Resume a previously paused CST simulation', specifying the verb 'resume' and resource 'CST simulation'. It distinguishes from siblings by referencing cst_pause_simulation and implying a 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?
Explicitly says 'Use after cst_pause_simulation', providing clear context. Lacks mention of when not to use (e.g., for non-paused simulations) and alternatives like cst_run_simulation for fresh starts, but adequate for a simple tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Start a CST simulation with the current solver settings. This is a blocking call that waits for the simulation to complete. Use cst_run_simulation_async for long-running simulations.
| Name | Required | Description | Default |
|---|---|---|---|
| solver_type | No | Solver type to use. If omitted, the currently configured solver is used. Options: 'Time Domain', 'Frequency Domain', 'Eigenmode', 'Integral Equation'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses key behavior (blocking call that waits for completion) without annotations. Could mention error handling or return value, but is still effective.
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. Front-loaded with key 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?
Explains blocking behavior and directs to async for long runs. Lacks return value or error details but sufficient for launch 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 100%, and the description does not add meaning beyond the schema. 'With the current solver settings' is implied. Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Start a CST simulation') and its blocking nature, distinguishing it from the async sibling. It uses a specific verb and resource.
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 advises using the async variant for long-running simulations, providing clear when-to-use and 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.
Start a CST simulation asynchronously (non-blocking). The simulation launches and control returns immediately. Use cst_get_simulation_status to monitor progress.
| Name | Required | Description | Default |
|---|---|---|---|
| solver_type | No | Solver type to use. If omitted, the currently configured solver is used. Options: 'Time Domain', 'Frequency Domain', 'Eigenmode', 'Integral Equation'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It accurately describes asynchronous behavior (non-blocking, immediate return). However, it lacks details about background execution limits, resource consumption, or potential error states. For a simulation launch, this is minimally adequate but not rich.
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 extremely concise with two front-loaded sentences. No unnecessary words, and every sentence adds value (action, behavior, next steps). Fully 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?
Despite good purpose and guidelines, the description omits critical context: there is no output schema, but the tool likely returns a job identifier or status handle needed for monitoring via cst_get_simulation_status. It also does not mention prerequisites (e.g., project must be open, mesh must be set). This leaves the agent guessing about return value and required prior state.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a detailed description for solver_type (enum, optional, default behavior). The tool description adds no extra semantics beyond what the schema already provides. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it starts a CST simulation asynchronously, with a specific verb (start) and resource (CST simulation). It distinguishes from synchronous sibling cst_run_simulation by emphasizing non-blocking behavior, and references cst_get_simulation_status for monitoring, which differentiates other similar 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?
Description explicitly states asynchronous nature and immediate return, telling the agent when to use it (for non-blocking). It also directs to cst_get_simulation_status for progress monitoring, implying the alternative. However, it does not explicitly state when not to use or list prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Save the currently open CST project. Optionally provide a new path to 'Save As'.
| Name | Required | Description | Default |
|---|---|---|---|
| path | No | Optional file path for 'Save As'. If omitted, saves to the current project path. |
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. It fails to mention whether overwriting occurs without confirmation, if the project must have a current path for normal saves, or any side effects like updating internal state. Basic save operation details 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?
Two sentences with the verb and resource front-loaded. Every word is functional; no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool with no output schema, the description covers the essential scenario. It could be improved by noting return behavior (e.g., throws on failure), but overall it is complete enough for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 100% of parameters, so baseline is 3. The description adds value by explaining that omitting 'path' uses the current project path, which clarifies the parameter's behavior beyond the schema's type/description 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?
The description clearly states the action ('Save') and the resource ('the currently open CST project') with specific differentiation for 'Save As' via optional path. This distinguishes it from siblings like cst_open_project or cst_export_project.
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 implicitly indicates usage when the current project needs saving or saving to a new location. However, it does not explicitly exclude use cases like closing without saving or exporting to other formats, leaving some ambiguity among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Call any public method on a project.schematic object. This is the generic bridge for CST schematic RemoteObjects: it invokes project.schematic..(*args, **kwargs). Use the specialized tools for common RLC/port/net operations when possible.
| Name | Required | Description | Default |
|---|---|---|---|
| args | No | Positional arguments passed to the CST method. | |
| kwargs | No | Keyword arguments passed to the CST method. | |
| method_name | Yes | Public method name to call on the object. | |
| object_name | Yes | Schematic object name, e.g. Block, Net, or SimulationTask. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not detail potential side effects, permission requirements, or error handling. The generic nature implies variable behavior, but more warnings about misuse would enhance 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 no wasted words. The purpose is front-loaded, and the usage guideline is clearly stated.
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 generic nature and absence of output schema, the description provides a reasonable overview. However, it lacks details on return values or potential errors, which could be useful for a generic bridge 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 coverage is 100%, but the description adds value by explaining object_name and method_name with examples (e.g., Block, Net, SimulationTask) and clarifying args/kwargs. This goes 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 calls any public method on a project.schematic object, using a generic bridge syntax. It explicitly distinguishes itself from specialized tools for common 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?
Explicitly advises to use specialized tools for common RLC/port/net operations when possible, providing clear guidance on when to prefer this tool vs alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Connect Design Studio schematic component ports into one net. Ports are entries such as {'component_type':'Block','name':'R1','port_index':1}.
| Name | Required | Description | Default |
|---|---|---|---|
| ports | Yes | ||
| net_name | Yes | Final schematic net name. | |
| show_label | No | Show the net-name label on the schematic. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since annotations are absent, the description must convey behavioral traits. It states that ports are connected into a net but does not disclose side effects (e.g., overwriting existing nets), permissions required, or error conditions. This leaves ambiguity for the agent about safe usage.
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 two sentences: one for purpose and one for example. No extraneous information. It is front-loaded with the action, making it 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?
The tool has moderate complexity with 3 parameters and no output schema. The description covers the core function and provides an example, but lacks details on return values, error handling, or behavioral constraints. It is adequate but not fully complete for a scheduling 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 already describes all parameters with clear descriptions. The description adds an example of port structure, which aids understanding but does not significantly enhance parameter semantics beyond the schema. Schema description coverage is high, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Connect Design Studio schematic component ports into one net') and provides an example of port entries. It effectively communicates the tool's purpose, though it does not explicitly differentiate from sibling tools like cst_schematic_call. However, the verb 'connect' and resource 'ports into one net' make the intent clear.
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., cst_schematic_create_external_port). There are no prerequisites, conditions, or exclusions stated. The description implies usage context but lacks explicit guidelines.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a Design Studio schematic external port. Connected mode calls project.schematic.ExternalPort directly; offline mode returns VBA.
| Name | Required | Description | Default |
|---|---|---|---|
| x | No | Schematic X position. | |
| y | No | Schematic Y position. | |
| name | Yes | External port name. | |
| label | No | Optional schematic label. | |
| number | No | Optional port number. | |
| impedance | No | Optional port impedance in Ohm or a CST expression. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description partially explains behavior by mentioning two modes (connected calls directly, offline returns VBA). However, it lacks details on side effects, prerequisites, or the nature of the VBA script.
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, no superfluous information, and is front-loaded with the main 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?
Given no output schema and no annotations, the description is incomplete. It does not explain what the tool returns, error conditions, or how the VBA output is used. For a tool with 6 parameters, 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?
Schema coverage is 100%, so the schema already describes parameters. The description adds no extra semantic meaning or usage hints for parameters like impedance or label.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates a schematic external port and distinguishes between connected and offline modes. The name is specific, and while no explicit sibling differentiation is given, the tool's purpose is clear.
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 cst_add_waveguide_port. The description does not provide context for selecting this port type over other port-related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a Design Studio schematic resistor, inductor, or capacitor. Connected mode calls project.schematic.Block directly; offline mode returns equivalent Design Studio VBA.
| Name | Required | Description | Default |
|---|---|---|---|
| x | No | Schematic X position. | |
| y | No | Schematic Y position. | |
| kind | Yes | Component kind: resistor, inductor, or capacitor. | |
| name | Yes | Schematic block name. | |
| value | Yes | Component value or CST parameter expression. | |
| rotation | No | Optional schematic rotation angle in degrees. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description mentions connected vs. offline modes but lacks details on side effects, prerequisites (e.g., open project), or error handling. Minimal behavioral context beyond mode descriptions.
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 two sentences front-loading purpose and key modes. 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?
No output schema; description does not explain return values or success/failure indicators. Missing prerequisites like project state. Adequate for a simple creation tool but 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?
Schema coverage is 100%, so each parameter has a description. The tool description reinforces the 'kind' parameter but adds no new semantics beyond what's 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 tool creates a resistor, inductor, or capacitor in a Design Studio schematic. It differentiates from sibling tools like ports or antennas by specifying the RLC component.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions two modes (connected/offline) but does not provide explicit guidance on when to use this tool versus other schematic creation tools. Implied usage for RLC creation, but no when-not or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List Design Studio schematic blocks and nets from the active CST project. Requires connected mode.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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. It only states that the tool lists and requires connected mode, omitting details like read-only nature, return format, side effects, or permissions needed.
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 only two sentences, no redundant words, and front-loaded with the key action and resource. Every part 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 simplicity of the tool (no parameters, no output schema), the description provides the essential purpose and a requirement. However, it lacks details about the return format or error conditions, which would help an agent use the tool more confidently.
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 schema coverage is 100% (trivially). Per guidelines, with no parameters, the baseline is 4; the description does not need to add parameter detail beyond what the empty schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (list) and the resource (schematic blocks and nets) from the active project. However, it does not explicitly differentiate itself from sibling tools like cst_schematic_list_objects, which may also list schematic elements.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions a prerequisite (requires connected mode) but provides no guidance on when to use this tool versus alternatives such as cst_schematic_list_objects or other schematic tools. No when-not-to-use or alternative suggestions are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List public members exposed by project.schematic. Use this to discover CST Design Studio schematic objects such as Block, Net, ExternalPort, SimulationTask, Optimizer, and their method counts.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the full burden for behavioral traits. It mentions that the tool lists objects and their method counts, implying a read-only operation. However, it does not explicitly state that the tool is non-destructive or require no authentication, nor does it describe the output structure beyond examples. A slight improvement would clarify that it only retrieves metadata.
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 only two sentences, with no superfluous words. It front-loads the action and resource, followed by examples and a note on method counts. Every sentence 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's simplicity (no parameters, no output schema), the description provides sufficient context: what it lists and why to use it. The examples help the agent understand the type of data returned. However, without an output schema, the description could elaborate on the exact format of returned objects (e.g., list of names and numerical counts) to be fully 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 tool has no parameters, and schema description coverage is 100% (empty schema). The description does not add parameter information because none exists. Baseline score of 4 is appropriate as the description adds no unnecessary details and the absence of parameters is clear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and clearly identifies the resource ('public members exposed by project.schematic'). It provides concrete examples of objects (Block, Net, ExternalPort, etc.) and mentions 'method counts,' which precisely defines the tool's scope and distinguishes it from siblings like cst_schematic_list or cst_schematic_object_methods.
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 states 'Use this to discover CST Design Studio schematic objects' which gives clear context for when to employ this tool. However, it does not provide exclusions or mention when not to use it (e.g., if you need detailed object methods, use cst_schematic_object_methods instead).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List public methods for one project.schematic object, for example Block, Net, ExternalPort, SchematicLayout, SimulationTask, or Optimizer.
| Name | Required | Description | Default |
|---|---|---|---|
| object_name | Yes | Schematic object name, e.g. Block or Net. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the action (list methods) without revealing traits like whether it's read-only, if it requires an active project, or the format of the output. The lack of side-effect or output information leaves the agent underinformed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that conveys the purpose and includes relevant examples. It is front-loaded with the key action and resource, with zero redundant words. Every element earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple, single-parameter tool with no output schema, the description covers the core purpose and gives sufficient context via examples. The only minor gap is the lack of specification about the output format (e.g., array of method names), but the tool's simplicity mitigates this.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with one parameter that already describes its meaning as 'Schematic object name, e.g. Block or Net.' The description adds similar information with more examples but does not provide additional semantic nuance or formatting details beyond the schema. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists public methods for a specific schematic object, with concrete examples like Block, Net, ExternalPort, etc. The verb 'List' and resource 'public methods for one project.schematic object' are specific and distinct from sibling tools such as 'cst_schematic_list_objects' which lists objects, not methods.
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 context by stating it's for 'one project.schematic object' and gives examples, but it does not explicitly state when to use this tool versus alternatives or mention any prerequisites like an open project. The guidance is implied but not comprehensive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Set up a one-at-a-time sensitivity analysis to rank parameters by their impact on a result. Varies each parameter individually while keeping others at nominal values.
| Name | Required | Description | Default |
|---|---|---|---|
| parameters | Yes | ||
| result_path | Yes | Result tree path to monitor. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full burden. It only says 'set up', which suggests configuration but not execution, and does not disclose side effects, return values, or whether it runs a simulation. This is insufficient 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?
Two efficient sentences with no wasted words. The key information is front-loaded and actionable.
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?
Without an output schema, the description should hint at return values or whether the analysis is executed. It lacks details on what happens after setup (e.g., ranking, simulation trigger). Given the tool's complexity (array parameters, analysis setup), the description is incomplete.
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 that parameters are varied individually and result_path is the monitored result. It contextualizes the nominal and perturbation fields, although the schema already partially describes result_path and perturbation_pct.
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 sets up a one-at-a-time sensitivity analysis to rank parameter impact, with a specific method (varying each individually). The name and sibling tools make the purpose distinct from sweeps or optimization.
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 sensitivity analysis but does not specify when to use this versus alternatives like cst_parameter_sweep or cst_optimizer. No exclusions or 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.
Configure adaptive mesh refinement. When enabled, the solver runs multiple passes, refining the mesh in regions of high field gradient until the result converges within the specified threshold.
| Name | Required | Description | Default |
|---|---|---|---|
| enabled | No | Enable or disable adaptive meshing (default true) | |
| threshold | No | Convergence threshold in dB — stop when S-parameter change is below this (default 0.02) | |
| max_passes | No | Maximum number of adaptive mesh refinement passes (default 3) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description explains that the solver runs multiple passes, refines in high-gradient regions, and converges within threshold. However, it does not mention that it stops after max_passes even if not converged, which is a key behavior. With no annotations, this is a notable 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?
Two sentences: first states purpose, second explains the mechanism. Every word earns its place. 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?
For a configuration tool with 3 optional parameters and no output schema, the description covers the core functionality. Lacking context of its role in the simulation setup sequence is a minor gap, 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?
Schema coverage is 100%, so baseline is 3. The description adds minimal semantic value beyond the parameter descriptions, only framing the behavior with 'when enabled'. No additional context for each 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 the tool configures adaptive mesh refinement, a specific and distinct function among siblings. The verb 'configure' and resource 'adaptive mesh refinement' are precise. No tautology.
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 adaptive refinement is desired but does not explicitly state when to use this tool versus alternatives like cst_add_mesh_refinement or cst_set_mesh_type. No 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 background material properties of the simulation domain. The background fills all space not occupied by defined solids.
| Name | Required | Description | Default |
|---|---|---|---|
| mu | No | Relative permeability (default 1.0, used when material is Normal) | |
| epsilon | No | Relative permittivity (default 1.0, used when material is Normal) | |
| material | No | Background material type (default Normal) | Normal |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It does not mention whether calling the tool overwrites existing settings, requires specific permissions, or has any side effects. This is inadequate for a tool that modifies simulation 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?
Two sentences, no fluff, front-loaded with the action. Every word serves a 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 the tool has 3 parameters and no output schema, the description is minimal but covers the basic purpose. It lacks details on parameter dependencies (e.g., when mu/epsilon are used) and the effect of omitting parameters (defaults).
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 100%, so the description adds no extra meaning to parameters beyond what is already in the schema (mu, epsilon, material with defaults and enums). The description does not clarify how parameters interact (e.g., mu/epsilon ignored for PEC/PMC).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Set the background material properties') and the scope ('fills all space not occupied by defined solids'), which distinguishes it from sibling tools that deal with material assignment to objects.
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 cst_create_material or cst_assign_material. The description implies it is used before defining solids, but does not state exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Set boundary conditions for the simulation domain. Each face of the bounding box can be assigned an independent boundary type (open, electric, magnetic, periodic, etc.).
| Name | Required | Description | Default |
|---|---|---|---|
| x_max | Yes | Boundary condition on the +X face | |
| x_min | Yes | Boundary condition on the -X face | |
| y_max | Yes | Boundary condition on the +Y face | |
| y_min | Yes | Boundary condition on the -Y face | |
| z_max | Yes | Boundary condition on the +Z face | |
| z_min | Yes | Boundary condition on the -Z face |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the full burden. It mentions independent boundary types per face, but does not disclose that this overrides previous settings, require an existing simulation domain, or any side effects. Adequate but not thorough.
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: the first states the core purpose, the second expands on the parameter semantics. Each sentence earns its place with 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?
The description covers the basic purpose and parameter independence, but does not explain the meaning of boundary types (e.g., open vs expanded open) or any broader simulation context. No output schema exists, so return values are unaddressed. Adequate for a moderately complex 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 coverage is 100% with enum values and descriptions for all 6 parameters. The description reiterates the enum values ('open, electric, magnetic, periodic') but adds the context that each face is independent. This adds modest value beyond the schema, achieving the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Set boundary conditions for the simulation domain' with a specific verb and resource. It also mentions that each face can have an independent boundary type. Although it does not explicitly differentiate from sibling tools like 'cst_set_periodic_boundary', the domain-wide scope is evident.
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 compared to alternatives (e.g., cst_set_periodic_boundary for periodic boundaries only). No prerequisites or exclusions are mentioned, leaving the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Configure advanced Floquet port settings for periodic structures. Controls the number of Floquet modes and scan angle for phased array element simulation and oblique incidence analysis.
| Name | Required | Description | Default |
|---|---|---|---|
| num_modes | No | Number of Floquet modes (2-20, default 2) | |
| scan_phi_deg | No | Scan azimuth angle in degrees (default 0) | |
| scan_theta_deg | No | Scan elevation angle in degrees (default 0) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It does not disclose behavioral traits like prerequisites (e.g., existing Floquet port), side effects, or error handling. Users are left unsure if this modifies an existing port or creates new settings.
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, front-loaded with purpose, no fluff. Every sentence adds value. Appropriate length and structure.
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 full schema coverage and lack of output schema, description covers purpose and parameters. However, it lacks context on prerequisites (e.g., existence of a Floquet port) and return values, which are important for a configuration 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?
Input schema has 100% coverage with descriptions for all three parameters. Description mentions they control modes and scan angle but adds no extra meaning beyond schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the verb 'Configure' and resource 'advanced Floquet port settings'. It distinguishes from sibling tools like 'cst_add_floquet_port' by focusing on advanced settings. Mentions specific controls (number of modes and scan angle) and context (periodic structures, phased array).
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?
Description implies this tool is for advanced configuration after adding a Floquet port, but does not explicitly state when to use it vs alternatives. Siblings include basic port creation, so guidance on sequencing or prerequisites would improve clarity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Set the simulation frequency range in GHz. This determines the bandwidth over which the solver computes results.
| Name | Required | Description | Default |
|---|---|---|---|
| f_max | Yes | Maximum frequency in GHz | |
| f_min | Yes | Minimum frequency in GHz |
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 of behavioral disclosure. It only states that the tool 'determines the bandwidth over which the solver computes results', but fails to mention any side effects, required sequence, or potential impact on existing settings. 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 extremely concise with two sentences. The first sentence front-loads the action, and the second adds context. Every word is necessary, and there is 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 two-parameter tool, the description is adequate but lacks additional context such as whether this setting is persistent, if it can be called multiple times, or any preconditions. Given the absence of an output schema and annotations, a score of 3 reflects a minimum viable description.
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 100%, with both parameters described as 'Minimum/Maximum frequency in GHz'. The description does not add any semantic meaning beyond what the schema already provides, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Set' and the resource 'simulation frequency range', specifying units in GHz. It is distinct from sibling tools like cst_set_mesh_density or cst_set_boundary, making the tool's 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?
The description does not provide any guidance on when to use this tool versus alternatives, such as whether it should be called before setting ports or running a simulation, or if there are prerequisites. No exclusion criteria or context is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Set global mesh density parameters controlling automatic mesh generation. Higher cells_per_wavelength gives finer mesh and better accuracy at the cost of longer simulation time.
| Name | Required | Description | Default |
|---|---|---|---|
| min_cells | No | Minimum number of mesh steps across any structure (default 5) | |
| ratio_limit | No | Maximum ratio between adjacent mesh cells (default 20) | |
| cells_per_wavelength | No | Number of mesh cells per wavelength (default 15) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds some behavioral context by explaining the accuracy-performance trade-off, but with no annotations, it misses details such as whether settings are overwritten, if mesh regeneration is required, or other 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 (two sentences) and front-loaded: first sentence states purpose, second adds a key trade-off. No unnecessary 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 and no annotations, the description adequately covers the tool's role and the main parameter's effect. It could be improved by referencing when to use this tool vs other mesh-related siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% of parameters with descriptions; the description adds value only for cells_per_wavelength by explaining its effect. This meets the baseline of 3 for high schema coverage with minimal additional insight.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Set') and the resource ('global mesh density parameters controlling automatic mesh generation'), effectively distinguishing it from sibling tools like cst_add_mesh_refinement or cst_set_mesh_type.
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 explicit guidance on when to use this tool vs alternatives. While it mentions the trade-off for cells_per_wavelength, it does not compare to other mesh tools or provide context for when settings should be adjusted.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Set the mesh type for the simulation. Hexahedral is used for time-domain, Tetrahedral for frequency-domain, Surface for integral-equation, and Hexahedral TLM for TLM solver.
| Name | Required | Description | Default |
|---|---|---|---|
| mesh_type | Yes | Type of mesh to use |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It explains the mapping of mesh types to solvers but does not disclose side effects (e.g., whether this call can be made multiple times, if it resets other mesh settings, or if a project must be open). This is adequate but not comprehensive.
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 sentences with no filler. The first sentence states the purpose, and the second explains the mapping. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one required parameter, no output schema), the description is fairly complete. It explains the parameter's values and their implications. However, it could mention whether the tool can be called multiple times or if there are prerequisites like an open project, but these are minor 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?
The input schema already has 100% coverage with a description for the 'mesh_type' parameter. The description adds significant value by explaining each enum value's meaning in the context of solver domains, which is beyond the schema's simple 'Type of mesh to use' description.
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: setting the mesh type for the simulation. It goes beyond a simple verb+resource by providing a mapping of each mesh type to its corresponding solver domain (e.g., Hexahedral for time-domain, Tetrahedral for frequency-domain), which distinguishes it from sibling tools that set other simulation parameters.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on when to use each mesh type by associating them with different solver domains (time-domain, frequency-domain, integral-equation, TLM). However, it does not explicitly state when not to use this tool or mention alternative mesh-related tools like cst_set_mesh_density, so it lacks explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Set or create a design parameter in CST Studio. Parameters can hold numeric values or string expressions referencing other parameters.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Parameter name (e.g. 'patch_length', 'substrate_h'). | |
| value | Yes | Parameter value — a number (e.g. 10.5) or a string expression referencing other parameters (e.g. 'patch_length / 2'). | |
| description | No | Optional human-readable description of the parameter. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavioral traits. It notes that values can be numeric or string expressions, but fails to mention side effects like triggering recomputation, requirement of an open project, or that setting a parameter may invalidate previous results.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at two sentences, with no redundant information. The key action ('Set or create a design parameter') is front-loaded, and every word 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?
Given the tool's simplicity (3 parameters, no output schema) and the existence of sibling tools covering other parameter operations, the description covers the core functionality well. It could mention the optional 'description' parameter and whether the tool returns a result, but overall is sufficiently 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 schema covers 100% of parameters with descriptions, establishing a baseline of 3. The description adds value by elaborating that 'value' can be a numeric or a string expression referencing other parameters, and provides concrete examples for 'name' (e.g., 'patch_length'). This enhances semantic clarity 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's verb ('Set or create') and resource ('design parameter'). It distinguishes from sibling tools like cst_get_parameter, cst_delete_parameter, and cst_list_parameters, 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 provides no guidance on when to use this tool versus alternatives (e.g., when to update vs create, or prerequisites like having an open project). No 'when not to use' or explicit context is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Configure periodic boundary conditions with optional phase shift for unit cell simulation. Sets X and Y boundaries to periodic and configures the phase shift for infinite array, FSS, and metasurface analysis.
| Name | Required | Description | Default |
|---|---|---|---|
| phase_x_deg | No | Phase shift in X direction in degrees (default 0) | |
| phase_y_deg | No | Phase shift in Y direction in degrees (default 0) |
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 that it sets X and Y boundaries to periodic and configures phase shift, but does not mention any side effects, prerequisites (e.g., required solver, open project), or limitations (e.g., Z boundary unchanged). This is minimal disclosure.
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, front-loaded with core purpose, then context. No filler, 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 2-param tool with no output schema, the description covers the main action. However, it could be more complete by noting that only X and Y are affected, or that no required parameters exist. Currently 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?
Schema coverage is 100% with descriptions for both parameters (phase_x_deg, phase_y_deg). The description adds only 'optional phase shift' which is vague; no additional meaning like typical ranges or usage tips beyond schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses specific verb 'configure' and resource 'periodic boundary conditions', and mentions use case (unit cell simulation, FSS, metasurface). However, it does not explicitly differentiate from closely related sibling like cst_set_boundary, which could also set periodic boundaries without phase shift.
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. The description implies use for periodic boundaries with phase shift but does not state when not to use or provide alternative tool names. Given many sibling tools, this is a gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Configure PML (Perfectly Matched Layer) absorbing boundary properties. Controls the number of absorbing layers and the target reflection level for fine-tuning radiation boundary accuracy.
| Name | Required | Description | Default |
|---|---|---|---|
| num_layers | No | Number of PML layers (4-12, default 4) | |
| reflection_level_db | No | Target reflection level in dB (-80 to -20, default -40) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description only states basic functionality without disclosing behavioral traits such as whether it overwrites previous PML settings, dependencies on boundary type, 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?
Two succinct sentences with front-loaded action verb and no superfluous information, earning its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple configuration tool with two well-documented parameters and no output schema, the description is sufficiently complete, though it lacks mention of return behavior or persistence.
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 100% with clear default values and ranges; description adds minimal context ('fine-tuning accuracy') beyond schema, so baseline score 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?
Description specifies verb 'Configure' and resource 'PML absorbing boundary properties', clearly distinguishing from sibling tools like cst_set_boundary which handle general 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?
Description implies usage context (fine-tuning radiation boundaries) but provides no explicit when-to-use or when-not-to-use guidance compared to alternatives like cst_set_boundary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Set symmetry planes to reduce computation time. Each axis can be assigned electric or magnetic symmetry, or none. Requires the model geometry and excitation to be compatible with the chosen symmetry.
| Name | Required | Description | Default |
|---|---|---|---|
| x_plane | No | Symmetry condition on the YZ plane (default none) | none |
| y_plane | No | Symmetry condition on the XZ plane (default none) | none |
| z_plane | No | Symmetry condition on the XY plane (default none) | none |
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 the tool sets symmetry planes and lists options, but does not mention side effects, reversibility, or impact on other project settings. The compatibility requirement is noted, but more detail on consequences 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 with two sentences, no redundant words, and the key information is front-loaded. Every sentence contributes meaning.
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 only three parameters (all enumerated) and no output schema, the description covers the purpose, usage requirement, and parameter options adequately. It does not detail the return value (likely void), but for a simple setting tool this is acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds value by explaining the purpose of symmetry (reducing computation time) and the compatibility constraint, which goes beyond the schema's per-parameter descriptions. This additional context justifies a higher score.
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 ('set symmetry planes') and purpose ('reduce computation time'), and specifies the available options (electric, magnetic, none). It distinguishes itself from sibling tools by focusing on symmetry settings, which is a unique function among the listed tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a prerequisite ('requires model geometry and excitation to be compatible') but does not explicitly state when to use this tool versus alternatives (e.g., boundary conditions or other symmetry methods). No guidance on when not to use it is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Start a background thread that automatically detects and dismisses CST dialog windows as they appear. Essential for long-running operations like optimization loops where dialogs would otherwise block execution. The watcher logs every dialog it dismisses — retrieve the log with cst_stop_dialog_watcher.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully carries the burden of behavioral disclosure. It states the watcher runs in a background thread, automatically detects and dismisses CST dialog windows, and logs each dismissal. It does not mention potential side effects (e.g., performance impact), but the core behavior is well-covered.
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 sentences that efficiently convey purpose, usage context, and a reference to the complementary tool. Every word 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?
Given the tool has no parameters, no output schema, and is a straightforward start action, the description provides complete context: what it does, when to use it (long-running ops), and what the output is (a log retrievable via another tool). No missing information.
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 zero parameters, and schema coverage is 100%, so the description needs no parameter details. The baseline for 0 parameters is 4, which 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 uses a specific verb ('start') and resource ('dialog watcher'), and distinguishes itself from the sibling tools 'cst_stop_dialog_watcher' (complementary) and 'cst_dismiss_dialogs' (one-time action) by noting it runs in the background for long-running 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 explicitly states when to use the tool ('essential for long-running operations like optimization loops where dialogs would otherwise block execution') and references the complementary tool 'cst_stop_dialog_watcher' for retrieving logs. It does not provide explicit when-not-to-use scenarios, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Stop the background dialog watcher and return its log of all dialogs that were auto-dismissed. Use after completing an operation that required the watcher.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description covers the key behavior—stopping the watcher and returning a log. It does not elaborate on side effects like log clearing, but the action is straightforward and sufficiently 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 consists of two concise, front-loaded sentences. Every sentence adds value: first states what it does, second provides usage timing. 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 has no parameters, no output schema, and is a simple stop action, the description is adequate. It could optionally detail the log format, but the current info is sufficient for an agent to understand its role.
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 no parameters, so schema coverage is trivially 100%. The description adds no parameter details, which is acceptable since none are 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 description clearly states the tool stops a background dialog watcher and returns its log. It identifies a specific resource and action, and distinguishes from siblings like cst_start_dialog_watcher and cst_dismiss_dialogs.
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 explicit usage context: 'Use after completing an operation that required the watcher.' This implies it should be called after starting the watcher, but it does not explicitly mention when not to use or compare to alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Stop and abort a running CST simulation. Unlike pause, a stopped simulation cannot be resumed — it must be restarted from the beginning.
| 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 carries full burden. It discloses the key behavior: the simulation is aborted and cannot be resumed. However, it could add more about side effects (e.g., unsaved data) or safety (e.g., multiple calls). Given the tool's simplicity (0 params), the disclosure is adequate but not exhaustive.
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, zero waste. Every word adds value: the first sentence states the action, the second provides crucial contrast with pause. Highly efficient and front-loaded.
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, no parameters, and low complexity, the description is mostly complete. It explains the action and irreversibility. Could note that a running simulation is required, but that is implied. Adequate for the tool's simplicity.
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 no parameters and schema coverage is 100% (trivially). The description adds meaning beyond the schema by explaining the action and irreversibility. Baseline for 0-param tools is 4, and the description meets that standard.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific verbs ('Stop and abort') and resource ('running CST simulation'), and explicitly distinguishes from the sibling tool 'pause' by noting irreversibility. This clearly states what the tool does and differentiates it from alternatives.
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 contrasts with pause ('Unlike pause, a stopped simulation cannot be resumed'), providing clear context for when to use this tool versus alternatives. However, it does not explicitly state when not to use it or mention prerequisites (e.g., needing a running simulation), so it misses some exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Mirror a solid across a plane (xy, xz, or yz). An optional center point can be specified.
| Name | Required | Description | Default |
|---|---|---|---|
| copy | No | If true, create a copy instead of moving the original | |
| plane | Yes | Mirror plane | |
| solid | Yes | Solid reference in "Component:Solid" format | |
| center_x | No | X coordinate of the transform center | |
| center_y | No | Y coordinate of the transform center | |
| center_z | No | Z coordinate of the transform center |
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 mentions mirroring across a plane and an optional center point, but fails to describe the critical copy parameter (whether the original is moved or a copy is created). This omission significantly reduces 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 a single, direct sentence that front-loads the key operation: 'Mirror a solid across a plane' and mentions the optional center point. 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 six parameters (including a boolean copy and three center coordinates) and no output schema or annotations, the description is too sparse. It lacks details on copy behavior, coordinate system assumptions, and default center behavior, leaving the agent underinformed.
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 100%, so the baseline is 3. The description adds no new information beyond the schema: it repeats plane enum options and the existence of a center point, but does not explain semantics like 'copy' or coordinate 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 identifies the verb 'mirror' and resource 'solid' across a plane, listing specific plane options (xy, xz, yz) and the optional center point. This differentiates it from sibling transform tools like cst_transform_translate or cst_transform_rotate.
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 translate or rotate, nor does it mention prerequisites or exclude negative cases. It only gives a minimal operation statement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Rotate a solid by a given angle around an axis (x, y, or z). An optional center point can be specified.
| Name | Required | Description | Default |
|---|---|---|---|
| axis | Yes | Rotation axis | |
| copy | No | If true, create a copy instead of moving the original | |
| angle | Yes | Rotation angle in degrees | |
| solid | Yes | Solid reference in "Component:Solid" format | |
| center_x | No | X coordinate of the transform center | |
| center_y | No | Y coordinate of the transform center | |
| center_z | No | Z coordinate of the transform center |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose behavior beyond the schema. It mentions optional center and axis, but does not clarify that the tool modifies the solid in place (copy parameter defaults to false) or what the return value is. This is adequate but incomplete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single 22-word sentence that efficiently conveys the core functionality without unnecessary detail. It is front-loaded and earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 7 parameters, no output schema, and no annotations, the description covers the main idea but omits important context: in-place modification behavior (copy parameter) and that no output is returned. It suffices but has 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?
The input schema has 100% coverage, so baseline is 3. The description adds 'around an axis (x, y, or z)' and 'optional center point', which aligns with schema fields but does not add substantial new meaning beyond existing 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 the tool rotates a solid, specifies angle, axis (x,y,z), and optional center point. It distinguishes from sibling transform tools (scale, mirror, translate) by naming the specific 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 provides no guidance on when to use this tool vs. alternatives like cst_transform_scale or cst_transform_translate. It only implies usage for rotation without giving exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Scale a solid by independent factors along each axis. An optional center point can be specified.
| Name | Required | Description | Default |
|---|---|---|---|
| copy | No | If true, create a copy instead of moving the original | |
| solid | Yes | Solid reference in "Component:Solid" format | |
| scale_x | No | Scale factor along X axis | |
| scale_y | No | Scale factor along Y axis | |
| scale_z | No | Scale factor along Z axis | |
| center_x | No | X coordinate of the transform center | |
| center_y | No | Y coordinate of the transform center | |
| center_z | No | Z coordinate of the transform center |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility. It does not disclose whether scaling modifies the original or creates a copy (though the 'copy' parameter exists), nor does it mention side effects, permissions, or result 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 two sentences (20 words), front-loaded with the main action, and contains no redundant information. Highly concise and 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?
For a tool with 8 parameters, no output schema, and no annotations, the description is too minimal. It fails to explain the meaning of scale factors (e.g., default 1 is identity), the role of the center point, or warning about negative factors.
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 100%, so baseline is 3. The description adds context about the optional center point, but this is already implied by the schema parameters. No additional semantic value beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Scale', the resource 'a solid', and specifies scaling by independent factors along each axis with an optional center point. This effectively distinguishes it from sibling tools like rotate and translate.
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 cst_transform_rotate or cst_transform_translate. It lacks context about prerequisites, scenarios, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Translate (move) a solid by a displacement vector (dx, dy, dz). Optionally create a translated copy.
| Name | Required | Description | Default |
|---|---|---|---|
| dx | Yes | Translation distance along X axis | |
| dy | Yes | Translation distance along Y axis | |
| dz | Yes | Translation distance along Z axis | |
| copy | No | If true, create a copy instead of moving the original | |
| solid | Yes | Solid reference in "Component:Solid" format |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries the burden. It indicates the tool can move or copy a solid, but does not clarify if the original is modified by default, what happens to the original when copying, or any return value. The ambiguity around destructive behavior lowers the score.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence that conveys all key information without redundancy. It is front-loaded and 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?
The description covers the tool's purpose and parameters but lacks information about return values, side effects, or prerequisites. With no output schema, the agent is left uncertain about what the tool provides after execution.
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 100% with each parameter described. The description adds minimal value beyond the schema, grouping dx, dy, dz as a displacement vector and noting the copy option. It does not introduce new meaning not already 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 verb 'Translate (move)' and the resource 'a solid', specifying the displacement vector as (dx, dy, dz). It distinguishes from sibling tools like cst_transform_rotate or cst_transform_scale by focusing on translation.
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 this tool (for moving solids) and briefly mentions the optional copy feature, but does not explicitly state when not to use it or compare to alternatives. Given sibling names, the context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get VBA reference documentation for a CST Studio object. Returns the object description and a list of its common methods and properties.
| Name | Required | Description | Default |
|---|---|---|---|
| object_name | Yes | Name of the CST VBA object to look up, e.g. 'Brick', 'Solver', 'Material', 'Port', 'Mesh', 'FarfieldPlot'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It does not mention that the tool is read-only, has no side effects, or requires specific permissions/authentication. The behavior is implied but not explicitly stated.
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, front-loaded with verb and resource, no extraneous text. Every word contributes to 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?
For a simple help tool with one parameter and no output schema, the description covers the essential return information (description and list of methods/properties). It is adequate for the expected usage, though it could specify scope (e.g., current project).
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 100% with a brief description for the 'object_name' parameter. The description adds meaningful examples (e.g., 'Brick', 'Solver') that enhance understanding beyond the schema, compensating for the schema's brevity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns VBA reference documentation for a CST Studio object, specifying the verb (Get), resource (documentation), and what is returned (object description and common methods/properties). This distinguishes it from siblings like cst_execute_vba or cst_list_vba_objects.
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 such as cst_list_vba_objects. The description does not specify prerequisites or scenarios where this tool is preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Set up a Monte Carlo yield analysis to estimate manufacturing yield. Randomly varies parameters according to their tolerances and evaluates pass/fail criteria.
| Name | Required | Description | Default |
|---|---|---|---|
| parameters | Yes | ||
| num_samples | No | Number of Monte Carlo samples. | |
| pass_criteria | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses core behavior: random parameter variation and pass/fail evaluation. However, it does not clarify whether the tool runs simulations or merely sets up the analysis, nor does it mention side effects or requirements. With no annotations, more detail on execution and output 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, consisting of two sentences that front-load the core purpose and method. No extraneous information is present.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of Monte Carlo analysis, the lack of an output schema, and low schema coverage, the description is insufficient. It does not explain how results are returned or what the output of the tool is, leaving a significant gap for an AI agent to correctly invoke and process outcomes.
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 by explaining that parameters are varied according to tolerances and that pass/fail criteria are evaluated, which complements the schema. However, it does not elaborate on the distribution or num_samples parameters, and schema coverage is low (33%), so 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 tool performs a Monte Carlo yield analysis, specifying it varies parameters based on tolerances and evaluates pass/fail criteria. This directly conveys the purpose and distinguishes from general simulation tools, though it does not explicitly differentiate from other analysis tools like sensitivity analysis.
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 parameter sweep or sensitivity analysis. The description lacks context for appropriate usage scenarios or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.2.0cst_add_discrete_portcst_add_field_monitorcst_add_fixpoint_meshcst_add_floquet_portcst_add_lumped_elementcst_add_mesh_refinementcst_add_multipin_portcst_add_plane_wavecst_add_waveguide_portcst_analyze_impedancecst_antenna_bowtiecst_antenna_dipolecst_antenna_helixcst_antenna_horncst_antenna_ifacst_antenna_monopolecst_antenna_patchcst_antenna_pifacst_antenna_slotcst_antenna_spiralcst_antenna_vivaldicst_antenna_yagicst_array_beam_steeringcst_array_circularcst_array_compute_factorcst_array_grating_lobe_analysiscst_array_linearcst_array_mutual_couplingcst_array_planarcst_array_taper_designcst_assign_materialcst_boolean_addcst_boolean_insertcst_boolean_intersectcst_boolean_subtractcst_close_projectcst_configure_eigenmode_advancedcst_configure_eigenmode_solvercst_configure_frequency_domain_solvercst_configure_ie_solver_advancedcst_configure_integral_equation_solvercst_configure_multilayer_solvercst_configure_time_domain_solvercst_connection_statuscst_constrained_optimizercst_create_analytical_curvecst_create_anisotropic_materialcst_create_brickcst_create_cole_cole_materialcst_create_conecst_create_cylindercst_create_debye_materialcst_create_drude_materialcst_create_ecylindercst_create_extrudecst_create_face_from_curvescst_create_ferrite_materialcst_create_loftcst_create_lorentz_materialcst_create_lossy_metalcst_create_materialcst_create_polygon_extrudecst_create_polygon3dcst_create_projectcst_create_spherecst_create_temperature_dependent_materialcst_create_toruscst_create_wirecst_delete_materialcst_delete_parametercst_delete_portcst_delete_resultscst_dismiss_dialogscst_evaluate_antennacst_execute_vbacst_export_cadcst_export_farfieldcst_export_projectcst_export_resultcst_export_touchstonecst_get_axial_ratiocst_get_bandwidthcst_get_cross_polarizationcst_get_current_distributioncst_get_efficiencycst_get_efficiency_breakdowncst_get_farfieldcst_get_gaincst_get_group_delaycst_get_impedancecst_get_material_infocst_get_mesh_infocst_get_mesh_qualitycst_get_parametercst_get_pattern_cutcst_get_radiation_pattern_3dcst_get_result_summarycst_get_s_parameter_phasecst_get_s_parameterscst_get_simulation_statuscst_get_smith_chart_datacst_get_solver_infocst_get_surface_currentcst_get_time_domain_signalcst_get_vswrcst_impedance_smith_transformcst_import_cadcst_import_touchstonecst_list_antenna_templatescst_list_ferrite_materialscst_list_materialscst_list_parameterscst_list_portscst_list_resultscst_list_vba_objectscst_load_materialcst_matching_create_lumpedcst_matching_l_networkcst_matching_microstrip_impedancecst_matching_pi_networkcst_matching_quarter_wavecst_matching_stubcst_matching_t_networkcst_multi_objective_optimizercst_open_projectcst_optimizercst_parameter_interpolationcst_parameter_sweepcst_pause_simulationcst_pcb_calculate_couplingcst_pcb_cpw_transitioncst_pcb_create_ground_planecst_pcb_create_stackupcst_pcb_create_tracecst_pcb_create_viacst_pcb_differential_paircst_pcb_import_gerbercst_pcb_list_stackup_templatescst_pcb_siw_waveguidecst_pcb_via_fencecst_pcb_via_modelcst_project_infocst_project_treecst_read_project_logcst_refine_antennacst_resume_simulationcst_run_simulationcst_run_simulation_asynccst_save_projectcst_schematic_callcst_schematic_connectcst_schematic_create_external_portcst_schematic_create_rlccst_schematic_listcst_schematic_list_objectscst_schematic_object_methodscst_sensitivity_analysiscst_set_adaptive_meshcst_set_backgroundcst_set_boundarycst_set_floquet_port_advancedcst_set_frequency_rangecst_set_mesh_densitycst_set_mesh_typecst_set_parametercst_set_periodic_boundarycst_set_pml_propertiescst_set_symmetrycst_start_dialog_watchercst_stop_dialog_watchercst_stop_simulationcst_transform_mirrorcst_transform_rotatecst_transform_scalecst_transform_translatecst_vba_helpcst_yield_analysisScored across 177 tools
The tools have distinct purposes with detailed descriptions, but some overlap exists among result extraction tools (e.g., multiple farfield-related functions) which could cause agent confusion.
Naming uses a consistent 'cst_' prefix and underscore separation, but mixes action-oriented (add_, create_, get_) and domain-oriented (antenna_, array_, pcb_) patterns, with minor inconsistencies like 'cst_impedance_smith_transform'.
177 tools is excessively large for a single server, far beyond typical scoping. Many could be parameterized or combined, making the tool set unwieldy and difficult for agents to navigate effectively.
The tool set covers a broad range of CST Studio Suite functionalities including project management, geometry, materials, ports, solvers, simulation, optimization, antenna/array/PCB creation, and results analysis, with only minor gaps in areas like thermal or SAR analysis.
Protocol-native energy infrastructure orchestration for AI data centers. Provides 46 MCP tools across 8 grid protocols (IEC-61850, DNP3, Modbus, OCPP, OpenADR, IEEE 2030.5, IEC 60870-5-104, ICCP) with 5 core API primitives: connect, dispatch, settle, comply, and intel. Enables AI agents to programmatically interact with substations, grid interfaces, and energy assets for real-time workload-grid coordination.
Free public MCP for AI agents — 193 tools, 44 workflows. No API key.
Geocoding, routing, isochrones, traffic, weather, and place search for AI agents. 19 MCP tools.
100+ MCP tools for AI agents: content metadata, trade intelligence, business-expertise analysis.
