ANSYS MCP Server

Overview Schema Source Related Servers Discussions Admin

Execute Fluent TUI

fluent_tui

Destructive

Execute arbitrary Fluent TUI commands in the active session after user confirmation, providing direct access to modify ANSYS Fluent simulations.

Instructions

Execute arbitrary Fluent TUI after explicit unsafe confirmation.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "command": "<command>",
      "confirm_unsafe": "<confirm_unsafe>"
    },
    "name": "fluent_tui"
  }
}

Input Schema

Name	Required	Description	Default
`command`	Yes
`confirm_unsafe`	Yes	Explicit confirmation that arbitrary TUI can modify the session

Output Schema

Name	Required	Description	Default
`ok`	Yes
`data`	No
`tool`	Yes
`error`	No
`message`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.2.0Aug 14, 2026

TDQS

B3/5.0

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/5

Is 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/5

Given 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/5

Does 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/5

Does 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/5

Does 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.