Loading ToolBench
DEPRECATED - MCP server for ITASCA FLAC simulation control and documentation. Provides tools for browsing/searching ITASCA reference documentation and for executing simulation tasks and managing runs through an itasca-mcp-bridge HTTP service running inside FLAC3D.
This is a STDIO-only server with mixed definition quality. Tool definitions have basic structure but lack sophistication in descriptions and schema documentation. Most tools (7/10) have descriptions, but they are generic and under 100 chars, scoring 40-60. Parameter descriptions are minimal or absent. No visible output schema documentation. Error handling is implicit, not guided. The server exposes 10 tools split across documentation browsing, task execution, and code execution, a reasonable scope, but the tool interface does not follow agentic patterns for composition or guidance. Six tools operate over a remote bridge (execute_task, execute_code, etc.), and two (query_command, query_python_api) use BM25 search with documented limit defaults (10). Tool naming is mostly verb-first and unambiguous, which is a strength. However, parameter handling is weak: task execution tools lack timeout guidance, description fields, or confirmation flows. Documentation tools lack schema definitions for returned search results or API documentation structures. The server is marked DEPRECATED in pyproject.toml ('use itasca-mcp'), which suggests this codebase is not maintained.
Browse ITASCA FLAC command documentation
Browse ITASCA FLAC Python API documentation
Browse ITASCA FLAC reference documentation
Check the status and output of a previously submitted FLAC3D task
Execute Python code directly in FLAC3D via the itasca-mcp-bridge
Submit a FLAC3D task (script execution) to the itasca-mcp-bridge for execution
Interrupt/cancel a running FLAC3D task
No visible output schema documentation for any tool. Documentation tools (browse_commands, browse_python_api, browse_reference, query_command, query_python_api) do not document what they return, LLMs cannot plan downstream actions or extract required fields for task submission. Search tools should document result structure (e.g., list of {name, category, summary} items) so agents know what data is available.
Parameter descriptions are missing or minimal for many tools. execute_task has 'script_path' and 'description' but no constraint hints (e.g., 'Absolute path to .py or .flac file' or 'What is this task trying to accomplish?'). execute_code has only 'Python code to execute', no guidance on imports, scope, or expected return values. check_task_status's skip_newest and limit parameters have basic descriptions but no ranges (e.g., 'limit: 1-1000').
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 49 | <=2025-11-25 | v2 |
List submitted FLAC3D tasks with pagination support
Search ITASCA FLAC command documentation using BM25 full-text search
Search ITASCA FLAC Python API documentation using BM25 full-text search
Irreversible tools (execute_task, execute_code) lack confirmation/dry-run patterns. No evidence of pre-execution confirmation or detailed error messages if submission fails. An LLM could submit a destructive script without review. Production tool design requires confirmation flows for irreversible operations.
Tool composition risk: execute_task and execute_code both submit code to a remote bridge, but there is no visible way to validate/preview script syntax before submission. No dry-run or syntax-check tool. An agent must call execute_task or execute_code blindly, then check_task_status to discover errors, wasteful and prone to mid-chain failures.
Error handling not documented. No evidence in descriptions of what errors tools can raise, what they mean, or how LLMs should recover. E.g., execute_task could fail with 'Script not found', 'Bridge connection timeout', 'License expired', or 'Syntax error in script', but LLMs are given no guidance on which are retryable or how to self-correct.
Documentation tools lack specificity. browse_commands, browse_python_api, browse_reference all use a string parameter (category/module/topic) with no enum or validation hints. An LLM does not know what categories, modules, or topics exist, it must guess or call tools blindly. Should provide discovery tool or document valid values.
Tool names 'execute_task' and 'execute_code' are generic and do not distinguish intent clearly. LLMs cannot easily determine: should I call execute_task or execute_code? Do they differ only by input format, or do they have different retry semantics, output formats, or permission gates? Consider submit_flac_script and execute_python_code for clarity.