Loading ToolBench
MCP server for discovering, understanding, and generating Teal R Shiny applications for clinical trial data analysis
TealFlowMCP demonstrates solid definition quality with comprehensive descriptions and proper schema structures for a domain-specific MCP server focused on Teal R/Shiny applications. All 14 tools have descriptions and properly defined input schemas with types. However, there are systematic gaps in output schema documentation, parameter constraint clarity, and error handling guidance. The server's heavy reliance on path-based filesystem operations introduces security and usability concerns that are not adequately mitigated in the current definitions.
Get comprehensive guidance for assisting users with Teal application development. ⚠️ IMPORTANT: This tool MUST be called FIRST whenever a user requests: - Creating a Teal application or Teal app - Adding Teal modules to an app - Building clinical trial analysis applications - Survival analysis, safety analysis, efficacy analysis, or any clinical data analysis - Working with Statistical Analysis Plans (SAP) - Understanding Teal modules or datasets - Any other Teal-related task. This tool provides the complete agent usage guide that includes: - Your role and responsibilities as a Teal assistant - Available MCP tools and when to use them - Step-by-step workflow guidance for common scenarios - Teal framework knowledge (modules, datasets, architecture) - Important module constraints and special cases - Development philosophy and R code style guidelines - Best practices for agent behavior - Example workflows for common tasks
Check if a module's dataset requirements are satisfied by the available datasets. Validates dataset compatibility and provides detailed feedback about which requirements are met and which are missing.
Check if a Shiny app starts without errors. Runs shiny::runApp() on the specified file in the directory with a timeout, captures output, and returns structured information about startup status.
Discover datasets in a specified directory by scanning for data files matching a pattern and supported formats. Returns structured information about each discovered dataset.
Missing output schema documentation for all tools. Tool descriptions do not specify what fields/structure will be returned, making it impossible for LLMs to plan downstream calls or extract data reliably.
Filesystem path parameters (data_directory, file_path, project_path, app_path) lack validation rules, sanitization guidance, and traversal prevention. These are security-sensitive inputs that could enable path injection attacks. No description of path resolution rules (absolute vs relative, working directory baseline).
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 64 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 45 | - | v1 |
Generate R code to load discovered datasets into a Teal app environment. Creates appropriate loading code for each dataset based on its file format.
Generate R code for a specific Teal module with optional parameter overrides and explanatory comments.
Get a template Teal application file that can be used as a starting point for creating new Teal apps. Provides boilerplate code with standard setup and module configuration.
Get comprehensive information about a dataset file including structure, column types, and sample values. Reads .rds or .csv files and provides metadata.
Get comprehensive details about a specific Teal module including all parameters and R help documentation. This tool provides complete information about a module's required and optional parameters, their types, default values, descriptions, and official R help documentation. Use this after discovering a module to understand how to configure it properly.
List default datasets available in Teal Flow framework. Provides information about standard ADaM datasets and their structures.
List all available Teal modules with their descriptions and dataset requirements. This tool helps discover what analysis modules are available in the Teal framework. Modules can be filtered by package (clinical vs general) and optionally by category. Clinical modules are designed for clinical trial reporting and work with ADaM datasets. General modules are for general-purpose data exploration and work with any data.frame.
Search for modules by analysis type using structured categories and text matching. First attempts exact/partial category matches from predefined analysis types, then falls back to text search across module descriptions. Scores and ranks results by relevance.
Set up renv environment for an R project by initializing renv and installing required dependencies for Teal development.
Create a snapshot of the current renv environment state in an R project. Records all package versions in renv.lock file for reproducibility.
No error handling guidance across any tool. Error responses should tell LLMs what to do next (e.g., 'File not found, check path or call tealflow_discover_datasets() to find available files'). Current pattern provides only generic descriptions.
Destructive operations (tealflow_setup_renv_environment, tealflow_snapshot_renv_environment) lack dry-run or confirmation patterns. These tools modify the user's R environment and package lock files without a safety check. No description of what will be overwritten or how to undo changes.
Parameters with default values that could cause unintended side effects: tealflow_setup_renv_environment defaults project_path to '.', and tealflow_check_shiny_startup defaults app_filename to 'app.R'. If an LLM omits these params, it may operate on the wrong project or expect a different file structure. Defaults should be explicit in descriptions.
tealflow_discover_datasets uses a hardcoded 'AD*' pattern default without explaining why. Descriptions should clarify: What does AD* match? Why is it the default? How should users change the pattern for non-ADaM datasets? Missing this context makes it opaque why some datasets are or aren't discovered.
tealflow_check_shiny_startup has a timeout_seconds parameter with min=1, max=120, but no guidance on what timeout values to use or what constitutes a 'startup' in Shiny context (app listening, first render complete?). Description lacks clarity on interpretation.
tealflow_generate_module_code and tealflow_generate_data_loading accept 'parameters' and 'datasets' objects without specifying the internal structure (keys, value types, nested fields). LLMs cannot infer valid structures from type='object'. A schema or example is needed.
response_format parameter is repeated across 11 tools with identical enums ('markdown', 'json'). No guidance on when LLMs should use each. Should be documented once in a helper pattern or clarified per tool (e.g., 'markdown for human display, json for agent parsing').