Loading ToolBench
A FastMCP server for R data visualization and script execution using ggplot2, with Docker-based execution, caching, and PII protection
R-Server MCP provides 7 tools with reasonable naming and decent descriptions, but suffers from moderate schema incompleteness, missing parameter type information, and insufficient error handling guidance. Most tools have descriptions (good baseline), but parameter descriptions are sparse and output schemas are not documented. The server executes R code in Docker containers, a security-conscious design, but the tool interface itself lacks the specificity and validation guidance needed for robust agent use. Tools are moderately well-named (execute_r_code, install_r_package) but descriptions lack actionable recovery guidance and don't clearly distinguish when to call similar tools (e.g., execute_r_code vs execute_r_file). Input schemas are partially visible but lack type annotations on several parameters (e.g., repos in install_r_package shown as string but no format/pattern constraints).
Create a ggplot2 visualization from data with automatic plot rendering and base64 encoding
Execute R code in a Docker container with automatic library installation, error handling with line numbers, and optional plot return
Execute an R script from a file path in a mounted directory with optional output capture
Get information about the R environment including version, installed packages, and loaded libraries
Install R packages using install.packages() or remotes::install_github()
List all mounted directories accessible to R scripts
Read a CSV file from a mounted directory into R as a data frame
Parameter descriptions are incomplete or missing for critical input fields. install_r_package 'repos' parameter lacks format constraints (CRAN URL format, defaults, validation range). create_ggplot aesthetic_mapping and geom_layers accept freeform strings with no examples, format guidance, or error recovery hints.
Output schemas are not documented. Tools return results but the response structure (fields, types, whether paginated) is not specified. LLMs cannot plan downstream calls without knowing what fields are available. E.g., execute_r_code returns what exactly? A string? JSON? Structured object with stdout/stderr/plots?
Error handling is not recovery-guided. If execute_r_code fails (syntax error, missing library, permission denied), the tool provides no suggestions for next steps. No dry-run or confirmation step for destructive operations (save_session, sanitize_output behaviors).
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 48 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 19 | - | v1 |
Parameter type annotations are incomplete. Several parameters are shown as type 'string' or 'array' but lack min/max lengths, enums, regex patterns, or constraints. E.g., repos (string, any CRAN URL?), file_path (string, absolute or relative? must be in mounted dirs?), aesthetic_mapping (any ggplot syntax?). This forces LLMs to guess valid formats.
Tool descriptions do not clarify mutual dependencies or sequencing. When should an agent call execute_r_code vs execute_r_file? Both can execute R, the description doesn't explain 'use execute_r_code for inline snippets, execute_r_file for reusable scripts.' Similarly, read_csv loads data, but the description doesn't hint 'call list_mounted_directories first if you don't know available paths.'
Dangerous boolean defaults without clear side effects. Parameters like save_session and sanitize_output are booleans but the descriptions don't clearly state their default values or the consequences. If save_session defaults to false, an LLM expecting persistence might waste setup time. If it defaults to true, it might overwrite user workspaces unexpectedly.