Loading ToolBench
MCP server exposing MATLAB capabilities to AI agents via FastMCP. Enables MATLAB code execution, workspace management, job scheduling, file operations, function discovery, plotting with Plotly conversion, and custom tool support.
The server exposes 17 tools across MATLAB operations (code execution, workspace management, job tracking, file I/O, discovery). Tool naming generally follows verb_noun patterns (execute_code, get_workspace, list_jobs). Descriptions exist for all tools and are reasonably specific (avg ~100 chars). However, critical gaps exist: (1) Input schemas are inferred from scripts/generate_docs.py rather than directly visible in source; actual tool registration code is not shown in the sample. (2) Parameter descriptions are minimal, only tool-level descriptions are evident; individual parameter detail is assumed but not confirmed. (3) No output schemas are documented. (4) Error handling guidance is absent from descriptions. (5) STDIO transport is a hard cap. The server shows thoughtful architecture (security validator, job tracker, pool manager) but the tool definition quality falls short of production grade due to missing schema visibility and sparse parameter documentation.
Cancel a running or pending asynchronous job
Validate MATLAB code for syntax errors and security issues without execution
Delete a file from the session temporary directory
Execute MATLAB code synchronously or asynchronously, returning workspace variables and side effects
Retrieve documentation and usage help for a MATLAB function or topic
Retrieve the output and workspace from a completed asynchronous job
Query the current status of an asynchronous MATLAB job
Input schemas inferred from generate_docs.py rather than visible in actual tool registration code. Cannot verify that all tools are registered with complete JSON Schema definitions in FastMCP.
No output schemas documented anywhere in provided source. Tools like execute_code, get_workspace, and get_job_result return results but LLMs have no way to know the structure of those results without calling the tool blind.
Parameter-level descriptions are not visible in source. Each parameter (code, sync, job_id, filename, pattern, format, etc.) needs its own description explaining format, constraints, and valid values, but none are documented.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 56 | 2026-07-28+ | v2 |
Get the current status of the MATLAB engine pool
Retrieve all variables from the current MATLAB workspace with automatic type conversion
List all files in the session temporary directory
List available functions from a specific category or toolbox
List all asynchronous jobs in the tracker with their status and progress
List all installed MATLAB toolboxes with version information
Read a data file (CSV, JSON, MAT) and return its contents
Read an image file and return as base64-encoded PNG or with pixel data
Read and display a MATLAB script file from the session directory
Upload a data file (CSV, MAT, JSON, Excel) to the workspace
No error handling guidance in tool descriptions. Tools like delete_file (DESTRUCTIVE risk) and execute_code (WRITE risk) do not explain failure modes, recovery steps, or confirmation requirements.
Destructive operations lack confirmation or dry-run. delete_file has no confirmation step documented; execute_code (WRITE) and upload_data should support a preview/validate mode before committing.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint) visible in source. FastMCP supports these, but they are not declared, limiting LLM awareness of operation safety.
list_* and read_* tools return potentially large result sets with no pagination. list_jobs, list_toolboxes, list_functions, get_help may return unbounded results, risking context window exhaustion.
Parameter names lack type qualifiers. 'filename' could be ambiguous (is it a path? a name only?). 'pattern' in list_functions is not clearly 'regex pattern' or 'glob pattern' in the description provided.
Security validator exists in code (SecurityValidator) but tool descriptions do not document what code security checks are applied. Agents cannot reason about safety guarantees.
No indication whether tools are idempotent. If an agent retries execute_code with the same code, will it re-run and create duplicate side effects, or is it idempotent?