COMSOL MCP Server
Server Quality Checklist
Latest release: v0.1.0
- Disambiguation4/5
Tools are organized by domain with descriptive names, but some overlap exists between generic and specific geometry tools (e.g., geometry_add_feature vs geometry_add_block) and between boundary condition configuration tools (physics_boundary_selection, physics_configure_boundary, interactive setup flows). However, descriptions mostly clarify differences.
Naming Consistency4/5Names follow a consistent prefix_pattern (comsol_, model_, geometry_, physics_, param_, results_, study_) with verb_noun structure. Minor inconsistencies: modeling_best_practices uses 'modeling_' vs 'model_', pdf_list_modules vs docs_ prefix, and geometry_add_feature uses 'feature' instead of specific type.
Tool Count2/5With 78 tools, the surface is overly broad. Many tools are redundant (e.g., separate geometry_add_block/cylinder/sphere vs generic geometry_add_feature; multiple interactive setup flows duplicate manual setup). Consolidation could reduce count significantly without loss of functionality.
Completeness4/5The tool set covers the full COMSOL workflow from connection to results evaluation. Minor gaps include explicit material library management tools, integration operators, and probe creation. However, core modeling tasks are well-supported.
Average 3.6/5 across 78 of 78 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 2 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is failing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add
glama.jsonto the root of your repository:{ "$schema": "https://glama.ai/mcp/schemas/server.json", "maintainers": [ "your-github-username" ] }Then . Browse examples.
Add related servers to improve discoverability.
How to sync the server with GitHub?
Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.
To manually sync the server, click the "Sync Server" button in the MCP server admin interface.
How is the quality score calculated?
The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).
Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.
Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).
Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.
Tool Scores
- Behavior2/5
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 beyond the basic action of adding a circle. There is no mention of side effects, required permissions, or constraints (e.g., whether the circle can be modified later).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a concise docstring with a clear purpose line, parameter list, and return statement. It is well-structured and includes no unnecessary text, efficiently conveying the core information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple additive tool with 4 parameters and no output schema, the description covers the basic inputs and output ('Created circle info'), but it lacks details on the output format or any constraints. It is minimally adequate but could be more complete with examples or additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description explains each parameter: position as center [x,y] in meters, radius default 0.5, and optional geometry/model names. This adds meaning beyond the schema, but the schema already shows defaults and types. The description does not elaborate on units or expected format beyond the docstring.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool adds a circle to a 2D geometry or work plane. The verb 'Add' and resource 'circle' are specific, and the tool is distinguished from siblings like geometry_add_block or geometry_add_rectangle by its shape-specific name and description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 other geometry addition tools (e.g., add_block, add_rectangle). No context such as prerequisites or if the geometry must exist beforehand is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must fully disclose behavior. It only says 'remove from memory' and returns confirmation/error, but does not state if the model file is affected, if other references become invalid, or side effects (e.g., freeing resources). Vague.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Very short and to the point without extraneous details. However, it's so concise that it sacrifices completeness. Every sentence is necessary but could be expanded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description is minimally adequate but does not explain error conditions (e.g., model not found), success indication, or relationship to sibling tools like model_load. Lacks context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and the description only restates 'Name of the model to remove' with no added meaning beyond the schema's title. Does not clarify expected format, case sensitivity, or how to specify the model (by file path or internal name?).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'remove' and the resource 'model from memory', distinguishing it from siblings like model_list, model_load, and model_clone, which do not remove from memory.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 model_save before removal or model_clear. Missing prerequisites (e.g., model must be loaded) and exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must convey behavioral traits like side effects, state changes, and error conditions. It only states that it sets the current active model and returns a confirmation/error message, but fails to disclose what 'current active model' implies (e.g., it changes global state for subsequent operations) or how it behaves with invalid input.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with an efficient main sentence and additional structured sections (Args, Returns). It is front-loaded and avoids unnecessary detail, making it easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given 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 or annotations, the description covers the basic purpose and parameter. However, it omits important context like error handling, prerequisites (model must exist), and post-condition behavior, making it minimally viable but not robust.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% coverage (no descriptions for parameters), so the description shoulders the burden of explaining the parameter. It adds 'Name of the model to set as current' which is basic but helpful. However, it does not clarify the expected format (e.g., model name vs. ID, path, or handle), leaving ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (set) and the target (current active model), indicating its role in selecting which model to use for subsequent operations. However, it does not explicitly differentiate from sibling tools like model_load or model_create, leaving the agent to infer that this tool is for switching between already-loaded models.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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, what prerequisites are needed (e.g., model must already be loaded), or what context it should be used in. The agent is left to guess the proper usage scenario.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fails to disclose behavioral traits such as whether the operation modifies the study, is irreversible, or requires specific permissions. It only indicates a 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.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively concise but includes unnecessary 'Args:' and 'Returns:' formatting typical of docstrings, which adds clutter. It could be streamlined without losing clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given 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 lacks complete context. It does not explain the return format in detail, nor does it mention prerequisites like needing an existing study or model.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning beyond the input schema by specifying default values for optional parameters and briefly explaining each parameter. Since schema description coverage is 0%, the description compensates adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool sets up a parametric sweep for a parameter, with a specific verb and resource. It is distinct from sibling tools like param_set which sets a single value, but does not explicitly differentiate them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 param_set or study_solve. The description does not mention prerequisites or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It states removal but does not disclose whether removal is irreversible, what happens to associated boundaries or settings, or if there are safety restrictions. The behavior is minimally disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise with a single sentence, then Args/Returns in a standard format. No unnecessary words, but could be slightly more detailed without bloat.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, low schema coverage, and no annotations, the description is insufficient for a removal tool. It does not mention return value details, error cases, or permanence of removal, 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.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description must explain parameters. It lists physics_name as required and model_name as optional with default null, but does not explain valid values, naming conventions, or where to obtain physics names. The description adds little beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Remove a physics interface from the model,' specifying the verb (remove) and resource (physics interface). This effectively distinguishes it from sibling tools like physics_add (add) and physics_list (list).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 physics_list to verify existence beforehand. No prerequisites or conditions (e.g., physics interface must exist) are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/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 states that the tool returns arrays of indices and values, implying it is a read operation, but it does not explicitly disclose whether it modifies state, requires authentication, or has other behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with the purpose. It uses a clear docstring format with Args and Returns sections, adding no extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description explains the return value but does not clarify what 'inner' means relative to 'outer', nor does it cover potential prerequisites or the relationship to sibling tools like 'results_evaluate'. Given the low complexity (2 optional parameters, no output schema), it is minimally adequate but leaves gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the description adds default values (e.g., 'default dataset', 'current model') that are not in the schema, providing some context. However, it does not elaborate on allowed values or constraints beyond the simple statements.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get inner solution indices and values (time steps in time-dependent study)', specifying the verb, resource, and context. It hints at distinction from 'results_outer_values' by using 'inner', but does not explicitly differentiate from other results tools like 'results_evaluate'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The context mentions time-dependent studies, but there is no explicit when-to-use, when-not-to-use, or mention of related sibling tools such as 'results_outer_values'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It explains parameters and return value but does not disclose if solving is destructive, prerequisites (e.g., study must exist), 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.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description includes a verbose Args section with parameter details. It is structured but could be more concise. Every sentence adds value, but the format is not optimal for quick scanning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists; the description mentions 'Solution status, or error message' but lacks detail on what the status contains. Prerequisites (e.g., study must exist) are not stated. Given the tool's complexity and many siblings, more context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description adds meaning for all 4 parameters: study_name (None for all), model_name (default current), wait (boolean for blocking), timeout (only when wait=True). This compensates for the schema lacking descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool solves a study, with 'synchronous by default'. The function name and sibling tools like study_solve_async and study_cancel help differentiate, but the description does not explicitly contrast with siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use synchronous vs async (study_solve_async) or other study-related tools. The description implies synchronous is default but does not provide context 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.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description states it adds a feature and returns created feature info, but does not disclose side effects, error handling, or prerequisites. With no annotations, more behavioral context is needed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is verbose with a long list of feature types and args, including boilerplate for kwargs. It is front-loaded with purpose, but the list adds unnecessary length. Could be more concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description explains the return value and gives a basic outline of parameters. However, it lacks examples, constraints on kwargs, and error handling details. Given the tool's generic nature and lack of output schema, it is minimally complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It explains all four named parameters and mentions kwargs for feature-specific properties, but does not clarify that kwargs should be a JSON string (schema type) nor provide constraints or examples.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it adds a geometry feature to a sequence and lists common feature types. However, it does not differentiate from sibling tools like geometry_add_block or geometry_add_circle, which serve specific feature types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this generic tool versus the specific sibling tools for blocks, circles, etc. The description fails to clarify the appropriate context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description bears full burden. It discloses default parameter behaviors but omits side effects, required permissions, or whether the tool modifies state. A listing tool likely has minimal side effects, but no explicit confirmation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Concise and structured with Args and Returns sections. However, the Returns line is somewhat vague ('List of geometry features with their types'). Could be slightly more specific without adding bloat.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, but description mentions return type. However, lacks details on how the return list is structured or what 'types' refer to. Adequate for a simple list tool but leaves some ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, the description adds meaningful defaults and explanations for both parameters (geometry_name defaulting to first geometry, model_name defaulting to current model). This compensates for the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List' and the resource 'features in a geometry sequence', distinguishing it from siblings like geometry_add_feature or geometry_list. However, it could be more specific about what 'features' entails.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. The description does not specify prerequisites, when-not to use, or mention related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden. It states it gets information, implying a read-only operation, but does not explicitly confirm it is non-destructive, nor does it disclose any behavioral traits like authorization needs 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise at about 4 lines, using a clear Args/Returns structure. However, the Returns section is somewhat lengthy and could be more succinct.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has only one parameter and no output schema, the description covers the parameter adequately but lacks detail on return values (e.g., format) and potential restrictions. It is minimally sufficient but not rich.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage for the parameter, but the description adds value by noting the default value ('current model') and that it can be null. This meaningfully supplements the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets detailed information about a model's structure and contents, using specific verbs and resources. However, it does not explicitly differentiate from sibling tools like model_list or model_clone, which also deal with models.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 inspection but does not provide context for when it is appropriate or what prerequisites exist (e.g., model must be loaded).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
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 transparency. It does not disclose side effects, prerequisites, limitations, or return value format. The return is vaguely 'Created physics info' without details, leaving the agent uncertain about behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: one sentence for purpose, plus Args and Returns sections. Front-loaded with the main action, no redundant words. Every sentence serves a clear purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with 2 optional params and no output schema, the description adequately covers the basic purpose and parameter meanings. However, it lacks details on return format, constraints, and integration context with sibling tools. Given no annotations, more context would be beneficial.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, so the description's parameter notes add some value (e.g., defaults for domain and model). However, the descriptions are terse and lack format specifics (e.g., what a 'selection name' looks like). The additive value is marginal, just enough to partially compensate for the schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it adds the Electrostatics physics interface for electric field analysis. The verb 'Add' and specific resource are clear. However, it does not differentiate from sibling tools like physics_add_heat_transfer or physics_add_solid_mechanics, missing explicit guidance on when to use this specific physics type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidelines are provided. The description does not specify when to use this tool versus alternatives, any prerequisites (e.g., model must exist), or context for invocation. This is a significant gap given the number of similar sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must carry the full burden. It only states the action and return type. It does not disclose whether the tool requires a current model, what happens if physics already exists, 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with the purpose. It wastes no words, though it could include more usage context without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description does not elaborate on return values beyond 'Created physics info'. It lacks error conditions, prerequisite model state, and interaction with other tools, making it incomplete for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, the description adds meaning by explaining domain_selection and model_name defaults. However, the explanations are minimal and do not fully compensate for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Add Laminar Flow physics') and the resource ('for fluid dynamics'). It is specific and distinguishes from sibling tools like physics_add_electrostatics or physics_add_heat_transfer.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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, no prerequisites, and no exclusion criteria. An agent has no context for choosing laminar flow over other physics.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; the description does not clarify whether the tool is read-only or modifies the model. It mentions both 'identify and configure' and 'provides setup instructions,' creating ambiguity about 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, uses bullets and clear sections (Args, Returns), and contains no unnecessary text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers the main purpose but misses prerequisites (e.g., need for an active model) and does not detail the return format or interactive behavior thoroughly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, the description adds basic meaning for physics_name and model_name but lacks examples or format constraints, leaving gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it is an interactive setup wizard for Heat Transfer boundary conditions, listing steps and distinguishing from related tools like physics_setup_heat_boundaries.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 like physics_setup_heat_boundaries or physics_add_heat_transfer. The context hints at an interactive role but lacks direct usage instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries full burden but only discloses parameter defaults (domain_selection, model_name). It does not mention side effects, required permissions, or what happens if the material or physics interface 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured with a clear one-line purpose followed by parameter and return documentation. No redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description does not explain the return value format ('Assignment confirmation'), error conditions, or dependencies (material must exist, physics must have domains). For a mutation tool with no output schema, this leaves significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema parameter description coverage, the description adds meaning by explaining each parameter's purpose and defaults. However, it lacks details on valid formats or constraints (e.g., domain_selection values must be integers).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Assign' and the resource 'material to physics domains', making the tool's function immediately obvious. It distinguishes itself from sibling tools like physics_add or physics_list by focusing on material assignment.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites (e.g., material must exist) or scenarios where this tool is inappropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose side effects, permissions, or limitations. It only states that it adds a sphere and returns info.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured as a docstring with Args and Returns sections, making it easy to parse. It is concise, though the first sentence is somewhat redundant with the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple addition tool, the description covers all parameters and the return value. It lacks mention of prerequisites (e.g., existing geometry) and examples, but is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description provides meaningful explanations for all 6 parameters, including units for position and radius. This compensates for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Add a sphere to the geometry', with a specific verb and resource. However, it does not differentiate from sibling tools like geometry_add_block or geometry_add_cylinder, which also add shapes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus other geometry_add_* tools. The description only lists parameters without usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description does not disclose effects on existing objects, permissions, error cases, or lifecycle details despite being a destructive operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Highly concise: one-line purpose, clear parameter list, and returns note. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema and minimal description leaves gaps: what is 'union operation info'? How to use result? No mention of prerequisites or relation to building geometry.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%. Description adds basic meaning (e.g., 'Names of objects to unite') but lacks details on format, required naming conventions, or how to obtain valid object names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Create' and the resource 'boolean union of geometry objects', distinguishing it from sibling tools like geometry_boolean_difference.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use union vs. difference or other geometry tools. No context on prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only states the action and return value. It does not disclose side effects (e.g., whether existing physics is replaced), required permissions, or model state expectations. The agent lacks insight into behavioral impacts.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: one sentence for purpose, two lines for args, and one for returns. No redundant information, front-loaded with the core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, the description only vaguely states 'Created physics info'. It omits context about model requirements, component selection, or how this interacts with other physics. For a tool with many siblings, more contextual completeness is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description adds minimal parameter context: it names the parameters and states defaults. However, it does not explain the format of 'domain_selection' or what 'Selection name' means, leaving ambiguity. Baseline for 0% coverage is low, and this is adequate but not rich.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Add Solid Mechanics physics for structural analysis', using a specific verb and resource. It distinguishes from sibling tools like physics_add_electrostatics and physics_add_heat_transfer by explicitly naming 'Solid Mechanics' and its application area.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 the generic 'physics_add' or other specific physics tools. The description provides no conditions, prerequisites, 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.
- Behavior2/5
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 explains it configures boundary conditions but does not state whether it overwrites existing conditions, requires prerequisites (e.g., physics already added), has side effects, or what 'Configuration confirmation' means. This is insufficient 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear intro, numbered steps, and organized examples by physics type. It is moderately concise, though the examples could be streamlined. Overall, it earns its place without excessive verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (generic boundary setup, 5 params, no output schema, no annotations), the description covers basic usage but lacks details on modification semantics, error handling, prerequisites, and return value format. It also does not guide when to use this vs. sibling tools. It is adequate but incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds meaning by explaining the four steps and giving examples for common boundary conditions and their properties. However, it does not fully describe all parameters (e.g., 'physics_name' and 'model_name' have no explanation), and the 'properties' dictionary is only partially illustrated.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it is a generic boundary condition setup tool with boundary selection, specifying physics interface, condition type, and boundary numbers. It provides examples for common physics, but does not explicitly differentiate from sibling tools like physics_configure_boundary, physics_setup_flow_boundaries, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description says 'Use this tool to configure any boundary condition' and lists common types, which implies usage. However, it does not provide when-not-to-use guidance or mention alternatives (e.g., specific setup tools for flow/heat), so the agent lacks clarity on when to prefer this generic tool over siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose behavioral details (e.g., requires an open model, no side effects). It only says 'List all features', omitting any such context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with the purpose. The Args section is slightly redundant with the schema, but overall it is efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 2 parameters, no annotations, and no output schema, the description is adequate but incomplete: it does not mention required model state, error conditions, or return format details beyond a brief note.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description's Args section adds minimal meaning: 'Name of the physics interface' and 'Model name (default: current model)'. This provides some value beyond the schema, but does not fully compensate for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'List' and clarifies 'features' with examples (boundary conditions, domain settings), clearly distinguishing it from siblings like physics_list (which lists interfaces) and physics_add.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 physics_list or other feature-related tools. The description states only what it does, not the context or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose any behavioral traits such as side effects, required study types, or state modifications. It only states the return type.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with a clear one-liner and structured Args/Returns sections. No extraneous information, but the parenthetical clarification is slightly redundant.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description explains the purpose and parameters but lacks details on return format (e.g., array shape) and error conditions. For a parametric sweep retrieval tool, more context on 'outer values' would help.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning to parameters by stating expected standard values (e.g., 'default dataset'), but notes a mismatch with schema defaults (null vs 'default dataset'). Schema coverage is 0%, so description partially compensates.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it gets outer solution indices and values in a parametric sweep, specifying the resource and context. It distinguishes itself from siblings like results_inner_values.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 results_inner_values or results_global_evaluate. No mention of prerequisites or conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description is minimal, stating only that it lists solutions. With no annotations provided, it fails to disclose any behavioral aspects such as whether it's safe (read-only), what happens if the model doesn't exist, or any side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, using a single line for purpose and clear sections for args and returns. Every sentence adds value; no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with one optional parameter and no output schema, the description is adequate but leaves ambiguity about the return format ('List of solution configurations'). It could be more complete by clarifying the structure of the returned list.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameter description (coverage 0%). The description adds the parameter's purpose ('Model name') and default value ('default: current model'), which provides meaningful guidance beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists all solutions in a model, using a specific verb (list) and resource (solutions). It does not explicitly differentiate from sibling list tools like datasets_list or docs_list, but the resource is distinct enough.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use or when not to use this tool instead of alternatives. The description mentions a default model but lacks context for when to specify model_name or how to determine the current model.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
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 only says 'Add a block...' and 'Returns Created block info' without describing side effects, validation, prerequisites, or what happens if the geometry doesn't exist. This is insufficient for a tool with no annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with a single purpose sentence followed by an organized argument list. It is front-loaded with the primary action. The list format is clear but slightly verbose (e.g., repeating 'default' multiple times).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 6 parameters, no output schema, and no annotations, the description should provide richer context about how this tool fits into the geometry workflow, what 'geometry_name' refers to, and the structure of the returned block info. The current description leaves many gaps for an AI agent to infer.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description adds value by explaining each parameter's meaning, units (meters), defaults, and field roles (e.g., 'position: Base position [x, y, z] in meters'). However, some terms like 'geometry_name' are only vaguely explained ('Geometry sequence name'). Still, it compensates significantly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Add a block (rectangular cuboid) to the geometry.' It specifies a distinct shape (rectangular cuboid) which differentiates it from sibling tools like geometry_add_circle, geometry_add_sphere, etc. The verb 'Add' and resource 'block' are specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 geometry_add_rectangle or geometry_add_cylinder. The description only lists parameters without any context about prerequisites, limitations, or best practices.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description only states basic functionality and return fields. It does not disclose potential side effects, performance implications, or requirements (e.g., need for an active session), leaving the agent with 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: the first clearly states the purpose, the second lists return fields. Every word adds value; it is efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless list tool with no output schema, the description adequately explains what the tool does and what it returns. It could mention error scenarios or prerequisites, but overall it is complete enough for typical use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and 100% schema coverage, so baseline is 4. The description adds value by outlining the return structure (name, file path, status), providing context beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists all models loaded in the COMSOL session, specifying the return fields (names, file paths, status). It is specific and unambiguous, though it does not differentiate from siblings like model_list_components.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives (e.g., model_list_components) or any prerequisites like an active connection. The description lacks context for proper selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
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 whether the operation is destructive, overwrites existing conditions, requires a prerequisite physics interface, or has side effects. The return info 'Created boundary condition info' is vague.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description contains a clear main sentence but is lengthy due to extensive bullet lists for three physics types (Electrostatics, Solid Mechanics, Heat Transfer). The Args section is well-structured, but the common conditions list could be more concise or referenced via a link to documentation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 5 parameters (3 required) and no output schema. The description explains parameters and provides example values per physics, but lacks details on how properties interact with boundary_condition, error handling, or prerequisites. For a configuration tool, it is moderately complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description adds parameter meaning via the Args section, listing types and default values. It provides examples for boundary_condition per physics, but lacks allowed values as enums and does not detail the properties dictionary for each condition. Adds moderate value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool configures a boundary condition for a physics interface, listing common boundary conditions per physics type (Electrostatics, Solid Mechanics, Heat Transfer). It distinguishes from sibling tools like physics_add_* which add interfaces, not configure boundaries.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a list of common boundary conditions but does not explicitly guide when to use this tool versus alternative boundary tools (e.g., physics_boundary_selection, physics_setup_flow_boundaries). No when-not-to-use 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.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses behavior for inner/outer parameters and return type ('Evaluated values as lists, or error message'). No annotations exist, so description carries the burden; however, it does not mention side effects, permissions, or any destructive potential (likely none). 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The docstring-style format (Args/Returns) is well-structured and concise. Each parameter description is a single line with examples. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description adequately covers parameters but leaves the return format vague ('lists' without structure). For a tool with 6 parameters and no output schema, more detail on return values would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description compensates by explaining each parameter with examples (e.g., 'es.normE', 'V/m'). This adds meaning beyond the schema's type-only definitions. Could improve by clarifying defaults more explicitly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('evaluate') and resource ('expression on a solution dataset'). It implies differentiation from siblings like results_global_evaluate by including a dataset parameter, but does not explicitly distinguish.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 results_global_evaluate, results_inner_values, or results_outer_values. The description only states what it does, not when to choose it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/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 states the tool returns a single numerical value but does not disclose side effects (likely read-only), performance implications, or prerequisites (e.g., model must be loaded). The description lacks behavioral details beyond purpose.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: a one-sentence purpose, bullet-point examples, and clear parameter documentation. It is front-loaded with the primary action. Every sentence is useful and there is no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 4 parameters, no output schema, and no annotations, the description covers the basics but lacks important context such as supported expression syntax, accepted units, whether a model must be loaded, or if it triggers computation. It is adequate but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description adds value by explaining each parameter: expression as 'Global expression to evaluate', unit as 'Desired unit for result', dataset and model_name with defaults. Examples of expressions further clarify. While not extremely detailed, it compensates well for the missing schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool evaluates a global expression returning a single scalar value, with specific examples of expressions like integration, maximum, and derived values. However, it does not explicitly differentiate from sibling tool 'results_evaluate', which may also evaluate expressions but likely on a local scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides common usage examples but lacks explicit guidance on when not to use this tool or alternatives. It implies use for global expressions but does not exclude other tools like 'results_evaluate' or 'param_get'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/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 only states it lists datasets and returns names, with no mention of side effects, permissions, or behavioral traits beyond a simple read operation. This is minimal 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (3 lines), front-loaded with the core purpose, and includes parameter documentation. It is efficient but could be slightly more structured with a brief explanation of datasets.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given 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 adequately covers purpose, parameter, and return type. It is sufficiently complete for this low-complexity tool, though it lacks sibling differentiation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, but the description adds meaningful context for the single parameter (model_name), explaining that it defaults to the current model. This compensates for the schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists all datasets in a model, using a specific verb and resource. However, it does not explicitly differentiate from sibling list tools like docs_list or solutions_list, though the resource is distinct.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context that datasets represent solution data for evaluation or visualization, but it does not specify when to use this tool over alternatives or when not to use it. No explicit usage guidance is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries full burden. It mentions 'Import geometry' and 'Returns: Import operation info' but does not disclose whether the tool modifies existing geometry, overwrites, or requires an active model. Side effects and permissions are absent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively short and uses a structured 'Args' and 'Returns' format. However, the docstring-style repetition of parameter names could be condensed, and the 'Returns' part adds little beyond the obvious.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a CAD import tool with multiple parameters and supported formats, the description lacks critical context: whether a model must be open, how the import interacts with existing geometry, and what 'Import operation info' actually contains. No output schema exacerbates the gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must add meaning. The 'Args' section provides brief descriptions for each parameter (e.g., 'Path to the CAD file', 'Geometry sequence name'), which is helpful but lacks details like allowed values for import_type or format-specific constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Import' and resource 'geometry from a CAD file', with a list of supported formats (STEP, IGES, STL, NASTRAN). This distinguishes it from sibling tools like geometry_add_* that create primitive shapes rather than import files.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description lists supported formats, implying the tool is for importing external CAD files, but does not explicitly state when to use it versus alternatives like geometry_create or geometry_add_feature. No when-not-to-use guidance or prerequisites (e.g., existing model) are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must fully disclose behavior. It states the tool runs meshing operations and returns a status, but it omits critical details: whether it is destructive (overwrites existing meshes), requires a model to be loaded, has side effects, or is asynchronous. The lack of behavioral context is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with a one-line summary followed by parameter and return descriptions. No superfluous information. The structure (summary, Args, Returns) is clear and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (2 optional params, no output schema), the description is minimally complete: it explains the main action and parameter roles, but lacks details on return value format, error conditions, or interaction with other tools (e.g., mesh_info). The return 'Mesh generation status' is vague.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It does provide semantic value: mesh_name is described as 'Mesh sequence name (default: run all mesh sequences)' and model_name as 'Model name (default: current model).' This adds meaning beyond the schema titles and defaults, but details on allowed values or format are missing.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Run a mesh sequence to generate the mesh.' It specifies that it executes meshing operations from a sequence, which distinguishes it from sibling tools like mesh_info or mesh_list that only inspect or list meshes. The action verb 'run' and resource 'mesh sequence' are specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied from the purpose—'when you want to create a mesh by running a sequence'—but no explicit guidance on when to use this tool versus alternatives like mesh_info or mesh_list. No prerequisites or exclusions are mentioned, relying on the user to infer context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must fully convey behavioral traits. It only states 'Get information' without confirming read-only behavior, lack of side effects, or any access requirements. The agent cannot infer safety from this text alone.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—one line for purpose, then structured Args/Returns sections. Every word adds value, and no unnecessary information is present.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple info tool with no output schema, the description covers purpose and parameters but fails to detail the return format beyond 'element counts.' Without an output schema, more specificity (e.g., keys like nodes, elements) would help the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description explains both parameters with default behaviors ('default: first mesh', 'default: current model'), adding significant meaning beyond the schema's type and title. Given 0% schema description coverage, this fully compensates.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Get information about a mesh' and specifies return includes element counts. This clearly identifies the action, but does not differentiate from sibling tools like mesh_list beyond the name. A slightly more specific purpose statement would improve clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 mesh_list or geometry_get_boundaries. The description does not mention prerequisites, typical workflow steps, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
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 states the tool adds a coupling, implying modification, but does not describe side effects, prerequisites, whether it overwrites existing couplings, or any authentication or rate limits. The example coupling types are useful but insufficient for complete transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured with a summary line, a bullet list of common coupling types, and an Args section. It is fairly concise but the list of types takes up space. Some information (e.g., 'Returns: Created coupling info') is minimal. It could be more streamlined without losing clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of annotations, output schema, and the tool's complexity (multiple parameters, selection of coupling types), the description is incomplete. It lacks behavioral details, error conditions, and a fuller description of the return value. The agent may not know how to handle failures or interpret the output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage (no descriptions within the schema properties), but the tool description provides an Args section that explains each parameter: coupling_type, physics_list, and model_name. It also lists valid coupling type names. This meaningfully supplements the schema, though it could provide more constraints or examples for the physics_list format.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Add a multiphysics coupling between physics interfaces.' It lists common coupling types, providing specific examples like ThermalStress and JouleHeating, which makes the purpose unambiguous. This distinguishes it from sibling tools that add individual physics interfaces or other operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit guidance on when to use this tool versus alternatives like physics_add_*. The description implies use when coupling physics interfaces, but does not specify prerequisites (e.g., the physics must already exist) or cases where it should not be used. The lack of exclusions or comparisons limits the agent's ability to select this tool appropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosure. It does not mention side effects (e.g., overwriting existing boundaries), required permissions, or validation behavior. The return value is vaguely described as 'Configuration confirmation' without specifics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear first sentence, a brief explanation, an Args list, and a Returns note. It is concise and front-loaded, though the Args section largely repeats parameter names without much additional context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 6 parameters, no output schema, and no annotations, the description covers inputs and basic functionality but lacks critical context like prerequisites (physics interface must exist), validation rules, and error handling. It is adequate but not fully comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description includes an 'Args' section explaining each parameter, including default values for 'inlet_velocity' and 'outlet_pressure'. This adds significant meaning beyond the bare schema, though it could clarify units and acceptable value formats.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it sets up Laminar Flow boundary conditions with inlet velocity and outlet pressure. It uses specific verbs ('Setup', 'configures') and distinguishes from sibling tools like 'physics_interactive_setup_flow' and 'physics_setup_heat_boundaries' by specifying the physics type and purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 like 'physics_interactive_setup_flow' or 'physics_boundary_selection'. It does not mention prerequisites (e.g., a Laminar Flow physics interface must be added first) or scenarios where this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for behavioral disclosure. It only states the basic action and parameters, omitting details about connection persistence, error handling, or side effects. This is insufficient for an operation that likely establishes a network connection.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, consisting of a clear purpose statement followed by a structured parameter list. 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.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the basic operation and parameters, and mentions return value type ('Connection info or error message'). However, it lacks context about the tool's role within the broader COMSOL workflow, such as the need for a server to be running or implications of multiple connections.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaningful information beyond the schema: 'port' is explained as 'Port number the COMSOL server is listening on', and 'host' as 'Server hostname or IP address (default: 'localhost')'. Given the schema's 0% parameter description coverage, this compensation is effective.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action ('Connect') and target ('a remote COMSOL server'). It effectively distinguishes this from sibling tools like comsol_disconnect and comsol_start, leaving no ambiguity about its core function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidelines are provided. The description does not specify when to use this tool versus alternatives (e.g., comsol_start, comsol_status), nor does it mention prerequisites or scenarios 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.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It lists return fields but does not disclose side effects (likely none) or edge cases like what happens if the knowledge base is not built. 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise: two sentences with no wasted words. Front-loaded with action and immediately followed by return details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given 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 is fairly complete for a simple status check. It covers the main output items, though could mention error cases or the safe read-only nature.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, so baseline score is 4. The description does not need to add parameter details and provides clear return information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get the status') and the resource ('PDF documentation search system'), and specifies the return items. It is distinguishable from siblings like pdf_search, though a brief differentiation would strengthen it.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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. For example, it does not suggest using it before pdf_search to ensure the knowledge base is loaded, which would be helpful.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility. It states the tool adds physics but lacks information about side effects, required prior state, idempotency, or whether existing heat transfer physics is replaced. 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, front-loading the main purpose in the first sentence. Parameters are listed clearly with defaults, and return info is mentioned. Every sentence serves a purpose without waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description provides minimal context for a tool with 2 parameters and no output schema. It does not explain the implications of adding heat transfer physics, required model state, or how the returned info can be used. Adequate but leaves gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description adds value by explaining domain_selection and model_name parameters, including defaults. However, it does not elaborate on valid selection names or behavior, remaining at a baseline level.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with a specific verb 'Add' and resource 'Heat Transfer physics', clearly distinguishing it from sibling tools like physics_add_electrostatics or physics_add_solid_mechanics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for adding heat transfer physics but provides no explicit guidance on when to use this tool versus alternatives such as physics_add or other physics-specific tools. No criteria or prerequisites are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
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 auto-generation for feature_name but does not describe side effects, reversibility, permissions, or rate limits. Limited transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured as a clear list of parameters with defaults, front-loaded with the action. It is efficient but could be more concise by removing redundant phrasing like 'in meters' repeated.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 6 parameters, no output schema, and no annotations, the description covers parameter semantics and return info. However, it lacks usage context and behavioral details, making it adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, so the description compensates by explaining each parameter's meaning, units (meters), and defaults. This adds significant value beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Add a rectangle') and the target ('2D geometry or work plane'), distinguishing it from sibling tools like geometry_add_block or geometry_add_circle.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does 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 over alternatives, such as choosing a rectangle instead of a block or circle. It implies usage for rectangles but lacks comparative context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It only states 'list' but does not disclose that it is a read-only operation, any prerequisites (e.g., model must exist), or error behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, using only three sentences plus a structured Args/Returns section. Every sentence is necessary and to the point.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple listing tool, the description adequately defines input and output. It could mention that the model must be currently loaded, but that is implicit given the context. The return value is specified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage. The description adds value by explaining the parameter 'model_name' with its default behavior ('default: current model'), compensating for the schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does 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 ('all geometry sequences in a model'). It distinguishes from sibling tools like geometry_list_features by focusing on sequences.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 geometry_list_features or geometry_get_boundaries. The description does not provide any context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must carry the burden. It discloses that it returns module names with file counts, which is adequate for a simple read-only list operation, but no additional behavioral context like idempotency 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no redundant information. Perfectly concise and directly states purpose and output.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters, no output schema, and a straightforward listing task, the description fully covers what the tool does and returns.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters, so schema coverage is 100% by default. The description adds no extra parameter details, but none are needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists all available COMSOL documentation modules and specifies return format (module names with file counts). However, it does not differentiate from sibling tools like `docs_list` which may also list documentation items, but the `pdf` prefix suggests a specific scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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., `docs_list`, `pdf_search`). No context or prerequisites provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description bears full burden. States action but lacks details on side effects, error conditions, or response structure. Minimal disclosure beyond basic operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with sections for description, common types, Args, and Returns. Front-loaded main purpose. Slightly verbose with extensive type list, but overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers basic parameters and return type but omits error handling, model prerequisites, and detailed return schema. Adequate for simple use but insufficient for complex scenarios, especially given sibling tools requiring differentiation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description adds meaningful explanations for all three parameters: examples for physics_type, defaults for component_name and model_name. Lacks constraints or enumerated values but significantly compensates for schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clear verb 'add' with resource 'physics interface'. Distinguishes from specific sibling tools like `physics_add_electrostatics` by listing common physics types as examples, indicating it's a generic alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides physics type examples and defaults for optional parameters, but does not explicitly state when to use this generic version versus the specific `physics_add_*` alternatives. No exclusion criteria or when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
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 the return value ('Export confirmation with file path'), but omits potential side effects, authorization needs, or error conditions. This is insufficient for a tool with no annotation safety net.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with the core purpose. It includes an Args section and Returns section, but the formatting is standard and could be slightly tighter. Overall, it earns its space without unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given 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 mentions the return value. However, it does not address edge cases like overwriting existing files or invalid node_name, nor does it explain the export format or dependencies. The tool's role in a COMSOL-like environment suggests more detail would be helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaningful context for all three parameters (node_name, file_path, model_name), including examples for file_path and a default for model_name. Since the schema has 0% description coverage, this compensates well, though the parameter names are already somewhat self-explanatory.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Export a plot as an image,' which specifies the verb (export), resource (plot), and output type (image). This distinguishes it from sibling tools like results_export_data (exports data) and results_plots_list (lists plots).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for exporting plot images but provides no explicit when-to-use or when-not-to-use guidance. No alternatives or exclusions are mentioned, leaving the agent to infer context from the sibling tool list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only states basic action and return. Missing details on side effects (e.g., if a session already exists), resource consumption, or blocking behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences for purpose, followed by a clear parameter list. No redundant information; every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and lack of output schema, the description is adequate but minimal. It could mention behavior on re-invocation, installation requirements, or session uniqueness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning beyond the input schema by explaining the 'cores' and 'version' parameters, including defaults (all available cores, latest installed version). This compensates for the 0% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Start a local COMSOL client session,' specifying a verb and resource. It distinguishes from sibling tools like comsol_connect and comsol_disconnect by focusing on initiating a session.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for starting a local session but does not provide explicit when-to-use or when-not-to-use guidance, nor does it mention alternatives like comsol_connect.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It states creation and containers role but omits side effects (e.g., duplicate component behavior), permissions, or return value details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with a clear opening sentence. The Args section is somewhat redundant but not overly long. Could integrate parameter info more efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 2 params and no output schema, the description covers the core purpose and preconditions. However, it lacks error handling, explanation of 'current model', or what happens on re-creation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so description must compensate. It redundantly repeats the default values already in schema and adds only minimal context ('default: current model'). Does not explain 'model_name' null behavior or validation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates a component and establishes it as a prerequisite for geometry/physics, distinguishing it from sibling tools like geometry_create or mesh_create.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'required before adding geometry/physics' and 'Must be created before adding geometry or physics', providing clear usage context. It does not discuss when not to use it, but the priority is evident.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses the interactive nature (prompts user, configures boundaries) and mutation implied by 'configures'. However, it does not clarify if modifications are reversible, permission needs, or behavior in headless mode. Adds moderate value beyond structured fields.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Description is well-structured with summary, enumerated steps, and clearly labeled Args/Returns sections. No redundant information, sentences are concise and front-loaded. Achieves clarity with minimal text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
At 2 optional parameters, moderate complexity. Description explains the wizard flow but lacks details on edge cases (no boundaries found, user cancellation), return format specifics (no output schema), and prerequisites (e.g., model must have a geometry). Vague 'Boundary information and setup instructions' returns.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 0% coverage, but description provides an Args section with brief descriptions for both parameters (e.g., 'Name of the Laminar Flow physics interface' for physics_name). This adds meaning beyond schema defaults and types, though could include constraints like valid physics names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it is an interactive setup wizard for Laminar Flow boundary conditions, with specific steps (list boundaries, prompt user, configure). This distinguishes it from sibling tools like physics_interactive_setup_heat (for heat transfer) and physics_setup_flow_boundaries (which likely automates the same task).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Description implies interactive usage but does not explicitly state when to use this tool versus the automated alternative physics_setup_flow_boundaries. No guidance on prerequisites, context, or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Only states it lists nodes and returns names. No disclosure of side effects, authorization needs, or prerequisites (e.g., model existence). A read operation but not explicitly stated as safe.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise: two sentences plus structured Args/Returns. Front-loaded with purpose, no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a simple list tool with one optional parameter and no output schema. However, lacks context on what export nodes are, error conditions, or relationship to export actions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Adds clarity to model_name parameter: 'Model name (default: current model)' goes beyond schema's title. Explains optionality and default behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'List all export nodes defined in a model', specifying verb, resource, and scope. Distinct from sibling tools like results_export_data and results_export_image.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies usage for listing export nodes before exporting, but no explicit when-to-use or when-not-to-use guidance. No mention of alternatives or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/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 a list operation, which is implicitly read-only and non-destructive, but it does not explicitly state these traits or any other behavioral details such as error conditions or required model state.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: a single-line summary followed by brief Args and Returns sections. It front-loads the core purpose and avoids any unnecessary words, earning its place efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description adequately covers the one parameter and return value for a simple list tool. However, it lacks context about prerequisites (e.g., model must be loaded), error handling, or any distinctions from similar sibling tools, leaving some gaps for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, but the description's Args section adds meaning by stating 'Model name (default: current model).' This clarifies the parameter's role and default behavior, which the schema alone does not convey.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'List all plot nodes defined in a model.' This clearly identifies the action (list) and resource (plot nodes), and distinguishes from sibling list tools like results_exports_list by specifying 'plot nodes'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention context, prerequisites, or exclusions, leaving the agent to infer usage solely from the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must disclose all behavioral traits. It mentions cancellation and a delay in response, but fails to specify side effects (e.g., whether partial results are preserved), safety of multiple calls, or behavior when no operation is running.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Description is extremely concise with two sentences and a return line, all front-loaded with the primary action. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description is somewhat complete for a simple action, but lacks detail on the return value structure and missing behavior edge cases like no active solving operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has zero parameters and schema coverage is 100%, so description does not need to explain parameters. Baseline score of 4 applies as there is no additional parameter info required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool cancels the current solving operation, with a specific verb 'Cancel' and resource. This distinguishes it from sibling tools like study_solve (starts solving), study_get_progress, and study_wait.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Description implicitly indicates use when there is an ongoing solving operation, but does not explicitly state when not to use or compare with alternatives like study_wait or study_solve_async. The note about solver delay gives some guidance on behavior but not on selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It mentions returns (status, percentage, elapsed time) but does not disclose whether it is read-only, non-blocking, or require an active operation. Lacks detail on behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two succinct sentences, front-loaded with purpose. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a simple getter with no parameters, but lacks explanation of edge cases (e.g., no active operation, error behavior) and does not describe return format in full.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters, so baseline 4. Description adds meaning by stating what the tool returns, which is beyond the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets progress of the current solving operation, with specific verb 'Get' and resource 'progress'. It distinguishes from siblings like study_solve or study_cancel by focusing on progress retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage after starting a solve operation (e.g., study_solve_async) but does not explicitly state when to use or not use it, nor mention alternatives like study_wait for waiting instead of polling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description specifies the default model is used if not provided, implying a read operation. However, it does not explicitly state that the tool is non-destructive or safe, nor does it mention any side effects. No annotations are present to contradict.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with a clear first sentence stating the purpose, followed by structured args and returns. It avoids unnecessary detail while being informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple listing tool with one optional parameter and no output schema, the description adequately covers purpose, parameter, and return value. It could mention if a model must be loaded, but is otherwise complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description explains the parameter 'model_name' includes its default value (current model), adding meaning beyond the input schema which only provides the title and type. This clarifies the optional behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists all studies in a model, with a specific verb (list) and resource (studies in a model). It is distinct from sibling tools like study_solve or model_list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 study_get_progress or when listing studies is appropriate. No exclusions 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.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It states the tool returns documentation content and lists available topics. However, it does not disclose behavior for invalid topics, potential errors, or whether the content is static or updated. The simplicity of the tool limits the need for extensive disclosure, so a score of 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: a one-sentence purpose, a bulleted list of available topics, and clear args/returns. Every sentence adds value with no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given 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), the description covers all essential aspects: what the tool does, what topics are available, and what is returned. It is complete for its context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides no description for the 'topic' parameter (0% coverage). The description compensates by listing three valid topic values ('mph_api', 'physics_guide', 'workflow') and briefly explaining each, adding significant meaning beyond the schema structure.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Get documentation on a specific topic' and lists three available topics, clearly defining the tool's purpose. However, it does not explicitly distinguish itself from the sibling 'docs_list' tool, leaving the differentiation implied rather than stated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage (use when you need content for a specific documentation topic) but does not provide explicit guidance on when to use this tool versus alternatives like 'docs_list' or 'pdf_search'. No when-not or exclusion criteria are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully convey behavioral traits. It states 'Add' (creation) and lists defaults, but does not disclose prerequisites (e.g., existing geometry), side effects, permissions, or error handling. The description 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Very concise: a one-line purpose followed by a bullet-point Args list and a Returns line. Every sentence adds value without redundancy. The structure is clean and easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema or annotations, the description covers all 7 parameters with defaults and context. It lacks details on preconditions (e.g., geometry must exist, model must be current) and the exact return structure, but is adequate for a straightforward addition tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaningful context beyond the input schema: it specifies units (meters for position, radius, height) and notes auto-generation for feature_name. Although the schema provides types and defaults, the description clarifies physical meaning and behavior like auto-naming.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Add a cylinder to the geometry.' The verb 'add' and resource 'cylinder' are specific, and the tool name includes 'geometry_add_cylinder', which distinguishes it from siblings like geometry_add_block or geometry_add_sphere.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives (e.g., adding a block or sphere). Usage context is implied by the tool name and description, but no exclusion or when-not-to-use information is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full burden. It states the operation creates a difference and mentions default behaviors (e.g., feature_name auto-generated). However, it does not disclose whether the operation is destructive, reversible, or requires specific model states.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description uses a clear docstring format with Args and Returns. It is moderately concise but could be slightly shorter for an AI agent (e.g., simplified examples). No wasted sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the main functionality and parameter explanations. However, it lacks details on edge cases (e.g., non-intersecting objects), error handling, or the return value structure beyond 'difference operation info'. Given no output schema, more context would help.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It provides meaningful examples (e.g., 'blk1', ['cyl1']) and explains default values for optional parameters. This adds significant value beyond the schema, though some parameters (e.g., geometry_name) could be further clarified.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The name and description clearly indicate the tool performs boolean difference (subtract objects). The description explicitly states 'Create a boolean difference (subtract objects from another)', and it distinguishes from sibling 'geometry_boolean_union' by specifying subtraction rather than union.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides basic usage (e.g., what each parameter represents) but does not specify when to use this tool over alternatives like boolean union or other geometry operations. There is no guidance on prerequisites or conditions for use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description mentions that the tool generates the actual geometry and returns a build status, but it does not disclose potential side effects, whether it modifies state, or behavior on repeated calls. With no annotations, the description carries the full burden and could provide more insight.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the main purpose. The docstring-style listing of arguments and returns is well-structured but could be slightly more compact.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the three parameters, no output schema, and no annotations, the description covers the essential use case but lacks details about return value format, error conditions, or relationship to other build-related tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, so the description must compensate. It lists parameters with defaults but adds little beyond the schema: it clarifies that geometry_name defaults to building all, but does not explain the purpose or constraints of each parameter in detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool builds the geometry sequence, distinguishing it from sibling tools that add or modify geometry features. It uses a specific verb ('build') and specifies the resource ('geometry sequence') and its role in generating actual geometry.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states that this tool must be called after adding/modifying geometry features, providing clear context for when to use it. However, it does not explicitly state when not to use it or reference alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
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 the tool modifies a model parameter and returns confirmation or error, but lacks details on side effects, validation, or prerequisites. 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence followed by a structured Args list. It is front-loaded and contains no superfluous information, earning its place efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and sparse annotations, the description covers the essential functionality for setting a parameter. However, it omits details about default model behavior and parameter existence validation, which could be helpful for complex use cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description's Args section compensates well by explaining the value format (units like '5[V]') and optional parameters. This adds meaning beyond the schema's type-only definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Set the value of a model parameter,' which is a specific verb-resource combination. This distinguishes it from sibling tools like param_get (get value) and param_list (list parameters).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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. Given siblings like param_sweep_setup, explicit context on when to use this for single parameters would improve usability.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It explains the search is semantic and mentions defaults and optional filter, but does not disclose behavioral traits like whether it is read-only, rate limits, error handling, or what happens with no results. Basic 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured with a clear purpose statement followed by structured Args and Returns sections. It is not overly verbose and front-loads the main action. However, it could be slightly more concise by omitting obvious details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given 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 covers the main functionality but lacks details on return format (snippets?), error handling, or pagination. For a search tool with 3 parameters, 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.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds meaning for all three parameters: query (search query), n_results (default 5, max 20), and module (optional filter). This goes beyond the bare schema and provides useful constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches COMSOL PDF documentation using semantic search, specifying the resource (PDF docs) and action (search). It also mentions the scope (60+ modules, physics, modeling, API usage), distinguishing it from sibling tools like docs_get or docs_list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides basic usage context via Args and Returns but does not explicitly compare with sibling tools or state when to use this tool versus alternatives like pdf_list_modules or pdf_search_status. It implies usage for finding information but lacks exclusions or guidance on 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.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully inform about behavioral traits. It states the tool returns a 'quick reference guide' but does not specify the format (e.g., string, object), whether it is read-only, or any side effects. The description is vague about the exact behavior 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, using a single introductory sentence followed by bullet points for available physics types, and clearly labeled 'Args' and 'Returns' sections. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool with no output schema, the description covers the input thoroughly but lacks detail on the output structure or format of the guide. It is adequate but leaves some ambiguity about what the agent will receive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema defines physics_type as a string with 0% coverage, but the description compensates by listing all four valid values and their meanings (e.g., 'electrostatics: Electric field and capacitance'). This adds crucial semantic information beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'Get a quick guide for a specific physics type' and lists four distinct physics types with brief explanations. This clearly identifies the tool's purpose and differentiates it from sibling tools like physics_add_* or physics_list, which serve different functions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by listing available types and stating what the tool returns, but it does not explicitly state when to use this tool versus alternatives such as physics_get_available or physics_list. No guidance on when not to use it is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It implies a read operation with no destructive effects, but does not disclose any behavioral traits beyond this. It does not mention side effects, authentication, or rate limits, but for a simple listing tool, the transparency is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise with no unnecessary words. It follows a clear structure: a brief statement of purpose, then an Args section and Returns summary. Every sentence is informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and lack of output schema, the description covers the main purpose and the parameter. It explains the return value as 'List of physics interface names'. It does not elaborate on what constitutes a physics interface, which may be assumed domain knowledge.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema description coverage, the description adds meaning by specifying that model_name defaults to 'current model', which is not in the schema. This provides useful context beyond the bare parameter definition.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List', the resource 'physics interfaces', and the scope 'in a model', distinguishing it from sibling tools like physics_list_features (which lists features of an interface) and physics_get_available (which lists available interfaces).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as physics_get_available or physics_list_features. The description lacks context for when this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
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 the return is a confirmation with file path but omits important details like error handling if the export node doesn't exist, required permissions, or side effects (e.g., whether it modifies state). Basic information is present but insufficient for a comprehensive understanding.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: one sentence for the main action, a brief list of arguments with defaults, and a one-line return description. No redundant words; every sentence serves a purpose. It follows the principle of front-loading the key action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema and minimal annotations, the description explains the tool's operation adequately for a simple export function. It covers parameter defaults and overrides. However, it lacks guidance on when to choose this export over alternatives (e.g., results_export_image) and does not describe potential side effects, which slightly reduces completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, so the description compensates well. It explains the meaning of node_name (export node name, default run all exports), file_path (output file path, overrides node setting), and model_name (model name, default current model). This adds significant value beyond the schema's bare property names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Export data from an export node,' which is a specific verb+resource combination. This distinguishes it from sibling tools like results_export_image (image export) and results_evaluate (evaluation). No ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides default behaviors for parameters (e.g., node_name defaults to run all exports) and explains file_path overrides. However, it does not explicitly state when to use this tool versus alternatives (e.g., results_export_image) or when not to use it. The context is clear but lacks exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It lacks disclosure of behavioral traits such as whether the tool modifies any state, requires authentication, or has rate limits. It only states it returns suggestions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, well-structured with bullet points for error types and clear parameter documentation. Every sentence serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given 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 covers return values ('Troubleshooting suggestions'). It could include example output format, but not essential for a straightforward tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, the description adds meaningful semantics: it defines 'error_type' as the type of error encountered with a list of common values, and 'context' as additional information. This goes beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool provides troubleshooting suggestions for common issues, listing specific error types. This verb+resource combination is distinct from sibling tools like comsol_connect or physics_add.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when encountering listed error types, but does not explicitly state when to use this tool versus alternatives or provide 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.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the verb 'Get' and description imply a read-only, non-destructive operation. However, it does not explicitly state that it has no side effects, which would be expected given 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no wasted words. The purpose is front-loaded, and return information is listed clearly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple status tool with no parameters and no output schema, the description adequately covers what is returned (connection status, version, loaded models). It is complete for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and schema coverage is 100%. The description does not need to add parameter details; baseline of 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get the current COMSOL session status' and specifies return details (connection status, version, loaded models). It distinguishes from sibling tools like comsol_connect and comsol_start.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 comsol_connect. The description does not mention prerequisites (e.g., active session) or when not to use it, leaving the agent without context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden; it states it lists all mesh sequences but lacks details on side effects or return format specifics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, well-structured with Args and Returns, and front-loaded with the key action statement.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one optional parameter and no output schema, the description sufficiently explains what it does and what it returns.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning by specifying 'Model name (default: current model)', which compensates for 0% schema description coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List' and the resource 'mesh sequences in a model', distinguishing it from sibling tools like mesh_create and mesh_info.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 prerequisites (e.g., model must be loaded) 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.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes return value (model info or error message) and the set_current parameter effect, but does not disclose side effects, dependencies, or whether it overwrites existing models. No annotations provided, so description carries the burden but is only partially complete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Concise, front-loaded summary, with clear Args and Returns sections. Every sentence is necessary and no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple load operation, it covers key aspects: parameters, return value. Could mention prerequisite of an active COM connection (comsol_connect) and potential error states, but overall adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Provides meaningful descriptions for both parameters beyond the input schema (which had only titles): explains file_path as absolute/relative path to .mph file, and set_current as whether to set as current active model with its default. Schema coverage was 0%, so description fully compensates.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clear verb 'Load' and resource 'COMSOL model' with source '.mph file'. Distinct from siblings like model_create and model_clone.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 like model_create or model_clone. Does not mention prerequisites (e.g., need an active COM connection from comsol_connect).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses the return type (a dictionary), but does not mention whether it is read-only or safe, though it is inherently a non-destructive listing. Slightly unclear about potential 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with just two short sentences, front-loaded with the main action, and every word adds value. No unnecessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given 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 fully covers what the tool does and what it returns. It is complete for an agent to understand and use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters (schema coverage 100%), so the description is not required to add parameter details. It adds value by explaining the tool's purpose and return type, which is sufficient for a zero-parameter tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves a list of available physics interfaces organized by category, using a specific verb and resource. It distinguishes from sibling tools like physics_add or physics_get_guide, which have different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 over alternatives, nor does it mention prerequisites or conditions. While the context implies use before adding a physics interface, this is not stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses that models are cleared from memory but does not mention potential side effects (e.g., unsaved work lost) or prerequisites (e.g., save models first).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, zero wasted words. The return type and message are included efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given 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 covers the action and return value well. Some context on when to disconnect (e.g., after a session) would improve completeness, but it is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so baseline 4. Description adds no parameter info, which is appropriate given zero parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific verb 'Disconnect' and resource 'COMSOL', plus additional detail 'clear all models from memory'. It clearly distinguishes from siblings like comsol_connect and comsol_start.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does 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. The purpose is implied by the name and sibling context, but no when-not or explicit usage guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description fully bears the responsibility. It describes the tool as a query that 'gets best practices' and returns them, which is non-destructive. However, it does not disclose any behavioral traits such as rate limits, authentication needs, or side effects beyond the obvious read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise and well-structured with a bullet list, clear Args/Returns sections, and no redundant text. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has only one string parameter and no output schema, the description is nearly complete. It explains what the tool does, what to provide, and what to expect back. Minor improvement could be made by specifying that category values are case-sensitive or must match exactly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It lists five valid category values with a one-line explanation each, adding meaning beyond the bare schema. However, it does not explicitly state that these are the exact allowed string values or specify case sensitivity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get best practices for different modeling categories.' It lists five specific categories with brief explanations, distinguishing it from sibling tools as the only one dedicated to best practices.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does 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 is provided. Usage is implied by the tool's unique purpose, but the description does not mention when-not-to-use or suggest alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
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 save action, defaults, format options, and return type. However, it omits side effects (e.g., overwriting behavior) or required environment (e.g., connected Comsol session), leaving moderate gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise: a one-line purpose, then args with defaults, then returns. Every sentence adds value with no redundancy. It is front-loaded with the core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 3 optional parameters, no output schema, and no annotations, the description covers the return type ('Save confirmation with file path, or error message'). It is complete enough for a save operation, though details on error conditions or format implications are missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description lists all three parameters with defaults and, for format, enumerates possible values ('Comsol', 'Java', 'Matlab', 'VBA'). This adds significant meaning beyond the schema's titles, though some constraints (e.g., file path format) are absent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Save a COMSOL model to file,' specifying the verb (save), resource (COMSOL model), and destination (file). This distinguishes it from sibling tools like model_save_version, which focuses on version tracking.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides defaults for all parameters (e.g., current model, original file path, Comsol format) but lacks guidance on when to use this tool versus siblings like model_save_version. No explicit when/when-not or alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It states the tool waits with a timeout (None for indefinite) and returns final progress status, but does not detail behavior on timeout or if no operation is active. 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: one sentence for purpose, clear Args/Returns. Every sentence earns its place; no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given low complexity (1 param, no output schema, no annotations), the description covers core behavior: purpose, parameter, return. Missing details on timeout behavior and error cases, but sufficient for a simple wait tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description must compensate. It explains timeout as 'Maximum time to wait in seconds (None for indefinite)', adding meaning beyond schema type and default.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Wait for the current solving operation to complete' uses a specific verb ('Wait') and identifies the resource ('solving operation'), clearly distinguishing it from siblings like study_solve (initiates solving) and study_cancel (cancels).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does 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 (e.g., study_solve, study_solve_async). The description implies usage after starting an asynchronous solve but lacks when-not or alternative suggestions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description itself discloses the core behavior (listing components). However, it does not explicitly state that the tool has no side effects or is read-only, though it is reasonably inferred. Lacks depth but is minimally adequate for a simple list operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two lines for the core action, plus structured Args and Returns sections. Every sentence adds value, and the format is easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (one optional parameter, no output schema), the description fully covers what a user needs: what it lists, how to specify the model, and what is returned. No gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, but the description compensates by explaining the 'model_name' parameter's default behavior ('default: current model'), which the schema only shows as 'default: null'. This adds meaningful context beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List' and resource 'components in a model', making the purpose unambiguous. It also distinguishes itself from sibling tools like 'model_list' (lists models) and 'model_create_component' (creates components).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage as a tool to inspect model composition, but provides no explicit guidance on when to use this tool versus alternatives, nor any conditions or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explains the effect of the 'evaluate' parameter (numerical values vs. expressions) and the return format (dictionary). Since no annotations are provided, the description carries the full burden and adequately discloses the tool's behavior, though it could mention that 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with a front-loaded purpose sentence followed by clearly structured Args and Returns sections. No extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the return type (dictionary of parameters) and parameter effects. Given no output schema, this is sufficient for a list tool, though it could include an example or mention potential errors.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description fully compensates by explaining both parameters: 'model_name: Model name (default: current model)' and 'evaluate: If True, return numerical values; if False, return expressions'. This adds essential meaning beyond the schema's type and default.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List all parameters in a model,' providing a specific verb (list) and resource (parameters in a model). This distinguishes it from sibling tools like param_get (specific parameter) or param_set.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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., param_get for a single parameter). The description does not mention exclusions or context for usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
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 defaults and returns a confirmation, but does not explain whether it overwrites existing boundaries, whether it requires an existing physics interface, or what happens on error.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a summary, bullet list of boundary types, and an Args section. It is concise, using clear sections and no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 9 parameters and no output schema, the description covers the main aspects. However, it lacks mention that boundary lists expect integer IDs, and does not address validation or error conditions. The optional model_name is explained implicitly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds significant meaning: it explains the role of each boundary list, provides default values with units, and gives temperature in Celsius for context. This fully compensates for lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool sets up heat transfer boundary conditions, specifying three types (heat flux, temperature, convection). It distinguishes from sibling tools like physics_setup_flow_boundaries by focusing on thermal boundaries.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description lists the types of boundaries but does not explicitly state when to use this tool versus alternatives or prerequisites (e.g., needing a heat transfer physics already added). The context from sibling names suggests it's for heat, but no direct guidance is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/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 mentions the return type (list of boundaries with numbers and areas) and default parameter values, but does not explicitly state that the operation is read-only or non-destructive. 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: two sentences plus succinct parameter descriptions. It is front-loaded with the purpose and uses no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 optional params, no nested objects, no output schema), the description covers the functionality, usage context, and parameters adequately. The return format is briefly described, but could be more explicit. Overall, it is complete enough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains both parameters: geometry_name as 'Geometry sequence name (default: first geometry)' and model_name as 'Model name (default: current model)'. This adds meaning beyond the bare schema, though it doesn't detail allowed values or format.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'boundaries from a geometry', and explains its purpose to identify boundary numbers before setting boundary conditions. This distinguishes it from sibling tools like geometry_add_block or physics_boundary_selection.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use this to identify which boundary numbers correspond to which faces before setting boundary conditions,' providing clear context for when to use it. It doesn't state when not to use, but the guidance is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/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 discloses the core cloning action and the set_current parameter effect, but lacks details on side effects (e.g., impact on original model, permissions, disk usage) and return value specifics beyond 'Info about the cloned model'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured, with a brief purpose statement followed by organized parameter and return documentation. Every sentence serves a purpose with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers parameter semantics and return type, but lacks details on the cloning process (e.g., whether it's a deep copy, what data is preserved) and prerequisites. Given no output schema and the tool's complexity, more context would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description includes a detailed Args section explaining each parameter's meaning and default behavior, adding significant value beyond the input schema which has 0% description coverage. For example, it clarifies that model_name defaults to the current model and new_name is auto-generated if not provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('clone') and the resource ('model'), with a specific purpose ('create a copy for comparison or modification'). It distinguishes from siblings like model_create by indicating duplication rather than creation from scratch.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool ('to create a copy for comparison or modification'), but does not explicitly state when not to use it or mention alternatives. It provides clear context without exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description discloses key behaviors: it returns a parameter value and an optional description, and the 'evaluate' flag controls whether a numerical value or expression string is returned. It does not detail error handling or performance, but the core behavior is well explained.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured with Args and Returns sections, front-loading the main purpose. Every sentence adds value, and there is no redundancy or fluff. 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.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (3 parameters, no output schema), the description covers the primary functionality: retrieving a parameter value with optional model name and evaluate flag. It mentions the return format (value and description or error), which is sufficient. However, it could elaborate on error message structure or data types.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description carries the full burden. It explains all three parameters: 'name' (parameter name), 'model_name' (default current model), and 'evaluate' (controls return type). This adds meaningful semantic information beyond the schema, though examples or accepted values are missing.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get the value of a model parameter', which is a specific verb and resource. It distinguishes itself from sibling tools like param_list (lists all parameters) and param_set (sets a parameter) by focusing on retrieval of a single parameter.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving a parameter value but provides no explicit guidance on when to use this tool versus alternatives such as param_list or param_description. No exclusions or context are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It mentions async behavior and returns confirmation but does not disclose side effects (e.g., if study already running, overwrite behavior, prerequisites).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise with two sentences for purpose and usage, then Args and Returns. No unnecessary words, front-loaded with main action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, parameters, and return. Lacks error details and behavior when study_name is None (all studies?), but sufficient for async action. Sibling tools are many, but description differentiates well.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description must explain parameters. It adds meaning by describing study_name as 'Study to solve (None for all studies)' and model_name as 'Model name (default: current model)', which goes beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool starts solving a study asynchronously, using 'Start solving a study in the background (asynchronous).' It distinguishes from siblings by referencing related progress and cancel tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says when to use (async solving) and points to alternatives (study_get_progress, study_cancel). Does not explicitly state when not to use, but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Given no annotations, the description carries the full burden. It discloses that creation sets the model as current by default, the name is optional, and the return includes model info. However, it doesn't mention prerequisites like a connection or potential side effects beyond setting current.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured with Args and Returns sections. Every sentence serves a purpose without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description adequately explains the creation of a new model and return value. It lacks mention of prerequisites (e.g., connection state) and error handling, but given the tool's simplicity, it is mostly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description fully compensates by explaining that 'name' is auto-generated when omitted and 'set_current' determines whether the model becomes active. This adds meaningful context beyond the schema's type information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Create a new empty COMSOL model' with a specific verb and resource, distinguishing it from siblings like model_clone or model_load.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does 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 (e.g., model_load), but the purpose is clear enough that usage is implied. No exclusion criteria or alternative suggestions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description discloses the file creation behavior, including the exact path structure and the creation of a 'latest' copy. It mentions the return value (confirmation with path or error). It does not detail overwrite behavior for the 'latest' copy or permissions, but covers the core actions adequately.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear action statement, path details, usage note, argument list, and return value. It is concise and front-loaded with the core purpose. No redundant sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with two optional parameters and no output schema or annotations, the description covers purpose, arguments, behavior, and return value. It could mention error handling or directory creation, but overall provides sufficient context for an agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description compensates by explaining both parameters: 'model_name' is the name to save (default current model), and 'description' is optional metadata. This adds meaning beyond the schema's basic type and default info.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool saves a model with a timestamp version suffix, creating structured versioned files and a 'latest' copy. It distinguishes from sibling tool 'model_save' by adding versioning functionality, and mentions version control and design iterations as use cases.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description notes the tool is 'useful for version control and design iterations', implying when to use it over a plain save. However, it does not explicitly state when not to use it or compare with alternatives like 'model_save', though 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.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose behavioral traits. It explains arguments and returns but lacks details on side effects, error handling, or what happens if geometry sequence already exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, front-loaded with purpose, includes a clear section for arguments, and an important usage note. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the 4 parameters with no schema descriptions, the Args section covers them well. The Returns statement is vague but acceptable. It distinguishes itself from many sister tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description's Args section explains each parameter's meaning and defaults, adding significant value beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Create a new geometry sequence in the model's component.' It uses a specific verb and resource, distinguishing it from sibling tools like geometry_add_block that add individual shapes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly warns that a component must exist first and suggests using model_create_component if needed, providing clear when-to-use guidance and an alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the read-write behavior (get or set) and explains the conditional logic based on the 'text' parameter. It also states the return values: description or confirmation. With no annotations provided, the description carries the full burden and does so adequately, though it omits potential side effects or prerequisites.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and structured with clear sections (Args, Returns). Every sentence serves a purpose, and there is 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.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 3 parameters, no annotations, and no output schema, the description is fairly complete. It explains the two modes of operation, required parameters, and expected returns. Minor omissions like prerequisites (e.g., loaded model) or examples are acceptable for a tool of this scope.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although the input schema has 0% description coverage, the description adds meaning for each parameter: 'name' is the parameter name, 'text' is the new description (or None to get current), and 'model_name' is the model name with a default. This adds value beyond the schema's bare parameter names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool gets or sets a parameter's description, using specific verbs and resource (parameter description). This distinguishes it from sibling tools like param_get (gets parameter values) and param_set (sets parameter values), which are about parameter values rather than descriptions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly indicates when to use each mode: when text is None, it retrieves the description; when text is provided, it updates it. While it does not explicitly state when not to use this tool or list alternatives, the behavior is self-explanatory given the context of sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, but the description fully discloses the tool's behavior: it lists available documentation topics and their descriptions. It implies a read-only operation with no side effects, which is adequate for this 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two sentences: the first states the purpose, the second specifies the return value. No unnecessary words; every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given 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 fully covers what the tool does and what it returns. It is complete for an agent to understand and invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does 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% (empty). The description does not need to add parameter information, so it performs its role adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'List' and resource 'documentation topics', clearly stating the tool's action. It distinguishes itself from siblings like 'docs_get' (which retrieves a specific topic) and 'pdf_list_modules' (which lists PDF modules).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description is clear about its function (listing all topics), and the tool has no parameters, making usage straightforward. While it doesn't explicitly state when not to use it, the context implies it's for browsing available topics before using 'docs_get'. No sibling tool duplicates this function.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
GitHub Badge
Glama performs regular codebase and documentation scans to:
- Confirm that the MCP server is working as expected.
- Confirm that there are no obvious security issues.
- Evaluate tool definition quality.
Our badge communicates server capabilities, safety, and installation instructions.
Card Badge
Copy to your README.md:
Score Badge
Copy to your README.md:
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/HBPEKING-TKS/mcp_server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server