English | 한국어 | 中文 | 日本語 | Deutsch | Français | Español | Português
VTK 就是你所需要的一切。为 AI 智能体提供的电影级科学可视化工具。
一个提示词 → 物理分析 → 电影级渲染 → LaTeX 方程 → 可出版的故事。
一个 MCP 服务器，让 AI 智能体能够完全访问 VTK 的渲染管线——无需 ParaView 图形界面，无需 Jupyter 笔记本，无需显示服务器。你的智能体可以读取仿真数据、应用过滤器、渲染电影级图像并导出动画，全程无头运行。
兼容： Claude Code · Cursor · Windsurf · Gemini CLI · 任何 MCP 客户端
Related MCP server: HoloViz MCP Server
pip install mcp-server-viznoir添加到你的 MCP 客户端配置中：
{
"mcpServers": {
"viznoir": {
"command": "mcp-server-viznoir"
}
}
}然后询问你的 AI 智能体：
"打开 cavity.foam，用电影级光照渲染压力场，然后创建一个物理分解故事。"
类别 | 工具 |
渲染 |
|
过滤器 |
|
分析 |
|
探测 |
|
动画 |
|
比较 |
|
导出 |
|
22 个工具 · 12 个资源 · 4 个提示词 · 50 多种文件格式 (OpenFOAM, VTK, CGNS, Exodus, STL, glTF, …)
prompt "Render pressure from cavity.foam"
│
MCP Server 22 tools · 12 resources · 4 prompts
│
VTK Engine readers → filters → renderer → camera
│ EGL/OSMesa headless · cinematic lighting
Physics Layer topology analysis · context parsing
│ vortex detection · stagnation points
Animation 7 physics presets · easing · timeline
│ transitions · compositor · video export
Output PNG · WebP · MP4 · GLTF · LaTeX22 个 MCP 工具 | 24 个 VTK 过滤器 |
10 个领域 | 19 种原生文件格式 |
6/6 种 VTK 数据类型 | 50+ 种通过 meshio 支持的格式 |
开发者文档： kimimgo.github.io/viznoir/docs — 完整的工具参考、领域展示、架构指南
MIT
[DEPRECATED — use inspect_physics instead] Analyze VTK/simulation data.
This tool is deprecated. Use inspect_physics for structured physics data extraction with vortex detection, critical points, and solver metadata.
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | Yes | Path to VTK/OpenFOAM/CGNS file | |
| focus | No | Analyze only this field (None for all fields) | |
| domain | No | Physics domain hint — "cfd", "fea", "thermal" (None for auto-detect) |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description should compensate with behavioral details. It only states the tool is deprecated and basic function, without mentioning outcomes, side effects, or access requirements. This is insufficient for a tool with no annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short (two sentences) and front-loads the deprecation warning. Every sentence serves a purpose: deprecation notice and tool function. However, it could benefit from a brief behavioral note without adding length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the existence of an output schema and 3 parameters, the description is too sparse. It lacks context about the nature of the analysis, expected results, and how it differs from inspect_physics beyond deprecation. More detail would be expected for a tool with such siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for its 3 parameters, so the baseline is 3. The description adds no extra explanation for parameters beyond what the schema already provides, so it neither helps nor harms.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool is for analyzing VTK/simulation data and is deprecated. It identifies the resource and action, but lacks specific details about the type of analysis beyond the schema. The deprecation notice effectively highlights that this tool is not the preferred one, distinguishing it from siblings like inspect_physics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says to use inspect_physics instead, providing clear when-not-to-use guidance and a direct alternative. This is optimal for deprecation scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create an animation from time series data or camera orbit.
Time mapping (timesteps mode): speed_factor=1.0: real-time (physics 1s = video 1s) speed_factor=5.0: 5x fast-forward speed_factor=0.2: 5x slow-motion (physics 1s = video 5s)
For VTK file series (e.g., PartFluid_0000.vtk through PartFluid_0100.vtk), use 'files' with an explicit list or 'file_pattern' with a glob pattern.
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | Yes | Path to simulation file (or first file in series) | |
| field_name | Yes | Field to visualize | |
| mode | No | "timesteps" for time series, "orbit" for camera rotation | timesteps |
| colormap | No | Color map preset | Cool to Warm |
| camera | No | Camera preset (used for initial view in orbit mode) | isometric |
| fps | No | Frames per second (15-60) | |
| time_range | No | [start, end] physics time range, None for all | |
| speed_factor | No | Playback speed multiplier (1.0=real-time) | |
| orbit_duration | No | Orbit video length in seconds (orbit mode only) | |
| width | No | Frame width | |
| height | No | Frame height | |
| files | No | Explicit list of file paths for VTK time series | |
| file_pattern | No | Glob pattern for file series (e.g., "/data/PartFluid_*.vtk") | |
| output_format | No | Output format — "frames" (PNG only), "mp4", "webm", or "gif" | frames |
| video_quality | No | Video CRF quality (lower=better, 18-28 typical, default 23) | |
| text_overlay | No | Text to overlay on video frames (e.g., case name) |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavioral traits. It explains speed_factor mapping and output formats, but does not mention output file locations, overwrite behavior, or side effects. This is adequate but leaves some gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (about 10 lines) and front-loaded with the core purpose. Every sentence provides useful information without redundancy or verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (16 parameters, output schema exists), the description covers the main modes and key behaviors. It does not detail output file naming or save location, but the output schema likely covers return values. Overall, it is fairly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, so the baseline is 3. The description adds extra semantic value by explaining speed_factor mapping (real-time vs fast-forward vs slow-motion) and VTK file pattern usage, which goes beyond the schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool's purpose: creating animations from time series data or camera orbits. It specifies two distinct modes (timesteps and orbit), which differentiates it from siblings like render or batch_render.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides guidance on when to use each mode and explains speed_factor scaling. It also mentions VTK file series usage. However, it lacks explicit comparisons to alternatives like split_animate, and could more clearly state when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Autonomous post-processing: inspect → visualize → evaluate → refine.
Analyzes the file, detects the simulation domain (CFD/FEA/SPH), and produces 3-5 visualizations automatically. With sampling-capable clients, evaluates results and refines parameters iteratively.
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | Yes | Path to simulation file (.foam, .vtu, .vtk, etc.) | |
| goal | No | "explore" (overview), "publish" (publication quality), "compare" (multi-field) | explore |
| max_iterations | No | Maximum refinement iterations (1-5) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully cover behavior. It discloses that the tool analyzes files, detects domains, produces 3-5 visualizations, and iteratively refines parameters. However, it does not clarify whether it modifies files, what the output format is, or any side effects like resource usage. There is room for more detail on the refinement process.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences plus a pipeline list. It is front-loaded with the key actions and avoids unnecessary words. Every sentence contributes meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description covers the tool's purpose, process, and parameters adequately. It explains the autonomous pipeline, domain detection, and iterative refinement, which is sufficient for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All three parameters have schema descriptions, and the tool description adds workflow context (e.g., '3-5 visualizations' implies the output count, 'inspect → visualize → evaluate → refine' explains the purpose of iterations). This adds value beyond the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool performs autonomous post-processing with a pipeline of inspect, visualize, evaluate, and refine. It specifies that it detects simulation domains (CFD/FEA/SPH) and produces 3-5 visualizations automatically. This distinguishes it from sibling tools like 'render' or 'animate' by emphasizing autonomy and iteration.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for autonomous exploration and refinement, especially with sampling-capable clients. However, it does not explicitly state when not to use this tool or mention alternative tools for specific tasks. The context is clear but lacks exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Render multiple fields from the same dataset in one call.
Returns a dict with images list, each containing field name and base64 PNG. Useful for comparing pressure, velocity, temperature, etc. side-by-side.
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | Yes | Path to simulation file | |
| fields | Yes | List of field names to render | |
| colormap | No | Color map preset | Cool to Warm |
| camera | No | Camera preset | isometric |
| purpose | No | Resolution preset — "analyze" (480p), "preview" (720p), "publish" (1080p) | analyze |
| width | No | Override width in pixels (must set both width and height, or neither) | |
| height | No | Override height in pixels (must set both width and height, or neither) | |
| timestep | No | Timestep selection | |
| quality | No | Rendering quality (draft/standard/cinematic) | standard |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description bears full burden. It describes basic behavior (batch render, return format) but does not disclose performance implications, side effects, read-only nature, or constraints like field limits. For a batch operation, more transparency is expected.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with action and return type, followed by use case. No verbose or redundant information. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 9 parameters, 2 required, high schema coverage, and output schema, the description covers main purpose and return format. Could mention constraints like max fields or defaults, but overall it is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, baseline 3. Description adds meaning by noting batch operation, return type (base64 PNG), and side-by-side comparison use case, which aids parameter selection. Does not deeply elaborate individual parameters but provides contextual value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it renders multiple fields from the same dataset in one call and returns a dict with images list containing field name and base64 PNG. It also provides use case (comparing fields side-by-side), distinguishing it from sibling tools like render.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implied usage from 'useful for comparing' but no explicit when-to-use, when-not-to-use, or alternatives among siblings like render or compare. Lacks guidance on choosing this over other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Cinematic-quality rendering with auto-framing, 3-point lighting, SSAO, and PBR.
Produces publication/presentation-quality images with:
PCA-based auto-camera: analyzes object shape and picks optimal viewing angle
3-point cinematic lighting (key + fill + rim)
SSAO (Screen-Space Ambient Occlusion) for contact shadows
FXAA anti-aliasing
Gradient backgrounds
PBR material support (metallic/roughness)
Quality presets:
draft: 960x540, no post-processing (fast preview)
standard: 1920x1080, SSAO + FXAA
cinematic: 1920x1080, all effects + ground plane
ultra: 3840x2160, all effects + ground plane
publication: 2400x1800, clean lighting, white background
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | Yes | Path to simulation file | |
| field_name | No | Field to visualize (None for auto-detect) | |
| colormap | No | Color map preset (e.g., "Cool to Warm", "Viridis") | Cool to Warm |
| quality | No | Rendering quality preset | standard |
| lighting | No | Lighting preset (cinematic, dramatic, studio, publication, outdoor, None) | cinematic |
| background | No | Background preset (dark_gradient, light_gradient, blue_gradient, publication, None) | dark_gradient |
| azimuth | No | Camera azimuth in degrees (None for auto from shape analysis) | |
| elevation | No | Camera elevation in degrees (None for auto from shape analysis) | |
| fill_ratio | No | How much of viewport the object fills (0.0-1.0, default 0.75) | |
| metallic | No | PBR metallic factor (0.0-1.0) | |
| roughness | No | PBR roughness factor (0.0-1.0) | |
| ground_plane | No | Add a semi-transparent ground plane for shadow catching | |
| ssao | No | Enable Screen-Space Ambient Occlusion | |
| fxaa | No | Enable Fast Approximate Anti-Aliasing | |
| width | No | Override image width (None uses quality preset) | |
| height | No | Override image height (None uses quality preset) | |
| scalar_range | No | [min, max] for color scale, None for auto | |
| timestep | No | Specific timestep, "latest", or None for first | |
| output_filename | No | Output PNG filename | cinematic.png |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden and details auto-camera behavior (PCA-based), lighting and effect options, and quality presets. It does not mention potential side effects (e.g., file overwrite) or performance implications, but the disclosed behavior is comprehensive for a rendering tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the main purpose, then bullet-points features and quality presets. Every sentence contributes meaning, and it is appropriately sized for a tool with many parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 19 parameters and no output schema, the description covers rendering features and presets well but omits what the tool returns (e.g., the saved file path or status). It assumes an output file is written, but this is not explicitly stated.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with all parameters described, so description adds value by explaining auto-camera behavior for azimuth/elevation and listing quality presets with specific resolutions/effects. This contextualizes the enumeration of the 'quality' parameter beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool does 'cinematic-quality rendering' with specifics like auto-framing, 3-point lighting, SSAO, and PBR. It distinguishes itself from siblings such as 'render' and 'volume_render' by emphasizing publication/presentation quality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for high-quality renders via quality presets but does not explicitly state when to use this tool over alternatives like 'render' or 'preview_3d'. No when-not-to-use or exclusion criteria are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a clipped visualization.
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | Yes | Path to simulation file | |
| field_name | Yes | Field to visualize | |
| origin | No | Clip plane origin [x, y, z] | |
| normal | No | Clip plane normal [nx, ny, nz] | |
| invert | No | If True, keep the other side | |
| colormap | No | Color map preset | Cool to Warm |
| camera | No | Camera preset | isometric |
| purpose | No | Resolution preset — "analyze" (480p), "preview" (720p), "publish" (1080p) | analyze |
| width | No | Override width in pixels (must set both width and height, or neither) | |
| height | No | Override height in pixels (must set both width and height, or neither) | |
| timestep | No | Timestep selection |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must carry the burden. It only says 'Create a clipped visualization' with no disclosure of behavioral traits like whether it mutates data, requires specific permissions, or what happens to the original data. Lacks transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, which is concise but lacks structure. It front-loads the action but does not elaborate, making it minimally adequate.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 11 parameters and no output schema, the description is very incomplete. It does not explain what a 'clipped visualization' entails, how parameters like 'origin' and 'normal' affect the result, or what the output will be. Missing crucial context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with each parameter having a description in the schema. The tool description adds no additional meaning beyond what the schema already provides, so baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description states 'Create a clipped visualization' which gives a verb and resource, but it is vague. It does not specify what kind of clipping or how it differs from sibling tools like 'slice' or 'contour'. The purpose is general.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives. The description does not mention any conditions, exclusions, or contexts where 'clip' is preferred over similar tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compare two simulation results side-by-side or as a difference map.
Renders both datasets with identical camera, colormap, and scalar range for direct visual comparison. Essential for design comparison, mesh convergence studies, and solver validation.
Modes:
side_by_side: Two panels with shared colorbar and consistent framing
diff: Absolute field difference map (|A - B|) rendered on dataset A's mesh
| Name | Required | Description | Default |
|---|---|---|---|
| file_a | Yes | Path to first simulation file | |
| file_b | Yes | Path to second simulation file | |
| field_name | No | Field to compare (None for auto-detect) | |
| mode | No | Comparison mode — "side_by_side" or "diff" | side_by_side |
| colormap | No | Color map preset for both panels | Cool to Warm |
| quality | No | Rendering quality (draft/standard/cinematic) | standard |
| purpose | No | Resolution preset — "analyze" (480p), "preview" (720p), "publish" (1080p) | analyze |
| width | No | Override total width in pixels (must set both width and height, or neither) | |
| height | No | Override height in pixels (must set both width and height, or neither) | |
| scalar_range | No | Shared [min, max] for consistent coloring (None for auto) | |
| timestep | No | Specific timestep, "latest", or None for first | |
| label_a | No | Label for first panel (displayed top-left) | A |
| label_b | No | Label for second panel (displayed top-left) | B |
| output_filename | No | Output PNG filename | compare.png |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description effectively discloses key behaviors: rendering both datasets with identical camera, colormap, and scalar range, and offering two comparison modes. However, it omits any discussion of side effects, required permissions, or resource considerations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear lead sentence, contextual elaboration, and bulleted mode list. It is appropriately concise without superfluous content, though it could be slightly more compact.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (14 parameters, no output schema), the description covers the core functionality but lacks details on what the tool returns (e.g., file path, success status) and does not fully explain parameter interactions or constraints. This leaves some gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the description adds limited value beyond the schema. It mentions modes and their meanings but does not elaborate on other parameters like 'quality' or 'purpose' beyond their schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool's purpose: comparing two simulation results side-by-side or as a difference map. It specifies use cases like design comparison, mesh convergence studies, and solver validation, and distinguishes from sibling tools by focusing on comparison rather than single visualization or analysis.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context (design comparison, convergence studies, solver validation) and describes two modes, but it does not explicitly state when to avoid this tool or provide alternatives. Given the many sibling tools, clearer guidance on when to choose 'compare' over 'analyze_data' or 'animate' would improve the score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compose multiple assets into a deliverable format.
| Name | Required | Description | Default |
|---|---|---|---|
| assets | Yes | List of asset definitions (dicts with 'type' and type-specific keys) | |
| layout | No | Layout mode — "story", "grid", "slides", or "video" | story |
| title | No | Optional title text (used in story layout) | |
| width | No | Output width in pixels (default 1920) | |
| height | No | Output height in pixels (default 1080) | |
| scenes | No | Scene definitions for video layout (list of dicts with asset_indices, duration, transition) | |
| fps | No | Frames per second for video export (default 30) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only states it composes assets, omitting behavioral details such as whether it is destructive, requires permissions, or modifies inputs. The one-line description does not compensate for the lack of annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, concise but not sufficiently informative. It could be expanded to add value without being verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 7 parameters, no output schema, and many sibling tools, the description does not explain return values, output format, or how it differs from other composition/render tools, leaving the agent underinformed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds no parameter-specific information beyond what the schema already provides; it does not mention any parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states it composes assets into a deliverable format, which is clear but does not differentiate from sibling tools like 'render' or 'batch_render' that also produce outputs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives; no context for when to choose 'compose_assets' over similar tools like 'animate' or 'cinematic_render'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create an iso-surface (contour) visualization.
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | Yes | Path to simulation file | |
| field_name | Yes | Field for iso-surface extraction | |
| isovalues | Yes | List of iso-values to extract | |
| colormap | No | Color map preset | Cool to Warm |
| camera | No | Camera preset | isometric |
| purpose | No | Resolution preset — "analyze" (480p), "preview" (720p), "publish" (1080p) | analyze |
| width | No | Override width in pixels (must set both width and height, or neither) | |
| height | No | Override height in pixels (must set both width and height, or neither) | |
| timestep | No | Timestep selection |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility for behavioral disclosure. It only states the action 'Create' with no details on side effects, return value, or required permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short (one sentence) and lacks substantive content. While concise, it does not earn its place by providing additional clarity beyond the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 9 parameters, no output schema, and no annotations, the description is severely incomplete. It fails to explain output format, constraints, or how it differs from sibling tools like 'pv_isosurface'.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with descriptions for all parameters, so the description adds no extra meaning. Baseline score of 3 is appropriate as the schema already serves the function.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it creates an iso-surface (contour) visualization, which is specific and matches the tool name. However, it does not differentiate from the sibling tool 'pv_isosurface', which likely has a similar purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives (e.g., slice, volume_render). There is no indication of prerequisites or context for appropriate use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Execute a custom pipeline definition (advanced).
Accepts a full PipelineDefinition JSON for maximum flexibility. This is the primary interface for CFD/FEA/CAE specialist agents.
The pipeline JSON structure: { "source": {"file": "/data/file.foam", "timestep": "latest"}, "pipeline": [ {"filter": "Slice", "params": {"origin": [0,0,0], "normal": [1,0,0]}}, {"filter": "Calculator", "params": {"expression": "mag(U)", "result_name": "Umag"}} ], "output": { "type": "image", "render": {"field": "Umag", "colormap": "Viridis"} } }
Available filters: Slice, Clip, Contour, Threshold, StreamTracer, Calculator, Gradient, IntegrateVariables, GenerateSurfaceNormals, ExtractBlock, ExtractSurface, WarpByVector, WarpByScalar, CellDatatoPointData, PlotOverLine, Glyph, ProgrammableFilter, Decimate, Triangulate.
Output types: image, data, csv, animation, export, multi.
| Name | Required | Description | Default |
|---|---|---|---|
| pipeline | Yes | Complete PipelineDefinition as JSON dict |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It describes the input format and options but omits behavioral traits such as resource usage, side effects, error conditions, or execution guarantees.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with an example and bullet-like lists, making it readable. It is slightly lengthy but every sentence adds value, though some repetition (e.g., listing filters) could be slightly more compact.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity, the description covers the pipeline structure, available filters, and output types comprehensively. However, it lacks details on error handling, prerequisites, or performance implications, leaving minor gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides minimal description ('Complete PipelineDefinition as JSON dict'), but the description enriches it with a full JSON example, valid filters list, and output types, adding substantial meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Execute a custom pipeline definition (advanced)' and specifies it's for 'CFD/FEA/CAE specialist agents.' It lists available filters and output types, distinguishing it from single-step sibling tools like clip or slice.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description identifies this as the primary interface for specialist agents, implying use for complex pipelines. It implicitly contrasts with simpler sibling tools but does not explicitly state when not to use it or alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Extract statistical summary (min/max/mean/std) for fields.
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | Yes | Path to simulation file | |
| fields | Yes | List of field names to analyze | |
| timestep | No | Timestep selection | |
| blocks | No | Multiblock region names |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It only states the output but does not mention whether the operation is read-only, requires permissions, or has side effects. The description is insufficient for an agent to understand behavior beyond the basic function.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded with the core purpose. It is concise and contains no superfluous information, earning maximum points for conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 4 parameters with 100% schema coverage and an output schema, which likely documents return values. The description is minimal but covers the essential purpose. Given the complexity, it is adequate but could be improved by mentioning typical use cases or error handling.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so parameters are documented in the schema. The description adds no additional semantics beyond the statistics listed. Baseline 3 is appropriate as the description does not improve understanding of parameter interactions or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool extracts statistical summary (min/max/mean/std) for fields, which is specific and actionable. However, it does not differentiate from sibling tools like inspect_data or probe_timeseries that may compute similar statistics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description lacks information about prerequisites, limitations, or preferred use cases, leaving the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Inspect a simulation file and return metadata.
Returns bounds, point/cell arrays with ranges, timestep info, and multiblock structure. Use this first to understand what data is available before rendering or extracting.
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | Yes | Path to the simulation file (e.g., /data/cavity.foam, /data/beam.vtu) |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It describes a read-only inspection returning metadata, with no indication of side effects. The listed return items (bounds, arrays, timestep, multiblock) provide behavioral transparency beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences: first defines action and output, second provides usage guidance. No wasted words, front-loaded with key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given one parameter, presence of output schema (though not detailed), and usage advice, the description is largely complete. Minor gaps: no mention of file format restrictions or glob behavior, but acceptable for a simple inspection tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only one parameter (file_path) with 100% schema coverage. The description adds usage context ('Inspect a simulation file') and the schema provides example paths. No extra semantic detail needed, but the description reinforces the parameter's role.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Inspect a simulation file and return metadata' and lists specific return types (bounds, arrays, timestep, multiblock). It distinguishes from siblings by positioning as the first step before rendering or extracting, aligning with its name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Use this first to understand what data is available before rendering or extracting,' providing clear context for when to invoke. Lacks explicit when-not-to-use or alternatives, but the sibling tool list implies specialized tools for later steps.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Extract structured physics data for AI storytelling.
Analyzes simulation data to extract:
L2 FieldTopology: vortex detection (Q-criterion), critical points, centerline profiles, gradient statistics per field
L3 CaseContext: boundary conditions, transport properties, solver info, mesh quality, derived quantities (Re, Ma, etc.)
Returns structured JSON for LLM to build physics narratives. Replaces analyze_data with quantitative topology data instead of hardcoded heuristics.
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | Yes | Path to VTK/OpenFOAM/CGNS simulation file | |
| case_dir | No | OpenFOAM case directory for full solver metadata. If None, only mesh quality is extracted. | |
| fields | No | Specific field names to analyze (None = all fields) | |
| probe_lines | No | Number of auto centerline probe lines (1-3) | |
| vortex_threshold | No | Q-criterion threshold for vortex detection |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It details extracted data categories (vortex detection, boundary conditions, etc.) and returns structured JSON, implying read-only behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is three paragraphs, front-loaded with main purpose, and efficient in listing capabilities without unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given high schema coverage and output schema present, the description adequately explains input/output and tool replacement context, though it could mention file format compatibility.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, but the description adds no extra parameter details beyond the schema. Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Extract structured physics data for AI storytelling' with specific details like L2/L3 structures. It distinguishes from sibling 'analyze_data' by replacing hardcoded heuristics with quantitative topology data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says it replaces 'analyze_data' and outlines extraction of specific physics data, giving a clear alternative context. However, it does not provide exhaustive when-not-to-use scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Integrate a field over a surface to compute forces, areas, or fluxes.
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | Yes | Path to simulation file | |
| field_name | Yes | Field to integrate (e.g., "p", "wallShearStress") | |
| boundary | No | Boundary/block name to extract (e.g., "wall", "inlet") | |
| timestep | No | Timestep selection |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the entire burden. It mentions the outputs (forces, areas, fluxes) but does not disclose potential side effects, computational cost, or whether the operation is read-only.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words. It is front-loaded with the key action and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that all parameters are well-described in the schema and there is an output schema, the description is minimally complete. However, it lacks any context about typical usage, error cases, or performance considerations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds no additional meaning beyond the schema; it only repeats the concept of a surface and field.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Integrate a field over a surface' and specifies output types like forces, areas, or fluxes. It distinguishes this tool from siblings, none of which involve surface integration.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, nor any prerequisites or exclusions. It is a single sentence with no usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Sample field values along a line between two points.
Returns coordinate arrays and field values for plotting.
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | Yes | Path to simulation file | |
| field_name | Yes | Field to sample | |
| point1 | Yes | Start point [x, y, z] | |
| point2 | Yes | End point [x, y, z] | |
| resolution | No | Number of sample points | |
| timestep | No | Timestep selection |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses key behavioral aspects: it samples along a line and returns coordinate arrays and field values. However, it does not mention whether the tool is read-only or if it has side effects like creating a plot. With no annotations, the description partially informs but leaves ambiguity about mutability.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loaded with the core action, and contains no superfluous information. Every word contributes to clarifying the tool's function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema, the description does not need to detail return values, but it still mentions 'Returns coordinate arrays and field values for plotting,' which is helpful. It covers the essential purpose and a hint about output, but could be more explicit about default resolution or timestep handling.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds context about returning coordinate arrays and field values for plotting, which helps understand the purpose but does not add specific meaning beyond what the input schema provides. Since schema coverage is 100%, the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states that the tool samples field values along a line between two points and returns data for plotting. It names the resource (field values) and action (sample), making the purpose obvious. However, it does not explicitly differentiate from sibling tools like 'probe_timeseries' or 'extract_stats'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as 'probe_timeseries' for point sampling or 'slice' for planar sampling. There is no mention of prerequisites, use cases, or when not to use the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Export dataset to glTF/glB for interactive 3D viewing in a browser.
Returns the exported file path and a viewer URL hint. Requires VTK >= 9.4 with vtkGLTFExporter support.
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | Yes | ||
| field_name | No | ||
| timestep | No | ||
| output_filename | No | preview.glb |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses output (file path and viewer URL hint) and requirements, but does not mention side effects like file creation or overwriting, which is relevant for a file-exporting tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, no wasted words, front-loaded with purpose. Efficiently communicates essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, output, and requirements but lacks parameter details and usage context compared to siblings. Incomplete for a tool with 4 parameters and no schema descriptions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description adds no information about parameters like 'file_path', 'field_name', 'timestep', or 'output_filename'. Parameter names are somewhat self-explanatory but the description should clarify their roles.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly specifies 'Export dataset to glTF/glB for interactive 3D viewing in a browser.' Uses specific verbs and resources, distinguishing it from siblings like render or volume_render.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides a clear prerequisite (VTK >= 9.4 with vtkGLTFExporter support) but does not explicitly state when to use vs alternatives or when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Sample a field value at a fixed point across timesteps.
Useful for monitoring pressure/velocity at a sensor location over time. Returns dict with times and values arrays.
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | Yes | ||
| field_name | Yes | ||
| point | Yes | ||
| files | No | ||
| file_pattern | No | ||
| time_range | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It indicates a read-like operation ('sample') and mentions output structure, but lacks details on permissions, side effects, or limitations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences and a return-type line, front-loaded with the core action and purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 6 parameters (3 required) and an output schema, the description lacks sufficient detail on parameter usage and constraints, making it incomplete for an agent to properly invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description should compensate by explaining parameters, but it only loosely references 'fixed point' and 'field value', leaving file_path, files, file_pattern, and time_range unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'sample' and resource 'field value at a fixed point across timesteps', with concrete examples of pressure/velocity, and clearly distinguishes from sibling tools like extract_stats or inspect_data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a use case ('monitoring pressure/velocity at a sensor location') but does not explicitly state when not to use this tool or mention alternative sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run DualSPHysics IsoSurface to generate VTK surface mesh files.
Converts bi4 particle data into VTK surface meshes (iso-surfaces). The output files can then be used with animate() or render() via SourceDef(files=[...]) for visualization.
| Name | Required | Description | Default |
|---|---|---|---|
| bi4_dir | Yes | Directory containing bi4 data files | |
| output_dir | Yes | Directory for output VTK surface mesh files | |
| vars | No | Variable selection (e.g., "+vel,+press,+rhop") | +vel,+press,+rhop |
| only_type | No | Particle type filter (e.g., "+fluid") | +fluid |
| docker_image | No | Docker image with IsoSurface tool | dsph-agent:latest |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description must cover behavioral traits. It describes input/output but omits details about process side effects, destructive potential, or prerequisites beyond the default Docker image.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, efficiently front-loaded with purpose and downstream usage, containing no waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description explains the output's use with animate/render and includes an output schema, but could provide more context on when to choose this over similar siblings like contour.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 100% coverage, so baseline is 3. The description adds no additional semantics beyond the schema, as it does not mention any parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool runs DualSPHysics IsoSurface to generate VTK surface mesh files from bi4 particle data, which is specific and distinguishes it from siblings like animate, render, and contour.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage as a preprocessing step for visualization via animate() or render(), providing clear context but no explicit when-not-to-use or comparisons to alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Render a field visualization and return a PNG screenshot.
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | Yes | Path to simulation file | |
| field_name | Yes | Name of the field to visualize (e.g., "p", "U", "T") | |
| association | No | "POINTS" or "CELLS" | POINTS |
| colormap | No | Color map preset (e.g., "Cool to Warm", "Viridis", "Jet") | Cool to Warm |
| camera | No | Camera preset — isometric, top, front, right, left, back | isometric |
| scalar_range | No | [min, max] for color scale, None for auto | |
| purpose | No | Resolution preset — "analyze" (480p), "preview" (720p), "publish" (1080p) | analyze |
| width | No | Override width in pixels (must set both width and height, or neither) | |
| height | No | Override height in pixels (must set both width and height, or neither) | |
| timestep | No | Specific timestep, "latest", or None for first | |
| blocks | No | Multiblock region names to include | |
| output_filename | No | Output PNG filename (e.g., "snapshot_press.png") | render.png |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full behavioral disclosure burden. It correctly states the return type (PNG screenshot) but does not mention that the tool is read-only or that it requires no file modifications. The description is minimally adequate but could be improved with explicit safety hints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler words. It is front-loaded with the verb and resource, making it efficient and immediately informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 12 parameters (2 required) and no output schema, the one-sentence description is insufficient. It does not explain the visualization process, resolution presets, or common usage patterns. More context is needed for an agent to use it effectively among many similar tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 100% description coverage across all 12 parameters, so baseline is 3. The description adds no additional meaning beyond the schema; it only repeats the overall purpose. No parameter specifics are explained in the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Render a field visualization and return a PNG screenshot' clearly states the verb (render), resource (field visualization), and output (PNG screenshot). However, it does not differentiate this tool from siblings like 'cinematic_render' or 'batch_render', which also render visualizations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It lacks any context about criteria such as file readiness, prerequisites, or comparative advantages over similar tools like 'preview_3d' or 'volume_render'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a slice (cut plane) visualization.
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | Yes | Path to simulation file | |
| field_name | Yes | Field to visualize on the slice | |
| origin | No | Slice plane origin [x, y, z] | |
| normal | No | Slice plane normal [nx, ny, nz] | |
| colormap | No | Color map preset | Cool to Warm |
| camera | No | Camera preset | isometric |
| purpose | No | Resolution preset — "analyze" (480p), "preview" (720p), "publish" (1080p) | analyze |
| width | No | Override width in pixels (must set both width and height, or neither) | |
| height | No | Override height in pixels (must set both width and height, or neither) | |
| timestep | No | Timestep selection |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must fully explain behavioral traits. It only states the purpose without detailing side effects, requirements, or computational impact. Critical gaps remain.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (one sentence) and front-loaded, but it omits valuable context like parameter roles or usage hints. It is not overly verbose, but brevity sacrifices completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema is provided, and the description does not explain what the tool returns or its effects. Given the complexity (10 parameters, many siblings), the description is insufficient to fully understand the tool's behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds no parameter meaning beyond the schema, which already describes each field adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create a slice (cut plane) visualization' clearly states the tool's action and result. It distinguishes from general rendering tools but not from specific siblings like contour or volume_render.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites, exclusions, or context for selection among sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a split-pane synchronized animation with multiple views.
Render 2-4 panes in a grid layout, combining 3D visualizations with time-series graphs. All panes are timestep-synchronized and output as a single GIF or PNG sequence.
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | Yes | Path to simulation file (PVD, foam, etc.) | |
| panes | Yes | List of pane definitions (render or graph) | |
| layout | No | Grid layout {"rows": 2, "cols": 2, "gap": 4} | |
| fps | No | Frames per second (15-60) | |
| time_range | No | [start, end] physics time range | |
| speed_factor | No | Playback speed (1.0=real-time, 5.0=5x fast-forward) | |
| resolution | No | Total output [width, height] in pixels | |
| gif | No | Generate animated GIF (True) or PNG sequence only (False) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full burden but only mentions synchronization and output format. It fails to disclose potential side effects, file overwriting, permissions, or limitations, though it does add value beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary action, and contains no extraneous information. Every word contributes to understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 8 parameters and no output schema, the description provides a high-level overview but lacks details on output format (beyond GIF/PNG), error handling, or required file format. It is adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds minimal value beyond parameter descriptions, e.g., noting panes are synchronized, but does not explain open-ended parameters like pane definitions format.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates a split-pane synchronized animation with 2-4 panes combining 3D visualizations and time-series graphs, outputting a GIF or PNG sequence. This distinguishes it from siblings like 'animate' (likely single-pane) and 'render' (static).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for multi-pane synchronized animations but does not explicitly state when to use it over alternatives like 'animate' or 'batch_render'. No exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a streamline visualization for vector fields.
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | Yes | Path to simulation file | |
| vector_field | Yes | Name of the vector field (e.g., "U") | |
| seed_point1 | No | Start of seed line [x, y, z] | |
| seed_point2 | No | End of seed line [x, y, z] | |
| seed_resolution | No | Number of seed points | |
| max_length | No | Maximum streamline length | |
| colormap | No | Color map preset | Cool to Warm |
| camera | No | Camera preset | isometric |
| purpose | No | Resolution preset — "analyze" (480p), "preview" (720p), "publish" (1080p) | analyze |
| width | No | Override width in pixels (must set both width and height, or neither) | |
| height | No | Override height in pixels (must set both width and height, or neither) | |
| timestep | No | Timestep selection |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fails to disclose behavioral traits such as output format, error handling, or side effects. It is minimal and provides no assurance of safety or performance.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words, but front-loading could be improved by including key behavioral context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite a rich schema, the description lacks details about the tool's output, which is not defined by an output schema. It does not address integration with sibling tools or typical use cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers all 12 parameters with descriptions, achieving 100% coverage. The description adds no additional parameter meaning, so baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (create) and the specific resource (streamline visualization for vector fields), distinguishing it from sibling tools like contour, volume_render, and preview_3d.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided; the description does not specify when to use this tool over others or mention any prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Volume render 3D data (CT, MRI, CFD fields) with transfer function presets.
Presets: generic, ct_bone, ct_tissue, mri_brain, thermal, isosurface_like
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | Yes | Path to volumetric data (VTI, VTK structured grid, etc.) | |
| field_name | No | Scalar field to render, None for active scalars | |
| transfer_preset | No | Opacity preset (ct_bone, ct_tissue, mri_brain, thermal, generic, isosurface_like) | generic |
| colormap | No | Color map preset | viridis |
| quality | No | Render quality (draft/standard/cinematic/ultra/publication) | standard |
| lighting | No | Lighting preset | cinematic |
| background | No | Background preset | dark_gradient |
| width | No | Image width in pixels | |
| height | No | Image height in pixels | |
| scalar_range | No | [min, max] for color scale | |
| timestep | No | Specific timestep, "latest", or None | |
| output_filename | No | Output filename | volume.png |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description must imply behavior. It says 'volume render' but does not disclose that it saves an output file, requires file access, or has no destructive side effects. Minimal behavioral context beyond the action itself.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences plus a list of presets. No redundant information, but the brevity trades off with completeness. Front-loaded with key action and examples.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 12-parameter tool with no output schema, the description is too sparse. Missing details on return value (image file), typical usage patterns, or error conditions. Schema covers input but description doesn't integrate it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers all parameters (100% coverage), so baseline is 3. Description adds preset values for 'transfer_preset' but does not explain details like the effect of 'quality' or 'lighting' beyond their names. Does not compensate for schema's completeness.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States specific verb 'volume render' and resource '3D data', lists data types (CT, MRI, CFD) and presets, which clarifies domain. However, it does not differentiate from sibling tools like 'render' or 'preview_3d', lacking explicit distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like 'isosurface' or 'slice'. Does not mention prerequisites, limitations, or contexts where other tools are preferable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.8.0analyze_data3 fields changedInput schema / properties / domain / descriptionAdded value: +"Physics domain hint — \"cfd\", \"fea\", \"thermal\" (None for auto-detect)"Input schema / properties / file_path / descriptionAdded value: +"Path to VTK/OpenFOAM/CGNS file"Input schema / properties / focus / descriptionAdded value: +"Analyze only this field (None for all fields)"animate16 fields changedInput schema / properties / camera / descriptionAdded value: +"Camera preset (used for initial view in orbit mode)"Input schema / properties / colormap / descriptionAdded value: +"Color map preset"Input schema / properties / field_name / descriptionAdded value: +"Field to visualize"Input schema / properties / file_path / descriptionAdded value: +"Path to simulation file (or first file in series)"Input schema / properties / file_pattern / descriptionAdded value: +"Glob pattern for file series (e.g., \"/data/PartFluid_*.vtk\")"Input schema / properties / files / descriptionAdded value: +"Explicit list of file paths for VTK time series"Input schema / properties / fps / descriptionAdded value: +"Frames per second (15-60)"Input schema / properties / height / descriptionAdded value: +"Frame height"Input schema / properties / mode / descriptionAdded value: +"\"timesteps\" for time series, \"orbit\" for camera rotation"Input schema / properties / orbit_duration / descriptionAdded value: +"Orbit video length in seconds (orbit mode only)"Input schema / properties / output_format / descriptionAdded value: +"Output format — \"frames\" (PNG only), \"mp4\", \"webm\", or \"gif\""Input schema / properties / speed_factor / descriptionAdded value: +"Playback speed multiplier (1.0=real-time)"Input schema / properties / text_overlay / descriptionAdded value: +"Text to overlay on video frames (e.g., case name)"Input schema / properties / time_range / descriptionAdded value: +"[start, end] physics time range, None for all"Input schema / properties / video_quality / descriptionAdded value: +"Video CRF quality (lower=better, 18-28 typical, default 23)"Input schema / properties / width / descriptionAdded value: +"Frame width"auto_postprocess3 fields changedInput schema / properties / file_path / descriptionAdded value: +"Path to simulation file (.foam, .vtu, .vtk, etc.)"Input schema / properties / goal / descriptionAdded value: +"\"explore\" (overview), \"publish\" (publication quality), \"compare\" (multi-field)"Input schema / properties / max_iterations / descriptionAdded value: +"Maximum refinement iterations (1-5)"batch_render9 fields changedInput schema / properties / camera / descriptionAdded value: +"Camera preset"Input schema / properties / colormap / descriptionAdded value: +"Color map preset"Input schema / properties / fields / descriptionAdded value: +"List of field names to render"Input schema / properties / file_path / descriptionAdded value: +"Path to simulation file"Input schema / properties / height / descriptionAdded value: +"Override height in pixels (must set both width and height, or neither)"Input schema / properties / purpose / descriptionAdded value: +"Resolution preset — \"analyze\" (480p), \"preview\" (720p), \"publish\" (1080p)"Input schema / properties / quality / descriptionAdded value: +"Rendering quality (draft/standard/cinematic)"Input schema / properties / timestep / descriptionAdded value: +"Timestep selection"Input schema / properties / width / descriptionAdded value: +"Override width in pixels (must set both width and height, or neither)"cinematic_render19 fields changedInput schema / properties / azimuth / descriptionAdded value: +"Camera azimuth in degrees (None for auto from shape analysis)"Input schema / properties / background / descriptionAdded value: +"Background preset (dark_gradient, light_gradient, blue_gradient, publication, None)"Input schema / properties / colormap / descriptionAdded value: +"Color map preset (e.g., \"Cool to Warm\", \"Viridis\")"Input schema / properties / elevation / descriptionAdded value: +"Camera elevation in degrees (None for auto from shape analysis)"Input schema / properties / field_name / descriptionAdded value: +"Field to visualize (None for auto-detect)"Input schema / properties / file_path / descriptionAdded value: +"Path to simulation file"Input schema / properties / fill_ratio / descriptionAdded value: +"How much of viewport the object fills (0.0-1.0, default 0.75)"Input schema / properties / fxaa / descriptionAdded value: +"Enable Fast Approximate Anti-Aliasing"Input schema / properties / ground_plane / descriptionAdded value: +"Add a semi-transparent ground plane for shadow catching"Input schema / properties / height / descriptionAdded value: +"Override image height (None uses quality preset)"Input schema / properties / lighting / descriptionAdded value: +"Lighting preset (cinematic, dramatic, studio, publication, outdoor, None)"Input schema / properties / metallic / descriptionAdded value: +"PBR metallic factor (0.0-1.0)"Input schema / properties / output_filename / descriptionAdded value: +"Output PNG filename"Input schema / properties / quality / descriptionAdded value: +"Rendering quality preset"Input schema / properties / roughness / descriptionAdded value: +"PBR roughness factor (0.0-1.0)"Input schema / properties / scalar_range / descriptionAdded value: +"[min, max] for color scale, None for auto"Input schema / properties / ssao / descriptionAdded value: +"Enable Screen-Space Ambient Occlusion"Input schema / properties / timestep / descriptionAdded value: +"Specific timestep, \"latest\", or None for first"Input schema / properties / width / descriptionAdded value: +"Override image width (None uses quality preset)"clip11 fields changedInput schema / properties / camera / descriptionAdded value: +"Camera preset"Input schema / properties / colormap / descriptionAdded value: +"Color map preset"Input schema / properties / field_name / descriptionAdded value: +"Field to visualize"Input schema / properties / file_path / descriptionAdded value: +"Path to simulation file"Input schema / properties / height / descriptionAdded value: +"Override height in pixels (must set both width and height, or neither)"Input schema / properties / invert / descriptionAdded value: +"If True, keep the other side"Input schema / properties / normal / descriptionAdded value: +"Clip plane normal [nx, ny, nz]"Input schema / properties / origin / descriptionAdded value: +"Clip plane origin [x, y, z]"Input schema / properties / purpose / descriptionAdded value: +"Resolution preset — \"analyze\" (480p), \"preview\" (720p), \"publish\" (1080p)"Input schema / properties / timestep / descriptionAdded value: +"Timestep selection"Input schema / properties / width / descriptionAdded value: +"Override width in pixels (must set both width and height, or neither)"compare14 fields changedInput schema / properties / colormap / descriptionAdded value: +"Color map preset for both panels"Input schema / properties / field_name / descriptionAdded value: +"Field to compare (None for auto-detect)"Input schema / properties / file_a / descriptionAdded value: +"Path to first simulation file"Input schema / properties / file_b / descriptionAdded value: +"Path to second simulation file"Input schema / properties / height / descriptionAdded value: +"Override height in pixels (must set both width and height, or neither)"Input schema / properties / label_a / descriptionAdded value: +"Label for first panel (displayed top-left)"Input schema / properties / label_b / descriptionAdded value: +"Label for second panel (displayed top-left)"Input schema / properties / mode / descriptionAdded value: +"Comparison mode — \"side_by_side\" or \"diff\""Input schema / properties / output_filename / descriptionAdded value: +"Output PNG filename"Input schema / properties / purpose / descriptionAdded value: +"Resolution preset — \"analyze\" (480p), \"preview\" (720p), \"publish\" (1080p)"Input schema / properties / quality / descriptionAdded value: +"Rendering quality (draft/standard/cinematic)"Input schema / properties / scalar_range / descriptionAdded value: +"Shared [min, max] for consistent coloring (None for auto)"Input schema / properties / timestep / descriptionAdded value: +"Specific timestep, \"latest\", or None for first"Input schema / properties / width / descriptionAdded value: +"Override total width in pixels (must set both width and height, or neither)"compose_assets7 fields changedInput schema / properties / assets / descriptionAdded value: +"List of asset definitions (dicts with 'type' and type-specific keys)"Input schema / properties / fps / descriptionAdded value: +"Frames per second for video export (default 30)"Input schema / properties / height / descriptionAdded value: +"Output height in pixels (default 1080)"Input schema / properties / layout / descriptionAdded value: +"Layout mode — \"story\", \"grid\", \"slides\", or \"video\""Input schema / properties / scenes / descriptionAdded value: +"Scene definitions for video layout (list of dicts with\n asset_indices, duration, transition)"Input schema / properties / title / descriptionAdded value: +"Optional title text (used in story layout)"Input schema / properties / width / descriptionAdded value: +"Output width in pixels (default 1920)"contour9 fields changedInput schema / properties / camera / descriptionAdded value: +"Camera preset"Input schema / properties / colormap / descriptionAdded value: +"Color map preset"Input schema / properties / field_name / descriptionAdded value: +"Field for iso-surface extraction"Input schema / properties / file_path / descriptionAdded value: +"Path to simulation file"Input schema / properties / height / descriptionAdded value: +"Override height in pixels (must set both width and height, or neither)"Input schema / properties / isovalues / descriptionAdded value: +"List of iso-values to extract"Input schema / properties / purpose / descriptionAdded value: +"Resolution preset — \"analyze\" (480p), \"preview\" (720p), \"publish\" (1080p)"Input schema / properties / timestep / descriptionAdded value: +"Timestep selection"Input schema / properties / width / descriptionAdded value: +"Override width in pixels (must set both width and height, or neither)"execute_pipeline1 field changedInput schema / properties / pipeline / descriptionAdded value: +"Complete PipelineDefinition as JSON dict"extract_stats4 fields changedInput schema / properties / blocks / descriptionAdded value: +"Multiblock region names"Input schema / properties / fields / descriptionAdded value: +"List of field names to analyze"Input schema / properties / file_path / descriptionAdded value: +"Path to simulation file"Input schema / properties / timestep / descriptionAdded value: +"Timestep selection"inspect_data1 field changedInput schema / properties / file_path / descriptionAdded value: +"Path to the simulation file (e.g., /data/cavity.foam, /data/beam.vtu)"inspect_physics5 fields changedInput schema / properties / case_dir / descriptionAdded value: +"OpenFOAM case directory for full solver metadata.\n If None, only mesh quality is extracted."Input schema / properties / fields / descriptionAdded value: +"Specific field names to analyze (None = all fields)"Input schema / properties / file_path / descriptionAdded value: +"Path to VTK/OpenFOAM/CGNS simulation file"Input schema / properties / probe_lines / descriptionAdded value: +"Number of auto centerline probe lines (1-3)"Input schema / properties / vortex_threshold / descriptionAdded value: +"Q-criterion threshold for vortex detection"integrate_surface4 fields changedInput schema / properties / boundary / descriptionAdded value: +"Boundary/block name to extract (e.g., \"wall\", \"inlet\")"Input schema / properties / field_name / descriptionAdded value: +"Field to integrate (e.g., \"p\", \"wallShearStress\")"Input schema / properties / file_path / descriptionAdded value: +"Path to simulation file"Input schema / properties / timestep / descriptionAdded value: +"Timestep selection"plot_over_line6 fields changedInput schema / properties / field_name / descriptionAdded value: +"Field to sample"Input schema / properties / file_path / descriptionAdded value: +"Path to simulation file"Input schema / properties / point1 / descriptionAdded value: +"Start point [x, y, z]"Input schema / properties / point2 / descriptionAdded value: +"End point [x, y, z]"Input schema / properties / resolution / descriptionAdded value: +"Number of sample points"Input schema / properties / timestep / descriptionAdded value: +"Timestep selection"pv_isosurface5 fields changedInput schema / properties / bi4_dir / descriptionAdded value: +"Directory containing bi4 data files"Input schema / properties / docker_image / descriptionAdded value: +"Docker image with IsoSurface tool"Input schema / properties / only_type / descriptionAdded value: +"Particle type filter (e.g., \"+fluid\")"Input schema / properties / output_dir / descriptionAdded value: +"Directory for output VTK surface mesh files"Input schema / properties / vars / descriptionAdded value: +"Variable selection (e.g., \"+vel,+press,+rhop\")"render12 fields changedInput schema / properties / association / descriptionAdded value: +"\"POINTS\" or \"CELLS\""Input schema / properties / blocks / descriptionAdded value: +"Multiblock region names to include"Input schema / properties / camera / descriptionAdded value: +"Camera preset — isometric, top, front, right, left, back"Input schema / properties / colormap / descriptionAdded value: +"Color map preset (e.g., \"Cool to Warm\", \"Viridis\", \"Jet\")"Input schema / properties / field_name / descriptionAdded value: +"Name of the field to visualize (e.g., \"p\", \"U\", \"T\")"Input schema / properties / file_path / descriptionAdded value: +"Path to simulation file"Input schema / properties / height / descriptionAdded value: +"Override height in pixels (must set both width and height, or neither)"Input schema / properties / output_filename / descriptionAdded value: +"Output PNG filename (e.g., \"snapshot_press.png\")"Input schema / properties / purpose / descriptionAdded value: +"Resolution preset — \"analyze\" (480p), \"preview\" (720p), \"publish\" (1080p)"Input schema / properties / scalar_range / descriptionAdded value: +"[min, max] for color scale, None for auto"Input schema / properties / timestep / descriptionAdded value: +"Specific timestep, \"latest\", or None for first"Input schema / properties / width / descriptionAdded value: +"Override width in pixels (must set both width and height, or neither)"slice10 fields changedInput schema / properties / camera / descriptionAdded value: +"Camera preset"Input schema / properties / colormap / descriptionAdded value: +"Color map preset"Input schema / properties / field_name / descriptionAdded value: +"Field to visualize on the slice"Input schema / properties / file_path / descriptionAdded value: +"Path to simulation file"Input schema / properties / height / descriptionAdded value: +"Override height in pixels (must set both width and height, or neither)"Input schema / properties / normal / descriptionAdded value: +"Slice plane normal [nx, ny, nz]"Input schema / properties / origin / descriptionAdded value: +"Slice plane origin [x, y, z]"Input schema / properties / purpose / descriptionAdded value: +"Resolution preset — \"analyze\" (480p), \"preview\" (720p), \"publish\" (1080p)"Input schema / properties / timestep / descriptionAdded value: +"Timestep selection"Input schema / properties / width / descriptionAdded value: +"Override width in pixels (must set both width and height, or neither)"split_animate8 fields changedInput schema / properties / file_path / descriptionAdded value: +"Path to simulation file (PVD, foam, etc.)"Input schema / properties / fps / descriptionAdded value: +"Frames per second (15-60)"Input schema / properties / gif / descriptionAdded value: +"Generate animated GIF (True) or PNG sequence only (False)"Input schema / properties / layout / descriptionAdded value: +"Grid layout {\"rows\": 2, \"cols\": 2, \"gap\": 4}"Input schema / properties / panes / descriptionAdded value: +"List of pane definitions (render or graph)"Input schema / properties / resolution / descriptionAdded value: +"Total output [width, height] in pixels"Input schema / properties / speed_factor / descriptionAdded value: +"Playback speed (1.0=real-time, 5.0=5x fast-forward)"Input schema / properties / time_range / descriptionAdded value: +"[start, end] physics time range"streamlines12 fields changedInput schema / properties / camera / descriptionAdded value: +"Camera preset"Input schema / properties / colormap / descriptionAdded value: +"Color map preset"Input schema / properties / file_path / descriptionAdded value: +"Path to simulation file"Input schema / properties / height / descriptionAdded value: +"Override height in pixels (must set both width and height, or neither)"Input schema / properties / max_length / descriptionAdded value: +"Maximum streamline length"Input schema / properties / purpose / descriptionAdded value: +"Resolution preset — \"analyze\" (480p), \"preview\" (720p), \"publish\" (1080p)"Input schema / properties / seed_point1 / descriptionAdded value: +"Start of seed line [x, y, z]"Input schema / properties / seed_point2 / descriptionAdded value: +"End of seed line [x, y, z]"Input schema / properties / seed_resolution / descriptionAdded value: +"Number of seed points"Input schema / properties / timestep / descriptionAdded value: +"Timestep selection"Input schema / properties / vector_field / descriptionAdded value: +"Name of the vector field (e.g., \"U\")"Input schema / properties / width / descriptionAdded value: +"Override width in pixels (must set both width and height, or neither)"volume_render12 fields changedInput schema / properties / background / descriptionAdded value: +"Background preset"Input schema / properties / colormap / descriptionAdded value: +"Color map preset"Input schema / properties / field_name / descriptionAdded value: +"Scalar field to render, None for active scalars"Input schema / properties / file_path / descriptionAdded value: +"Path to volumetric data (VTI, VTK structured grid, etc.)"Input schema / properties / height / descriptionAdded value: +"Image height in pixels"Input schema / properties / lighting / descriptionAdded value: +"Lighting preset"Input schema / properties / output_filename / descriptionAdded value: +"Output filename"Input schema / properties / quality / descriptionAdded value: +"Render quality (draft/standard/cinematic/ultra/publication)"Input schema / properties / scalar_range / descriptionAdded value: +"[min, max] for color scale"Input schema / properties / timestep / descriptionAdded value: +"Specific timestep, \"latest\", or None"Input schema / properties / transfer_preset / descriptionAdded value: +"Opacity preset (ct_bone, ct_tissue, mri_brain, thermal, generic, isosurface_like)"Input schema / properties / width / descriptionAdded value: +"Image width in pixels"v0.7.0analyze_dataanimateauto_postprocessbatch_rendercinematic_renderclipcomparecompose_assetscontourexecute_pipelineextract_statsinspect_datainspect_physicsintegrate_surfaceplot_over_linepreview_3dprobe_timeseriespv_isosurfacerenderslicesplit_animatestreamlinesvolume_renderScored across 23 tools
Each tool has a clearly distinct purpose. Overlaps like multiple render tools are differentiated by quality presets and batch capabilities, and inspect_data vs inspect_physics serve different metadata levels. Deprecated tools are clearly marked.
Naming is inconsistent: some tools are single verbs (animate, render, slice), others are verb_noun (inspect_data, batch_render), and some are nouns (contour, streamlines). The mix of styles and a few odd names like pv_isosurface reduce coherence.
With 23 tools, the set is on the high side but still reasonable for a comprehensive simulation visualization server. The tools cover a wide range of operations without feeling excessive, but could be trimmed slightly.
The tool set offers strong coverage for simulation data analysis and visualization: inspection, multiple render styles, animations, statistics, and pipeline execution. Minor gaps like direct data export to common formats or advanced filtering are present but not critical.
Give your AI agents a design superpower. Generate, edit, and publish publication-grade decks, reports, landing pages, resumes, and marketing visuals directly within your agent workflow. Delivering frontier-level design quality at 3× the speed and 53× lower cost -from conversational prompt to live link or vector PDF in minutes.
Deterministic visual marketing engine. Your agent plans, renders, and posts on-brand campaigns.
AI visual generation agent: multi-pipeline rendering, prompt crafting, and image composition.
MD workbench for agents: 13 analysis tools, renders, hosted GPU runs; LAMMPS + OpenMM.
