ANSYS MCP Server
Server Quality Checklist
Latest release: v0.2.0
- Disambiguation4/5
Domain prefixes (geometry_, mechanical_, fluent_) clearly separate tools, and within each domain actions like apply_load, solve, and get_result are distinct. The only potential overlap is between geometry_import_file and mechanical_import, but their descriptions clarify the active model.
Naming Consistency4/5Tool names follow a domain_verb_noun snake_case pattern, which is predictable. However, retrieval verbs vary ('list', 'get', 'read') and lifecycle verbs differ ('close' for geometry, 'exit' for mechanical/fluent), creating minor inconsistency.
Tool Count2/5With 41 tools, the server exceeds the 25+ threshold for 'too many' and may overwhelm agents. While the broad scope (Geometry, Mechanical, Fluent) justifies some size, the count is still heavy and would benefit from consolidation.
Completeness4/5Core workflows are covered: geometry creation/import/export, mechanical setup/solve/result, and fluent setup/solve/save. Minor gaps exist, such as no geometry editing/deletion and limited result types, but these are workable for typical simulation tasks.
Average 3.5/5 across 41 of 41 tools scored. Lowest: 2.1/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 5 commits in the last 12 weeks
- Last stable release on
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
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?
The description provides no behavioral details beyond the action. It doesn't state whether this modifies state, requires a prior launch/read, what happens on repeated calls, or any side effects. The annotations are neutral and don't add context, so the description carries the burden but fails to disclose anything.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, which is concise in word count, but it's under-specified. It doesn't structure any useful information; it's closer to a heading than a functional description.
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 tool has a simple schema with one optional parameter, but the description provides no context on how to use it, what the method choices mean, or what initializing entails. Despite having an output schema, the agent lacks the necessary context to invoke this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter (method) with an enum, but the description doesn't explain what 'method' does or how 'hybrid' vs 'standard' affect initialization. With 0% schema description coverage, the parameter is completely unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Initialize') on a resource ('the Fluent solution'), but adds little detail beyond the title/name. It does not distinguish this from many other Fluent tools like fluent_launch or fluent_read_case. The word 'solution' is ambiguous—could mean the computational setup, initial conditions, or something else.
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 vs alternatives. It doesn't mention prerequisites, typical use case, or any exclusions. The sibling tools include many Fluent operations, but the description offers no direction.
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 adds no behavior beyond the annotations, which are all false and thus convey little. It does not disclose side effects (e.g., whether iterations overwrite results, whether the solver is blocking, or whether a session must be already initialized). Annotations already declare readOnlyHint=false, but the description provides no additional context.
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 a single, grammatically correct sentence with no wasted words. However, it is so brief that it borders on under-specification rather than effective conciseness, providing minimal information for a tool in a complex workflow.
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 tool's role in a Fluent simulation workflow, the description omits critical context such as when to run it relative to reading a case, initializing, or solving. It does not mention that it likely requires an existing Fluent session. While an output schema exists, the description fails to cover usage context and integration with sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/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, but it mentions no parameters. The schema itself includes defaults and ranges for 'iterations' and 'timeout', but the description adds no meaning beyond those structured fields, leaving their semantic roles (e.g., number of iterations, total time limit) unexplained.
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 a clear verb ('Run') and resource ('Fluent solver iterations'), distinguishing it from siblings that launch Fluent, read cases, or get residuals. It does not explicitly compare with alternatives, but the action is specific enough to differentiate it from most sibling tools.
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. It does not mention prerequisites like an active Fluent session or case setup, nor any exclusions. The context is implied only by the tool name and description.
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 adds little beyond the annotations. It does not disclose side effects such as starting a local process, network connections, authentication requirements (despite the password parameter), or whether attaching vs launching affects state. Annotations indicate non-read-only, non-idempotent behavior, but the description fails to elaborate on these traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no extraneous words, but it is under-specified for a tool with 11 parameters. This is more under-specification than effective conciseness, as it omits critical 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?
Given the tool's complexity (11 optional parameters, output schema, and role in a larger Fluent workflow), the description is far too brief. It does not explain the return value, how to use this with subsequent fluent_* tools, or what configuration decisions are significant.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description offers no explanation for any of the 11 parameters. Schema coverage is only 9%, with only allow_insecure_remote described. The phrase 'Launch Fluent or attach to a gRPC instance' vaguely relates to ip/port parameters but does not clarify meaningful options like dimension, precision, processors, or replace.
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 uses a specific verb 'Launch or attach' and identifies the resource 'Fluent'/'gRPC instance', making the core action clear. However, it does not differentiate from sibling launch tools like geometry_launch or mechanical_launch, nor explain what 'attach to a gRPC instance' entails in practical terms.
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 instead of alternatives like geometry_launch or mechanical_launch. The description does not mention prerequisites, connection targets, or workflow 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?
Annotations already indicate the operation is not read-only, not destructive, and not idempotent. The description adds only that it launches a 'service', implying a persistent background process, but doesn't disclose side effects, license requirements, whether it blocks until ready, or the open-world implications suggested by openWorldHint=true.
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 a single sentence with no fluff, but it is under-specified. It is concise but at the cost of critical information. A bit more detail would be earned.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a launch tool with 4 parameters and an output schema, yet the description gives no context about what happens after launch, how to reference the service, or how it fits into the geometry workflow. Given the sibling tools, the agent is left guessing about sequencing.
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 the description carries no parameter information. While the schema provides names, types, defaults, and an enum for 'mode', it doesn't explain the meaning of 'replace' or 'timeout' in the launch context, and the description does nothing to clarify.
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 identifies the action (launch) and resource (Geometry service), and names the two supported modes (Discovery or SpaceClaim). This distinguishes it from sibling launch tools like mechanical_launch and fluent_launch. However, it doesn't explain what 'launch' entails or that it starts a persistent service.
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. It doesn't mention prerequisites such as needing an import file, or that geometry_launch should be called before geometry_create_* or geometry_list_bodies. There is no explicit statement about 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?
The annotation set provides no explicit safety hints (readOnlyHint=false, destructiveHint=false, idempotentHint=false), so the description must carry the burden. 'Set one boundary type and validated properties' implies a mutation and validation but does not explain side effects, whether existing properties are overwritten, or how validation failures are handled. This is insufficient for a modifying 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 a single, concise sentence with no fluff, and it is front-loaded with the verb 'Set.' However, its brevity may sacrifice necessary explanatory content, though that is a completeness issue rather than a structure issue.
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 tool has three parameters (including an open-ended object) and no schema descriptions, the description provides almost no contextual information. It does not mention requirements like a loaded Fluent case, how the output looks (though output schema exists), or how params should be formatted. For a configuration tool, this is inadequate.
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?
With 0% schema description coverage, the description was expected to compensate. It maps 'boundary type' to bc_type and 'validated properties' to params, but provides no details about acceptable bc_type values, the structure of the params object, or what 'zone' refers to beyond its name. The agent is left to guess valid parameter formats.
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 identifies the action ('set') and the resource ('boundary type and validated properties'), distinguishing it from sibling tools like fluent_set_solver or fluent_set_material. However, it does not explicitly mention the 'zone' parameter or that this applies to a specific mesh zone, leaving slight ambiguity about 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 is provided on when to use this tool versus alternatives such as fluent_tui or fluent_set_material. The description does not state prerequisites (e.g., a loaded case) or scenarios where this tool is preferred, leaving the agent without directional 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?
The description adds the behavior 'optionally create and evaluate one,' which is more specific than the annotation readOnlyHint=false. However, it does not disclose potential side effects, such as triggering a solve or modifying the state, which would be valuable for a tool with a false readOnlyHint.
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 single sentence with no redundancy, making it concise and front-loaded. It could be longer to add useful context, but the structure itself is efficient.
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 tool has an output schema (not shown) and a non-read-only annotation, the description is too sparse. It omits when to use, parameter details, and behavioral consequences. A more complete description would address the 'create and evaluate' flow and expected outputs.
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%. The description only indirectly alludes to the create_if_missing parameter via 'optionally create and evaluate one.' It does not explain result_type or analysis_index, leaving the parameters to be interpreted solely from schema titles and enums.
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's core function: 'Read an existing result or optionally create and evaluate one.' This specifies a verb and resource, and the distinction from sibling tools like mechanical_solve is implicit but not explicit. It could be clearer about the nature of 'results' but the input schema helps.
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. There is no mention of prerequisites, such as needing a solved analysis, or when to prefer other tools like mechanical_solve. The description gives no 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?
Annotations already declare destructiveHint=true, so the description does not need to restate destructiveness. It adds 'unsafe confirmation', which reinforces the danger and mentions the session-modification risk via the schema's confirm_unsafe description. However, it does not explain what kinds of modifications can occur, side effects, or whether the tool is reversible. The bar is lower due to annotations, so this is acceptable but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence that front-loads the action and the key safety requirement. Every word earns its place, and there is no redundant filler or repetition of schema details.
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 tool's high-risk nature (arbitrary execution, destructive hint), the description is too terse. It does not explain what Fluent TUI is, what commands are appropriate, how the session may be modified, or what happens after execution. Although an output schema exists, it is not shown in the provided text, and the description does not contribute enough context for a dangerous arbitrary-execution tool. The schema's confirm_unsafe hints at session modification, but the description should provide more guardrails and guidance.
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?
The schema has two parameters: 'command' (string, no description) and 'confirm_unsafe' (boolean with description). The description says 'arbitrary Fluent TUI', which implies 'command' holds the TUI command string, but it does not provide syntax, examples, or constraints beyond the schema's max length. With 50% schema coverage, the description should compensate for the undocumented 'command' parameter but only offers a vague connection.
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 uses the verb 'Execute' with the resource 'Fluent TUI', making it clear this tool runs arbitrary TUI commands. It distinguishes from siblings by the word 'arbitrary', implying a general-purpose fallback. However, 'Fluent TUI' is not defined, leaving some ambiguity about what exactly is being executed.
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 only mentions that execution requires 'explicit unsafe confirmation', which implies caution but does not state when to use this tool over the many specific fluent_* siblings. No alternatives, prerequisites, or exclusions are provided, leaving the agent without guidance on selecting this tool.
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 annotations are all false (readOnlyHint, openWorldHint, idempotentHint, destructiveHint), so they provide no behavioral safety profile. The description adds no details about side effects, whether the boundary field is modified in memory or persisted, or if any validation occurs. It only states the action without any 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 a single sentence that is concise and front-loaded. It contains no filler or redundant information. Every word contributes to the action and target.
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 tool has 4 parameters (2 required) and a moderate schema, the description is insufficient. It does not explain what 'attach' entails, what output to expect, or any preconditions. Although an output schema exists, the description still needs to convey purpose and usage context. The tool is underspecified for the complexity involved.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/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 for parameter semantics. It does not mention any parameter names, meanings, or relationships. The description adds no value beyond the input schema, leaving the agent to infer parameter semantics solely from the JSON 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 uses a specific verb ('attach') and clearly identifies the resource ('a loaded UDF profile to a boundary field'). It distinguishes this tool from siblings like fluent_load_udf (which loads UDFs) and fluent_list_udfs (which lists them). This makes the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly states that the UDF must already be loaded (by saying 'loaded UDF'), which provides minimal usage guidance. However, it does not explicitly mention when to use this tool over alternatives or any prerequisites beyond loading. It does not discuss context 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?
Annotations provide no safety hints (all false), and the description adds no behavioral disclosure about session state mutation, error handling, or file requirements. The word 'Read' may imply safe read-only, but readOnlyHint=false contradicts that implication, creating ambiguity rather than clarity.
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 one compact sentence with no filler, earning high marks for efficiency. It is appropriately front-loaded with verb and resource.
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 an output schema, the description is minimally sufficient, but it lacks any context about session state, file validity, or relationship to fluent_read_case. Given the sibling context, more contextual detail would be helpful.
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 fully describes the file_path parameter with 100% coverage, and the description offers no additional parameter semantics beyond what the schema already states. Thus the baseline of 3 applies.
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 'read' and the resource 'Fluent mesh file', making the primary function unambiguous. However, it does not explicitly differentiate from the sibling tool fluent_read_case, though the resource type provides implicit distinction.
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 such as fluent_read_case, nor any prerequisites or exclusions. It only states the action without 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?
Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true. The description adds no additional behavioral context (e.g., return format, limitations, prerequisites). It simply restates the action, providing no value beyond the 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?
The description is a single, short sentence that is directly front-loaded with the verb and resource list. Every word adds value, and there is no wasted content.
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 is simple with one optional parameter and an output schema, so the description is minimally adequate. However, it doesn't clarify the mechanical analysis context or differentiate from geometry_list_bodies, leaving some ambiguity for an agent deciding between 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 has one parameter 'what' with enum values, and schema description coverage is 0%. The description lists the exact enum values ('bodies, named selections, or analyses'), which clarifies the parameter's accepted values, but it doesn't explain their meaning or behavior. This partially 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 states a clear verb ('List') and resource ('bodies, named selections, or analyses'), which precisely conveys the tool's function. It distinguishes from siblings like geometry_list_bodies by covering additional object types, though it doesn't explicitly name alternatives.
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 alternatives like geometry_list_bodies or mechanical_get_result. The description merely states the function without any contextual usage hints 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?
Annotations provide no hints (all false), so the description carries the burden. It mentions 'optionally generate' but does not disclose side effects of changing mesh settings, whether generation is blocking, what the timeout parameter controls, or if prior model setup is required. This is insufficient for a mutating 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 a single front-loaded sentence that efficiently conveys the core action and optional outcome. It wastes no words and 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.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 5 parameters and no annotation support, the description is too sparse. It does not explain the generate flag's effect, timeout semantics, element size unit implications, or how this step fits into the broader meshing/solving workflow, even though an output schema exists.
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 the description must compensate. It mentions 'mesh size' and 'method', which maps to element_size and method, but ignores element_size_unit, generate, and timeout. The schema only provides titles/enums, leaving these parameters under-explained.
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 mesh size and method and optionally generates the mesh, using a specific verb and resource. It distinguishes from sibling tools like mechanical_get_mesh_settings (which reads settings) and mechanical_apply_load (which applies loads), so the purpose is unambiguous.
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 gives no explicit guidance on when to use this tool versus alternatives, such as mechanical_get_mesh_settings for reading current mesh settings. It implies use before solving but does not state prerequisites, exclusions, or alternative 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?
The annotations indicate non-read-only, non-idempotent, and non-destructive behavior, but the description adds no behavioral depth. It does not disclose side effects (e.g., overwriting existing materials), error conditions, or whether the action is reversible. The 'exactly one named body' constraint is a scoping detail, not a behavioral disclosure.
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 of eight words, front-loaded with the action verb. There is no fluff or redundant phrasing, making it appropriately concise.
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 being a low-complexity tool with simple string parameters, the description omits essential context: it does not mention that the body likely comes from geometry_list_bodies, whether materials are predefined, what the output schema indicates, or how this tool fits into the broader mechanical workflow. The presence of an output schema does not mitigate the lack of usage guidance.
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 the description must compensate. It clarifies that 'body' is the named target and 'material' is the assigned value, but it does not explain valid material identifiers, naming conventions, or whether the material must pre-exist. The description adds minimal semantic value beyond the schema's string types.
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 ('assign') and resource ('material') with a precise scope ('exactly one named body'), distinguishing it from sibling tools like mechanical_apply_load or mechanical_mesh. It clearly states the tool's purpose and 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?
The description provides no guidance on when to use this tool versus alternatives, nor does it mention prerequisites, exclusions, or relationships to other mechanical tools. The usage context is entirely absent.
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?
Annotations already indicate this is a non-read-only, non-destructive operation. The description adds the behavior that the new design is 'selected,' implying it becomes the active design. However, it does not explain side effects (e.g., whether existing unsaved designs are affected) or any session requirements. This is adequate but not rich beyond 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?
The description is a single, front-loaded sentence that directly states the tool's purpose. Every word earns its place, with no redundant 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?
The tool is simple (one optional parameter, output schema present) and the description covers the core function. However, it omits context about preconditions, behavior of the selection, or uniqueness constraints. Given the simplicity, this is a minimal viable description with clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema defines one parameter 'name' with no description (0% schema coverage), and the tool description does not mention it at all. With low schema coverage, the description must compensate for parameter meaning, but it fails to explain what 'name' is for or how it is used.
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 clear action verbs 'Create' and 'select' with a specific resource, 'a new Geometry design.' This distinguishes it from sibling tools like geometry_create_block, geometry_create_cylinder, and geometry_create_sphere, which target specific shape primitives rather than the design container itself.
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., launching an application) or contrast with sibling tools, leaving the agent to infer usage solely from the tool name and 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?
Annotations already cover read-only/idempotent/destructive characteristics. The description adds 'detected' to clarify scope, but does not provide additional behavioral details such as prerequisites 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?
The description is a single, concise sentence that immediately conveys the tool's purpose without 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?
The tool is simple with only one optional parameter, but the description omits the parameter's meaning, leaving a significant gap. The output schema covers return values, but parameter semantics are missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one optional parameter 'zone_name' with no description, and the tool description does not mention it. With 0% schema description coverage, the description fails to compensate by explaining the parameter's purpose.
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 (detected UDF profile hooks). It distinguishes from sibling tools like fluent_load_udf and fluent_hook_udf, 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 Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool is for inspecting detected UDFs, but it does not explicitly state when to use it versus alternatives or provide exclusion criteria. No alternatives 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?
Annotations provide only all-false hints, which do not disclose actual side effects. The description says 'Read' but does not explain that reading a case file into Fluent likely modifies the current solver state. It adds no behavioral context beyond the literal 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 a single concise sentence with no unnecessary words. It is front-loaded with the primary action and resource, earning full credit for conciseness and structure.
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 is simple and has an output schema, so return values are already covered. However, the description lacks context about what happens when a case is read (e.g., replaces current case, initializes solver). It is minimally complete but misses important usage context for a Fluent session.
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 100% with file_path described as 'Absolute or working-directory-relative file path'. The description adds no additional meaning to the parameter, so the schema does the heavy lifting. Baseline score of 3 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 'Read an existing Fluent case file' uses a specific verb 'Read' and a distinct resource 'Fluent case file', clearly distinguishing it from sibling tools like fluent_read_mesh. It is specific and unambiguous about what the tool does.
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 that it loads a case for simulations, nor does it distinguish from fluent_read_mesh or other Fluent operations. No exclusions or contexts 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?
Annotations provide readOnlyHint=false, indicating it's a write operation, but the description adds minimal behavioral context beyond 'create'. It does not disclose side effects like whether it modifies the active design, requires a design to exist, or how it interacts with existing geometry. The 'centered' and 'SI units' details are more parameter-level than behavioral.
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 concise sentence that front-loads the verb and object. No words are wasted, and it avoids redundancy with the schema.
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 core purpose and useful constraints (centering, SI units) but lacks important context such as prerequisites (e.g., an active design), expected side effects, or how the created cylinder is exposed (e.g., returned ID). For a create operation with 6 parameters, this is adequate but not 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?
The input schema has 0% description coverage, so the description's mention of 'centered' and 'SI length units' adds meaningful context beyond the bare schema titles. However, it does not elaborate on individual parameters or clarify the coordinate system for center_x/y/z, leaving some ambiguity.
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 'Create a centered cylinder using SI length units' clearly states the specific verb (create), resource (cylinder), and unique qualifiers (centered, SI units). It distinguishes this from sibling tools like geometry_create_block and geometry_create_sphere.
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. There is no mention of when not to use it or any explicit alternative. The usage context is only implied by the tool name and purpose.
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 annotations indicating the tool is not read-only and not idempotent, the description adds no additional behavioral detail about mutation semantics, whether loads accumulate or overwrite, or side effects. The one-line description does not disclose these essential traits beyond what annotations already provide.
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, front-loaded sentence with no wasted words. It immediately states the action and target, making it concise and well-structured despite the underlying complexity.
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 having an output schema, the description omits prerequisites, parameter semantics, and how this tool fits into the Mechanical workflow relative to siblings like mechanical_mesh or mechanical_solve. For a 6-parameter tool, the description is far too thin to be contextually complete.
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%, and the description only hints at 'load or support' mapping to load_type and 'named selection' mapping to location. It leaves direction, magnitude, magnitude_unit, and analysis_index completely unexplained, providing only marginal value over 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 'Apply one typed load or support to one uniquely named selection' uses a specific verb and resource, clearly indicating it applies loads/supports to named selections. It distinguishes itself from sibling tools like mechanical_mesh and mechanical_solve in the Mechanical workflow.
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 the tool is for applying loads/supports to named selections, which gives clear context, but it does not explicitly state when to use this tool versus alternatives, nor does it mention exclusions 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?
Annotations only indicate non-read-only, non-idempotent, non-destructive, and open-world, but do not describe side effects. The description adds that it can launch or attach and probe readiness, but it fails to disclose key behaviors like starting a background process, the meaning of 'replace', or potential resource implications.
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, front-loaded sentence that efficiently communicates the core functionality without unnecessary words or repetition.
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 having an output schema and three optional parameters, the description is far too minimal for an agent to invoke the tool correctly. It does not specify how to choose between launching vs attaching, what 'replace' does, or how the timeout is applied, leaving significant gaps in operational understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description gives no parameter-specific information. It does not explain the 'port', 'replace', or 'connect_timeout' parameters, leaving the agent without the necessary meaning beyond just their names and types.
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 a specific verb ('Launch' or 'attach') and resource ('Mechanical batch mode', 'existing gRPC instance'), and adds the action 'probe readiness'. This distinguishes it from sibling launch tools like geometry_launch and fluent_launch, and from other mechanical_* tools that solve, apply loads, or check status.
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 the main use cases: when you need to start Mechanical in batch mode or connect to an already running gRPC instance. It gives clear context but does not explicitly mention when NOT to use it or name alternatives such as mechanical_status for checking readiness.
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?
Annotations already indicate the tool is not read-only, but the description adds no extra behavioral context. It does not explain side effects (e.g., overwriting previous results), potential long-running computation, or requirements for a valid active model. No additional transparency beyond the verb itself.
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 single concise sentence, front-loaded and without any wasted words. It is slightly more specific than the title by adding 'active,' but it does not enrich the description beyond that.
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 surrounding workflow (tools for meshing, applying loads, getting results), the description is too sparse. It does not mention that solving is typically a prerequisite to retrieving results, nor does it indicate that solving may be time-consuming or require a properly configured model. Output schema exists, but that does not cover usage 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 tool takes zero parameters and schema coverage is effectively 100%, so the description has no parameter details to add. The phrase 'active Mechanical model' implies reliance on session state, which is useful context, though minimal.
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 the specific verb 'Solve' with the resource 'active Mechanical model,' clearly distinguishing this tool from siblings that launch, import, or retrieve results. It unambiguously identifies the tool's 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?
The description provides no guidance on when to use this tool versus alternatives, such as prerequisites like meshing or applying loads before solving, or using mechanical_get_result after solving. It does not mention any exclusions 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?
Annotations indicate readOnlyHint=false and destructiveHint=false, so the description must clarify side effects, but it does not. It simply restates the action without disclosing that existing material assignments will be overwritten, or whether zone and material must reference pre-defined objects. No additional behavioral context beyond the annotations is provided.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single straightforward sentence, 'Assign a material to a Fluent cell zone,' is front-loaded and free of waste. Every word contributes meaning, and the structure is easily parsed.
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 is simple with only two string parameters, so a short description may suffice, but it still lacks essential context such as what the output will be, whether the zone must have a specific type, or any side effects. Since an output schema exists, the description need not explain return values, but behavioral and prerequisite details are missing, making it only minimally complete.
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% with no descriptions for zone or material. The brief description loosely implies that zone is the target cell zone and material is what to assign, but it does not explain acceptable formats, type expectations, or valid sources (e.g., material names from the Fluent database). It compensates minimally for the missing schema documentation but leaves key semantics unclear.
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 'Assign' with a clear resource 'material to a Fluent cell zone', which precisely identifies the tool's function. It also distinguishes itself from siblings like fluent_set_boundary and fluent_set_solver by specifying Fluent cell zone context. This is a clear and unambiguous purpose statement.
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 when to use the tool (whenever a material needs to be assigned to a Fluent cell zone) but provides no explicit guidance on prerequisites, when not to use it, or alternatives. For instance, it does not mention that the zone must exist or that mechanical_set_material is for Mechanical. The usage context is implied rather than explicitly 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?
Annotations provide basic hints (readOnlyHint=false, destructiveHint=false), and the description adds useful context about the block being centered and using SI units. However, it does not disclose side effects, relationship to an existing design, or output 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 a single, front-loaded sentence with no waste. It is appropriately concise for expressing the core purpose, though it sacrifices detail for brevity.
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 7 parameters, 0% schema descriptions, and no parameter clarifications, the description is far from complete. It does not explain how center coordinates affect placement, what the output means, or any operational 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 description coverage is 0% and the description provides almost no parameter-specific guidance. It mentions SI length units, which applies to dimensions, but does not explain width, height, length, center coordinates, or name, leaving the agent to guess.
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 'block', and includes a distinguishing feature ('centered', 'SI length units') that differentiates it from sibling tools like geometry_create_cylinder and geometry_create_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?
The description implies usage when a block is needed, but provides no explicit guidance on when to prefer this over alternatives like cylinder or sphere. There are no exclusions or alternative tool references.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint: true and readOnlyHint: false, so the agent knows this is a write operation. The description adds that it writes both case and data and uses a path prefix, but does not disclose side effects such as behavior when overwrite is false and files exist. It adds some context beyond annotations but lacks important behavioral detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that leads with the verb and communicates the core action efficiently. Every word contributes to understanding the tool's function, and there is no redundancy or irrelevant 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 simple schema and presence of an output schema, the description covers the primary action and main parameter. However, it omits important operational context such as whether existing files are preserved or overwritten by default, what file extensions are produced, and any dependence on an active Fluent session. This makes it adequate but not 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 description coverage is 0%, so the description must compensate. It explains 'prefix' via 'path prefix', but gives no information about the 'overwrite' parameter beyond the schema's default and name. The description partially compensates but leaves semantic gaps for one of the two 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 the specific verb 'Write' and clearly identifies the resource ('Fluent case and data') and mechanism ('using a path prefix'). This distinguishes it from sibling read tools like fluent_read_case and fluent_read_mesh, making the purpose immediately clear.
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, typical workflows (e.g., after solving), or contrast with other Fluent write/set tools. It merely states what the tool does, leaving usage entirely implied.
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?
Annotations already signal destructiveness (destructiveHint=true). The description adds useful context not present in annotations: the two possible behaviors (detach vs close) and the scope limitation to MCP-launched instances. This is meaningful additional 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 a single, front-loaded sentence with no unnecessary words. It conveys the core functionality 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?
For a simple exit tool with strong annotations, a schema-documented parameter, and an output schema, the description is mostly sufficient. It could add a note about being the standard way to end a Fluent session, but it covers the essential behavior without redundancy.
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 100%: the only parameter 'shutdown_attached' has its own description. The tool description adds no information about parameters, so the baseline of 3 applies.
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 'Detach from Fluent or close an MCP-launched instance' clearly states the action and resource. It distinguishes from siblings by being the only Fluent exit/disconnect tool, but the dual 'detach or close' wording introduces slight ambiguity.
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. It does not mention that this should be used to end a Fluent session or how to decide between detach and close beyond the parameter schema. No alternatives or exclusions are discussed.
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?
Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior, so the safety profile is well covered. The description adds that the output is 'structured' history, but it does not disclose details like whether the history persists across sessions or is cleared by reset operations. No contradiction with 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?
A single concise sentence that is front-loaded with the action ('Return') and the specific resource ('structured MCP-to-TUI mapping history'). Every word earns its place, with no unnecessary detail.
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, output schema present, annotations covering safety), the description is fully sufficient. It specifies the domain-specific resource and action, and the output schema will define the exact return structure.
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 the schema confirms this with 100% description coverage. Per the rubric, 0 parameters yields a baseline of 4; the description correctly provides no parameter documentation as none exist.
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 uses the specific verb 'Return' with the resource 'structured MCP-to-TUI mapping history', clearly stating the tool's purpose. However, it does not explicitly differentiate from related sibling tools like 'fluent_reset_mapper', relying on the verb to imply it is the query counterpart.
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 description only states what it does; there is no mention of complementary tools such as 'fluent_reset_mapper' or typical scenarios for consulting mapping history.
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?
All annotations are set to false, so the description carries the full burden. It discloses two modes (compile vs. interpret) but omits significant behavioral details: prerequisites (e.g., valid C source), side effects (e.g., generated artifacts), and what loading actually accomplishes in the Fluent environment.
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 with no redundancy. It is front-loaded with the action and specifies the resource immediately.
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 only two parameters and an output schema, so the description covers the core action. However, it falls short on usage guidance and behavioral context, especially given the presence of closely related Fluent UDF tools. It is minimally sufficient but not comprehensive.
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 effectively explains the compile flag via 'compile or interpret' and clarifies that source_file should reference an existing file. However, it lacks details on file types, path conventions, or the default behavior when compile is false.
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 phrase ('Compile or interpret') and names the resource ('existing Fluent UDF source file'), which clearly states the tool's function and distinguishes it from siblings like fluent_hook_udf or fluent_list_udfs.
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 (for existing UDF source files) and what it does (compile or interpret), but does not explicitly contrast it with alternatives or specify when not to use it. This gives 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.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds no behavioral details beyond what the annotations already provide. It doesn't disclose prerequisites (e.g., a loaded Fluent case), side effects (e.g., whether settings are applied immediately), or reversibility. Since annotations already mark it as a non-destructive mutation, the description does not enrich the agent's understanding of the tool's runtime 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 a single, front-loaded sentence with no redundant words. It efficiently conveys the tool's scope: 'Configure viscosity, energy, and steady/transient solver settings.'
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?
This is a simple tool with three optional parameters and an output schema. The description covers the core purpose but omits context such as when to call it relative to other steps (e.g., after reading a case) and what the output contains (though output schema exists). It is adequate but not fully self-sufficient.
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 maps 'viscosity' to viscous_model, 'energy' to energy, and 'steady/transient' to transient, giving basic semantic context. However, it does not explain the meaning of each option (e.g., turbulence models) or the implications of enabling energy, so it offers only a minimal interpretation.
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 function: 'Configure viscosity, energy, and steady/transient solver settings.' It uses a specific verb ('configure') and resource ('solver settings'), and it distinguishes itself from siblings like fluent_set_boundary and fluent_set_material by focusing on solver-level configuration.
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 makes it obvious when to use this tool: whenever the user needs to set solver-related parameters. It doesn't explicitly mention alternatives or exclusions, but the context is clear given the sibling tools like fluent_set_boundary and fluent_set_material, which cover other configuration aspects.
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 annotations indicate a non-read-only, non-idempotent mutation, which the description aligns with. It adds the fact that the sphere is 'centered' and uses 'SI length units', providing useful context beyond the raw annotations. However, it does not disclose potential side effects, naming constraints, or coordinate system assumptions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the core purpose. Every word contributes meaning, with no redundant filler or repetition of schema 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 tool is simple and an output schema is present, so return value explanation is unnecessary. However, the description lacks broader workflow context, such as prerequisites (e.g., an active geometry session) or how this creation step relates to subsequent geometry operations. Minimal but acceptable for a basic creation tool.
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 must compensate. It clarifies that all length-related parameters (radius, center coordinates) use SI units, which is valuable. However, it does not explain the individual parameter semantics beyond what their names imply, and it omits details about defaults or constraints already present in 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 'Create a centered sphere using SI length units' clearly states the action (create) and the resource (sphere). It distinguishes itself from sibling tools like geometry_create_block and geometry_create_cylinder by explicitly naming the shape.
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 a sphere geometry is needed, but it does not explicitly state when to use this tool over alternatives like geometry_create_cylinder or geometry_create_block. There are no exclusions or alternative references.
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?
Annotations already declare destructiveHint=true, and the description adds 'unsafe confirmation,' reinforcing the risk. It does not detail side effects or that arbitrary code can modify Mechanical state (though the schema does for confirm_unsafe). Given annotation coverage, the description adds minimal extra context, so a 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?
One short sentence, front-loads the verb and resource, with no filler. Perfectly concise.
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?
This is a powerful tool with arbitrary code execution and a destructive hint, yet the description provides only one sentence. It does not describe return behavior, error conditions, or what state changes may occur. With an output schema present but not described, and significant execution risk, the description is insufficient for full understanding.
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 only 33% (only confirm_unsafe has a description). The description mentions 'arbitrary Mechanical IronPython' and 'unsafe confirmation,' which loosely map to script and confirm_unsafe, but it never mentions the timeout parameter, leaving its semantics unclear. The description does not compensate for the schema's lack of descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies a clear verb ('Execute') and resource ('Mechanical IronPython'), and the qualifier 'after explicit unsafe confirmation' distinguishes it from other Mechanical operations. It clearly separates from sibling tools that perform specific actions like solve or get_result.
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 word 'arbitrary' implies use for custom operations not covered by specific sibling tools, and the unsafe confirmation indicates it's for advanced users. However, it doesn't explicitly state when to prefer this over other tools or provide exclusions, so it's clear context but lacks explicit 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?
Annotations already indicate this is a write operation (readOnlyHint=false) and not destructive, so the description adds some value by specifying the target is the 'active design'. However, it does not disclose potential failure modes (e.g., missing active design, unsupported file formats) or whether existing geometry is replaced.
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 compact sentence that immediately states the action and target. Every word earns its place, with no redundant or superfluous content.
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 tool has only one parameter and an output schema exists, so the description is largely sufficient. It correctly identifies the prerequisite of an active design. It could mention file format constraints or behavior when no design is active, but these are not critical for basic usage.
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 100% and the single parameter file_path has a clear description in the schema. The tool description does not add extra parameter context beyond what the schema already provides, so a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Insert') and resource ('existing CAD file into the active design'), clearly distinguishing it from sibling tools like create_block or create_cylinder that generate new geometry. The title also reinforces the purpose.
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 use when an existing CAD file needs to be added to the active design, but it does not explicitly state when to use this tool over alternatives like geometry_create_block or geometry_launch. No exclusions or alternative references are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare this tool as read-only, non-destructive, and idempotent. The description adds valuable context by specifying that it returns 'connection' and 'active-design state', which are the key behavioral outputs. It does not contradict annotations, and the safety profile is already covered by structured data.
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 of eight words. It is immediate, front-loaded with the verb, and contains no redundant phrases or filler. Every word 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?
For a zero-parameter status tool with rich annotations and an output schema, the description is sufficient. It clearly names what the tool returns (connection and active-design state), and the output schema handles return-value details. No gaps in context are evident.
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% (vacuously). Per the rubric, the baseline for 0 params is 4. The description does not need to explain parameter semantics since there are none, and it adds no conflicting 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 uses a specific verb ('Return') and names a distinct resource ('Geometry connection and active-design state'). It clearly indicates a status/read operation. However, it does not explicitly distinguish itself from sibling tools like geometry_list_bodies, and 'active-design state' is somewhat vague without further elaboration.
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 gives no guidance on when to use this tool versus alternatives. It does not mention typical use cases, prerequisites, or when to prefer other geometry tools. The only implied usage is 'to get status', but no context or exclusions are 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?
The description adds the scope 'current Fluent session' which is not in the title, but it does not disclose side effects or what happens to the mapping beyond clearing. Annotations already indicate idempotent and non-destructive behavior, and the description does not contradict them.
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, front-loaded sentence with no wasted words. It conveys the purpose clearly and efficiently.
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 parameterless tool with an output schema, the description is complete. It states exactly what action is performed and the scope, and no further details about return values or parameters are required.
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, so the baseline is 4. The description correctly omits parameter details; no additional semantic information is needed.
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 ('Clear'), names the resource ('mapping history'), and scopes it to the current Fluent session. It clearly distinguishes this tool from siblings like fluent_get_mapping_report, which retrieves a report rather than clearing 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 is provided on when to use this tool versus alternatives, nor any prerequisites, exclusions, or context about when clearing mapping history is appropriate. The description only states the action.
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?
Annotations already declare destructiveHint=true, so the destructive nature is known. The description adds the context that this closes the service 'launched via MCP', which is useful scope. However, it does not describe what happens to running processes, unsaved data, or whether the action is reversible beyond what annotations already indicate.
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 concise sentence that conveys the essential purpose without any wasted words. It is appropriately sized for a no-parameter, simple action tool.
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 (no parameters, no nested objects) and the presence of a destructive annotation, the description is adequate for an agent to understand the action. It lacks explicit detail about side effects or post-conditions, but these are not critical for a simple close 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?
The input schema has zero parameters, so per rubric baseline is 4. The description adds no parameter-related information, but none is needed since the tool takes no inputs.
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 the specific verb 'Close' and identifies the resource as 'the MCP-launched Geometry service', clearly distinguishing it from sibling tools like geometry_launch and geometry_status. It is immediately clear what action this tool performs.
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 the tool is used to shut down the Geometry service, but it does not explicitly state when to use it versus alternatives (e.g., geometry_exit) or mention any prerequisites or consequences. Usage is inferred from the verb 'Close' rather than explicitly guided.
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?
Annotations already declare destructiveHint=true, and the description does not contradict this. The description adds the scope ('active design') and precision ('exact requested path'), but it does not mention file overwriting behavior or other side effects beyond what the annotation already indicates.
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, tightly crafted sentence that immediately states the action, resource, and target. No filler or 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?
For a relatively simple export tool with annotations and an output schema, the description covers the core purpose and key parameters. It could mention overwrite behavior or limitations, but the destructiveHint annotation partially covers that gap, making it sufficient for tool selection.
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 does mention the format options (STEP or IGES) and the output path, but it says nothing about the 'overwrite' parameter, leaving one of three parameters undocumented.
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 the specific verb 'Export' and names the resource ('active design') and target format/path ('STEP or IGES path'), clearly distinguishing this from sibling tools like geometry_import_file or geometry_create_design.
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 conveys that this tool is used to export the active design to a file, which is a clear context. It does not explicitly exclude alternatives or state when not to use it, but no other sibling tool provides export functionality, so the usage is unambiguous enough.
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?
Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, so the description does not need to restate safety. It adds minimal context by mentioning 'configured global mesh settings' and 'generated counts,' but does not elaborate on what these include or any edge cases beyond the 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?
The description is a single, front-loaded sentence with no filler or redundancy. It directly communicates the tool's function in a compact and scannable format, earning maximum points for conciseness.
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 (no parameters), strong annotations (read-only, idempotent), and the presence of an output schema, the description is sufficiently complete. It clearly states what is read, and the output schema likely details the return structure. A minor gap is the lack of clarity about what 'global mesh settings' includes, but this is acceptable given the output schema's role.
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 is empty (0 parameters), so there are no parameter semantics to explain. Schema description coverage is 100% by nature, and the description accurately reflects the no-input nature. Baseline 4 applies due to 0 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 clearly states the tool reads configured global mesh settings and generated counts, which is a specific verb-resource combination. It distinguishes itself from sibling tools like mechanical_mesh (likely setting or creating mesh) and mechanical_get_result (getting results) by focusing on global settings and counts.
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 the tool is used to read mesh settings, but it does not explicitly state when to use it versus alternatives. There is no mention of exclusions or preferred scenarios, leaving the agent to infer usage from the verb 'Read' and 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?
Annotations already indicate that the tool is not read-only, not idempotent, and not destructive. The description adds that it targets the 'active Mechanical model', implying a prerequisite state. However, it does not disclose what happens on file-not-found, file-format compatibility, or whether repeated imports replace existing geometry, leaving some behavioral 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 a single sentence with no redundant words. It immediately states the action and target, earning the highest score for conciseness and structure.
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 tool with one parameter and an output schema, the description covers the essential 'what' and 'where'. It could be more complete by mentioning supported file types or that the Mechanical model must be active, but the output schema and annotations reduce the burden.
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 one parameter, file_path, with a description already covering meaning (absolute or relative path). With 100% schema coverage, the baseline is 3, and the description adds no additional parameter semantics beyond what the schema provides.
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 'Import' and clearly identifies the resource: 'existing geometry file' and the destination: 'active Mechanical model'. This distinguishes it from sibling tools like geometry_import_file, which target the geometry editor rather than the Mechanical model.
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 phrase 'into the active Mechanical model' indicates the intended context and implies that this tool is for transferring geometry into a Mechanical simulation setup, as opposed to geometry creation or other operations. It lacks explicit exclusions or alternatives, but for a single-purpose import tool this 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?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, covering safety. The description adds the 'latest' qualifier, providing temporal context, but does not disclose behavior like empty results when no residuals exist. This is a minor addition beyond 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?
The description is a single, front-loaded sentence with no unnecessary words. It conveys the exact purpose efficiently.
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 parameterless tool with clear read-only annotations and an output schema, this one-sentence description is sufficiently complete. It specifies what is returned (residuals) and their recency (latest), with no critical missing 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 tool has zero parameters, and the schema is empty with 100% coverage, so the description carries no burden for parameter meaning. The baseline of 4 applies as no parameter information is needed.
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 the specific verb 'Read' and identifies the resource as 'the latest Fluent residual values,' making its function unmistakable. It distinguishes itself from sibling tools like fluent_status or fluent_get_mapping_report by focusing on residuals.
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 you need residual values) but provides no explicit context, alternatives, or exclusions. There is no mention of when to use this over other fluent read tools.
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 annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false. The description adds the scoping context that the journal is from the current session and generated, but does not disclose behavior like what happens if no journal exists or response format, leaving some transparency 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?
One sentence, no filler, front-loaded with the core action. Every word 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?
For a simple read-only tool with no parameters and an output schema, the description sufficiently covers the tool's purpose and scope. No significant missing 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 tool has zero parameters, so the schema completely covers the input. According to the 0-param baseline, a 4 is appropriate; the description adds no parameter semantics needed.
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 'Return' and names the resource 'current session's generated Fluent journal', clearly distinguishing it from sibling tools like fluent_get_residuals or fluent_get_mapping_report.
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 states the tool's scope ('only the current session's') but provides no explicit guidance on when to use this tool over alternatives or when not to use it. Context is clear but exclusions/alternatives are absent.
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?
Annotations already provide readOnly, idempotent, and non-destructive hints. The description adds the specific readiness categories returned, but no additional behavioral traits like session requirements or latency. It does not contradict 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?
The description is a single, front-loaded sentence with only essential words. It efficiently communicates the tool's purpose without redundancy.
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), rich annotations, and existing output schema, the description is complete enough. It lists the readiness domains, making the tool's behavior clear.
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, so there is no parameter complexity. The baseline of 4 applies since the description does not need to compensate for undocumented 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 clearly states the tool returns readiness for transport, scripting, project, model, and analysis. This distinguishes it from sibling status tools (geometry_status, fluent_status) and other mechanical actions.
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. Its purpose is implied by the name and sibling context, but no clear 'when-to-use' or 'alternatives' 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?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the description's role is to add scope. It adds 'active Geometry design', specifying that it operates on the active design rather than a specified design. No contradictions; however, it doesn't disclose return behavior, though output schema is available.
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?
Single sentence, precisely worded, 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 0 parameters, annotations covering safety, and an output schema, the description sufficiently orients the agent. Minor gap: doesn't specify body type/filtering, but that's likely in output schema.
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 parameters, so description has no param semantics to add. Per rubric, 0-param tools get baseline 4.
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 the specific verb 'List' and identifies the resource 'bodies' within 'active Geometry design', clearly distinguishing it from other geometry tools like create/export/status.
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 phrase 'active Geometry design' provides clear context for when the tool applies (to the current design), but it does not explicitly mention alternatives or exclusion criteria. However, as the only listing tool for geometry bodies, usage is implied.
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?
Annotations already declare destructiveHint=true. The description adds context beyond this by explaining the two modes (detach vs. close an MCP-launched instance), which clarifies the tool's scope. It does not contradict 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?
The description is a single, concise sentence that is front-loaded with the core action. No wasted words, exactly the right amount of information for a simple tool.
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?
With a simple one-parameter tool, an output schema, and complete parameter descriptions, the description fully covers the necessary context. It clarifies the two distinct behaviors without needing to explain return values.
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 100% and the parameter shutdown_attached is well-documented in the schema. The tool description does not add additional meaning beyond what the schema provides, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the action ('Detach', 'close') and the resource ('Mechanical', 'MCP-launched instance'). It directly states the tool's purpose of ending a session, which distinguishes it from sibling tools like mechanical_launch or mechanical_status.
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 provides clear context for use: when you want to disconnect from or close a Mechanical instance. It does not explicitly contrast with alternatives, but the action is evident and appropriately scoped for an exit tool.
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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds context about checking live connection and version state, which goes slightly beyond the annotations by specifying what status means. It is concise but behaviorally transparent for a simple read-only 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?
A single front-loaded sentence that says exactly what the tool does and its side-effect profile. Zero filler, perfectly sized for the tool's simplicity.
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 has no parameters, strong annotations (read-only, idempotent, non-destructive), and an output schema, the description is complete. It adequately conveys purpose and safety without needing to explain return values or additional behaviors.
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, and the schema confirms this with 100% coverage. Baseline for zero parameters is 4; the description has no need to explain parameters and correctly stays silent.
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 ('Return') and resource ('connection and version state'), clearly distinguishing this from sibling Fluent and mechanical tools. It also reinforces the read-only nature, leaving no ambiguity about what the tool does.
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 context is clear: use this to check Fluent's connection and version before other operations. It does not explicitly name alternatives or exclusions, but for a status tool the intended usage is obvious and the 'without modifying Fluent' phrase helps set expectations.
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/Bettertoo2/ansys-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server