Provides tools for R package development (testing, documentation, building, checking, loading) and jamovi module development, integrating with RStudio Desktop via the Model Context Protocol.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@rstudio-mcp-server Run the tests for my R package"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A Model Context Protocol (MCP) server for RStudio Desktop integration, enabling seamless R package development, testing, and jamovi module development from VSCode and other MCP clients.
Testing: Run package tests with devtools::test() or individual test files with testthat::test_file()
Documentation: Generate documentation with devtools::document() (roxygen2)
Building: Build packages with devtools::build()
Checking: Run R CMD check with devtools::check()
Loading: Load package functions with devtools::load_all() for interactive development
Build: Build jamovi modules with jmvtools::build()
Check: Validate jamovi modules with jmvtools::check()
Code Execution: Run arbitrary R code
Package Management: Install and list packages
Workspace Inspection: List and inspect R workspace objects
Related MCP server: ClaudeR
Run the automated setup script to check prerequisites and configure everything:
# Clone the repository
git clone <repository-url>
cd rstudio-mcp-server
# Run automated setup
npm run setupThe setup script will:
Check Node.js and R installation
Install npm dependencies
Build the server
Verify R package requirements
Guide you through MCP client configuration
If you prefer manual setup:
Install Prerequisites
Node.js v18 or higher (nodejs.org)
R 3.6 or higher with Rscript in PATH
Git (for cloning)
Clone and Build
git clone <repository-url>
cd rstudio-mcp-server
npm install
npm run buildInstall R Packages
install.packages(c("devtools", "testthat", "roxygen2"))Configure MCP Client (see Configuration section below)
Add to your Claude Code MCP settings file (usually ~/.config/claude-code/mcp_settings.json on Linux/Mac or %APPDATA%\claude-code\mcp_settings.json on Windows):
{
"mcpServers": {
"rstudio": {
"command": "node",
"args": ["/path/to/rstudio-mcp-server/build/index.js"]
}
}
}Add to the appropriate MCP settings file for your client:
{
"mcpServers": {
"rstudio": {
"command": "node",
"args": ["/absolute/path/to/rstudio-mcp-server/build/index.js"]
}
}
}Execute arbitrary R code.
Parameters:
code (required): The R code to execute
working_dir (optional): Working directory for execution
Example:
{
"code": "summary(mtcars)",
"working_dir": "/path/to/project"
}Run tests for an R package using devtools::test().
Parameters:
package_path (required): Path to the R package directory
filter (optional): Test filter pattern (regex)
Example:
{
"package_path": "/path/to/mypackage",
"filter": "test-myfunction"
}Run a specific test file.
Parameters:
test_file (required): Path to the test file
Example:
{
"test_file": "/path/to/mypackage/tests/testthat/test-myfunction.R"
}Run R CMD check on a package.
Parameters:
package_path (required): Path to the R package directory
args (optional): Additional arguments for R CMD check
Example:
{
"package_path": "/path/to/mypackage",
"args": "--as-cran"
}Generate documentation for an R package using roxygen2.
Parameters:
package_path (required): Path to the R package directory
Build an R package.
Parameters:
package_path (required): Path to the R package directory
binary (optional): Build a binary package (default: false)
Load all functions in a package for interactive development.
Parameters:
package_path (required): Path to the R package directory
Install an R package from CRAN or local path.
Parameters:
package (required): Package name or path
dependencies (optional): Install dependencies (default: true)
List all installed R packages.
List objects in the R workspace.
Parameters:
pattern (optional): Pattern to filter object names
Build a jamovi module.
Parameters:
module_path (required): Path to the jamovi module directory
install (optional): Install the module after building (default: false)
Check a jamovi module for issues.
Parameters:
module_path (required): Path to the jamovi module directory
Once configured, you can interact with R through natural language:
Test R connection:
"Can you list all installed R packages?"
"What version of R is running?"
"Execute this R code: print(sessionInfo())"
Package development:
"Run the tests for this package"
"Generate documentation for my package"
"Check if this package passes R CMD check"
"Build this package"
Code execution:
"Execute this R code: summary(mtcars)"
"Install the tidyverse package"
"Show me what objects are in the workspace"
You: "I'm creating a new R package called 'datautils'. Can you help me set it up?"
Claude: [Guides you through using usethis::create_package()]
You: "Now document the package"
Claude: [Uses r_document_package tool]
Output: ✔ Writing 'NAMESPACE'
✔ Writing 'datautils.Rd'
You: "Check if it passes R CMD check"
Claude: [Uses r_check_package tool]
Output: ── R CMD check results ─────────────────────
0 errors ✔ | 0 warnings ✔ | 0 notes ✔You: "Run all tests in the package"
Claude: [Uses r_test_package tool]
Output: ✔ | F W S OK | Context
✔ | 5 | validation
✔ | 8 | data-processing
✔ | 3 | output-formatting
You: "Run only tests matching 'validation'"
Claude: [Uses r_test_package with filter: "validation"]
Output: ✔ | F W S OK | Context
✔ | 5 | validation
You: "Run the specific test file test-validation.R"
Claude: [Uses r_test_file tool]
Output: Test results for tests/testthat/test-validation.R
✔ | 5 tests passedYou: "Run the package tests"
Claude: [Uses r_test_package tool]
Output: ✖ | F W S OK | Context
✖ | 1 4 | validation
────────────────────────────────────────────
Failure (test-validation.R:15:3): input validation works
Expected TRUE, got FALSE
You: "Can you execute this R code to debug:
source('R/validation.R');
validate_input(c(1, 2, NA))"
Claude: [Uses r_execute tool]
Output: Error: NA values not allowed
You: "Now I see the issue. Let me fix the code and re-run tests..."You: "I'm ready to release my package. Let's go through the checklist."
Claude: "I'll help you verify everything:
1. First, let's run the tests"
[Uses r_test_package - shows all passing]
Claude: "2. Generating documentation"
[Uses r_document_package]
Claude: "3. Running R CMD check"
[Uses r_check_package with args: "--as-cran"]
Claude: "4. Building the package"
[Uses r_build_package]
Output: ✔ Building 'datautils_1.0.0.tar.gz'
You: "Perfect! Can you also check for any spelling issues?"
Claude: [Uses r_execute with "spelling::spell_check_package()"]You: "I'm working on a jamovi module. Can you check it for issues?"
Claude: [Uses jamovi_check_module tool]
Output: ✔ Checking module structure
✔ Validating .a.yaml files
✔ Checking R functions
✔ Verifying UI definitions
You: "Build and install the module"
Claude: [Uses jamovi_build_module with install: true]
Output: ✔ Building module
✔ Installing to jamovi
Module 'mymodule' installed successfully
You: "Now I'll test it in jamovi..."You: "Can you execute this analysis:
library(dplyr)
mtcars %>%
group_by(cyl) %>%
summarize(
mean_mpg = mean(mpg),
mean_hp = mean(hp)
)"
Claude: [Uses r_execute tool]
Output: # A tibble: 3 × 3
cyl mean_mpg mean_hp
<dbl> <dbl> <dbl>
1 4 26.7 82.6
2 6 19.7 122.
3 8 15.1 209.
You: "Now create a linear model of mpg vs hp"
Claude: [Uses r_execute tool]
Output: Call:
lm(formula = mpg ~ hp, data = mtcars)
Coefficients:
(Intercept) hp
30.09886 -0.06823You: "Install the ggplot2 package"
Claude: [Uses r_install_package tool]
Output: Installing package into '/home/user/R/library'
✔ Package 'ggplot2' successfully installed
You: "List all packages containing 'test' in the name"
Claude: [Uses r_list_packages tool, then filters]
Output: Packages matching 'test':
- testthat (3.2.0)
- testit (0.13)
- covr (3.6.1)You: "I have three packages I'm developing. Can you run tests on all of them?
- /path/to/package1
- /path/to/package2
- /path/to/package3"
Claude: "I'll test each package:
Package 1:
[Uses r_test_package for package1]
✔ All 15 tests passed
Package 2:
[Uses r_test_package for package2]
✔ All 22 tests passed
Package 3:
[Uses r_test_package for package3]
✖ 2 tests failed
[Shows failure details]
Two packages passed, but package3 has failing tests. Would you like me to show the specific failures?"You: "I'm setting up a new development machine. What R packages do I need?"
Claude: "Let me check what's installed"
[Uses r_list_packages tool]
Claude: "I see you're missing some key development packages. I can install:
- devtools (package development)
- testthat (testing)
- roxygen2 (documentation)
- usethis (workflow automation)
Should I install these?"
You: "Yes, please install them"
Claude: [Uses r_install_package for each package]
✔ All development packages installedYou: "I want to make sure my package will pass CI checks. Run all quality checks."
Claude: "I'll run a comprehensive check:
1. Tests:
[Uses r_test_package]
✔ All 45 tests passed
2. Documentation:
[Uses r_document_package]
✔ Documentation up to date
3. R CMD check:
[Uses r_check_package with args: "--as-cran"]
✔ 0 errors | 0 warnings | 0 notes
4. Package build:
[Uses r_build_package]
✔ Package builds successfully
Your package is ready for CI! All checks passed."Quick test after code changes:
"Run the tests"Full pre-commit check:
"Run tests, update docs, and run R CMD check"Install development dependencies:
"Install devtools, testthat, and roxygen2"Debug a specific function:
"Execute this code: debugonce(my_function); my_function(test_data)"Check test coverage:
"Execute: covr::package_coverage()"Spell check documentation:
"Execute: spelling::spell_check_package()"Watch mode for development:
npm run watchMake sure R and Rscript are in your system PATH:
which Rscript # Linux/Mac
where Rscript # WindowsWindows PATH setup:
Find your R installation (usually C:\Program Files\R\R-4.x.x\bin)
Add to PATH:
Search "Environment Variables" in Start menu
Edit "Path" under System variables
Add new entry: C:\Program Files\R\R-4.x.x\bin
Restart terminal/VSCode
Multiple R versions:
Ensure the correct R version is first in PATH
Check with: Rscript --version
Install required R packages:
install.packages(c("devtools", "testthat", "roxygen2"))Installing jmvtools requires special considerations. See JMVTOOLS_INSTALLATION.md for detailed instructions.
Quick summary:
Option 1: Install Rtools (Windows) or build tools (Mac/Linux), then install.packages("jmvtools")
Option 2: Use jamovi's bundled R (recommended for jamovi developers)
Option 3: Install pre-built binaries
Common issue: jmvtools requires compilation tools:
Error: package 'jmvtools' is not availableSee the dedicated jmvtools guide for platform-specific solutions.
TypeScript errors:
# Clean rebuild
rm -rf build node_modules
npm install
npm run buildPermission errors:
# Linux/Mac
chmod +x build/index.js
# Windows: Run terminal as Administrator if neededServer not appearing in MCP client:
Verify JSON syntax in config file (use a JSON validator)
Use absolute paths (not relative: ~/ or .\)
Restart the MCP client completely
Check client logs for error messages
Windows path format:
{
"args": ["D:\\path\\to\\server\\build\\index.js"] // Use double backslashes
// OR
"args": ["D:/path/to/server/build/index.js"] // Use forward slashes
}Contributions are welcome! Please feel free to submit issues or pull requests.
MIT
Build a jamovi module using jmvtools
| Name | Required | Description | Default |
|---|---|---|---|
| install | No | Install the module after building (default: false) | |
| module_path | Yes | Path to the jamovi module directory |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description only mentions 'using jmvtools' without disclosing behaviors like destructive potential, prerequisites, or side effects.
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?
Single sentence is concise and front-loaded, but may be too minimal for the tool's complexity.
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?
Missing details on return values, side effects, and prerequisites; minimal for a build tool with no output schema or annotations.
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?
Both parameters are described in the input schema (100% coverage); description adds no additional meaning beyond that.
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 clear verb ('Build') and resource ('jamovi module'), but does not differentiate from sibling tools like jamovi_check_module.
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 such as jamovi_check_module or r_build_package.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check a jamovi module for common issues
| Name | Required | Description | Default |
|---|---|---|---|
| module_path | Yes | Path to the jamovi module directory |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must disclose behavior. It only says 'check for common issues' without specifying if it modifies state, returns output, or what constitutes common issues. Lacks behavioral detail.
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?
Single sentence, no waste. However, it is too concise and lacks substance, making it borderline under-specified. Still, it earns a 4 for brevity without redundancy.
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 a simple tool with one parameter and no output schema, the description should at least hint at what 'common issues' means or the format of results. It is incomplete for an agent to use effectively.
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?
One parameter 'module_path' with schema description 'Path to the jamovi module directory'. Schema coverage is 100%, so description adds no extra value beyond the schema. 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 tool checks a jamovi module for common issues, with a specific verb and resource. It distinguishes from sibling tools like jamovi_build_module (build) and r_check_package (R package check).
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, no prerequisites or exclusions. The description is too brief to inform usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Build an R package using devtools::build()
| Name | Required | Description | Default |
|---|---|---|---|
| binary | No | Build a binary package (default: false) | |
| package_path | Yes | Path to the R package directory |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description is minimal: 'Build an R package using devtools::build()'. Does not disclose side effects, prerequisites, or whether it's a read/write operation.
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?
Single sentence, front-loaded with purpose. Concise but could be slightly more structured (e.g., listing effects).
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. Description lacks context about build artifacts, success/failure indicators, or any constraints like required R environment. Incomplete for a build 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?
Schema covers 100% of parameters (package_path, binary) with descriptions. Description adds no further meaning; baseline 3 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 clearly states it builds an R package using devtools::build(), but does not differentiate from sibling tools like r_install_package or r_check_package.
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 (e.g., build vs check vs install). Agent given no decision criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run R CMD check on a package using devtools::check(). Essential for package development.
| Name | Required | Description | Default |
|---|---|---|---|
| args | No | Optional additional arguments for R CMD check | |
| package_path | Yes | Path to the R package directory |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description does not disclose side effects, permissions needed, or whether it modifies files. Only states it runs a check, but behavioral traits like read-only nature are not explicit.
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, efficient. First sentence clearly states action and method. Second sentence emphasizes importance. No 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 lack of output schema and the tool's role in development, description is too sparse. Does not mention output format, common errors, or how to interpret results. Requires user knowledge to use effectively.
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 both parameters with descriptions. Description adds no additional semantic information beyond what's in 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?
Describes verb 'run' and resource 'package', specifically using devtools::check(). Distinguishes from sibling tools like r_build_package or r_test_package by naming the exact R function and implying a quality check step.
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 explicit guidance on when to use this tool versus alternatives. Only says it's essential, but doesn't mention scenarios where others might be preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate documentation for an R package using devtools::document() (roxygen2)
| Name | Required | Description | Default |
|---|---|---|---|
| package_path | Yes | Path to the R package directory |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It only states the underlying function (devtools::document()) but fails to mention that it modifies the package directory (creates .Rd files, updates NAMESPACE) or whether it is destructive or idempotent. The agent lacks critical behavior insights.
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 concise sentence of 10 words, front-loaded with the essential action. Every word is meaningful, and there is no redundancy.
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 simplicity (1 parameter, no output schema), the description is minimally adequate. However, it lacks context on outcomes (e.g., what files are generated), prerequisites, and error conditions. A slightly fuller description would improve completeness.
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 covers 100% of the single parameter with a clear description ('Path to the R package directory'). The tool description adds no additional meaning beyond the schema, 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 tool generates documentation for an R package using devtools::document() and roxygen2. It uses a specific verb and resource, distinguishing it from sibling tools like r_build_package or r_check_package that perform different actions.
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 explicit guidance on when to use this tool versus alternatives. It does not mention prerequisites, such as requiring roxygen comments, or scenarios where this tool is appropriate (e.g., after editing documentation, before building). The user must infer usage from the tool's name and context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Execute R code and return the output. Useful for running R commands, data analysis, or quick tests.
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | The R code to execute | |
| working_dir | No | Optional working directory for execution |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only mentions execution and output, omitting important details like side effects, security, error handling, or environment constraints.
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 concise: two sentences front-load the purpose and use cases with no wasted 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?
For a code execution tool, the description is insufficient. It lacks details about return format, error capture, environment, and dependencies, leaving significant gaps in user understanding.
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% (both parameters have descriptions). The tool description adds no additional meaning beyond the schema, meeting the baseline but not exceeding it.
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 executes R code and returns output, with examples like running commands, data analysis, or tests. This distinguishes it from siblings focused on package development.
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 suggests use cases but does not explain when not to use this tool or compare to siblings. No explicit alternatives or exclusions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Install an R package from CRAN or local path
| Name | Required | Description | Default |
|---|---|---|---|
| package | Yes | Package name (for CRAN) or path (for local) | |
| dependencies | No | Install dependencies (default: true) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility. It fails to disclose that installing a package may modify the R library, require internet access for CRAN downloads, or overwrite existing packages. The description only states the action without side effects.
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, concise sentence that efficiently conveys the tool's purpose. Every word contributes meaning, with no unnecessary elaboration.
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 simple two-parameter tool with no output schema, the description covers the basic action. However, the lack of behavioral transparency and usage guidance leaves it incomplete, especially given the potential consequences of installation.
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%, and both parameters have clear descriptions in the schema. The tool description adds 'from CRAN or local path', which reinforces the parameter meaning but does not provide additional details beyond the schema. Baseline 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 explicitly states the verb 'Install' and the resource 'R package', and distinguishes between installation sources 'from CRAN or local path'. This clearly differentiates from sibling tools like r_build_package or r_check_package.
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 does not provide guidance on when to use this tool versus the many siblings (e.g., r_build_package, r_check_package). No context about prerequisites or appropriate scenarios is included, leaving the agent without usage boundaries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all installed R packages
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure. It does not mention side effects (none expected), permissions, or output format. It adds no value beyond the purpose.
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?
Single sentence, no wasted words. Front-loaded with verb and resource. Appropriate for the tool's simplicity.
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 parameterless list tool with no output schema, the description is mostly adequate. However, it does not describe the return value format (e.g., list of names only, or with versions), slightly reducing completeness.
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 no parameters, so schema coverage is 100%. The description adds nothing beyond schema, but baseline for 0 parameters is 4.
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 'List all installed R packages' uses a specific verb and resource, clearly distinguishing it from siblings like r_install_package or r_workspace_ls.
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 such as r_workspace_ls or r_execute. The description provides no context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Load all functions in an R package for interactive development using devtools::load_all()
| Name | Required | Description | Default |
|---|---|---|---|
| package_path | Yes | Path to the R package directory |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must fully disclose behavior. Only states it loads functions, but omits side effects (e.g., overwriting existing objects), dependencies (devtools), and potential errors (package not built). Minimum behavioral info.
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?
Single sentence of 15 words, immediately conveys the tool's action and purpose. No wasted text.
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 simple tool with no output schema and one parameter, the description covers the basic purpose but lacks context on return behavior or differentiation from sibling tools. Adequate but incomplete.
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%—parameter 'package_path' is described as 'Path to the R package directory'. Description adds no extra meaning beyond the schema, hitting the baseline.
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?
Describes loading R package functions using devtools::load_all(), clearly stating the verb ('load'), resource ('all functions in an R package'), and purpose ('interactive development'). Could be more explicit about how it differs from sibling tools like r_install_package.
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?
Implies usage for interactive development, but provides no explicit when-to-use or when-not-to-use guidance. Does not mention alternatives or prerequisites like devtools being installed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run a specific test file using testthat::test_file()
| Name | Required | Description | Default |
|---|---|---|---|
| test_file | Yes | Path to the test file (e.g., tests/testthat/test-myfunction.R) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It only states the function used (testthat::test_file()) without disclosing side effects, output, error behavior, or requirements. This is minimal.
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, front-loading the core purpose immediately.
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 simple tool with one parameter and no output schema, the description is adequate but lacks information about return values, dependencies, or how results are presented.
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% and the parameter has a descriptive schema. The description does not add any additional meaning beyond what the schema provides, so baseline 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 that the tool runs a specific test file using testthat::test_file(). It distinguishes itself from the sibling r_test_package (which runs all tests) implicitly through the name and wording, but does not explicitly contrast them.
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 r_test_package. No mention of prerequisites or context for usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run tests for an R package using devtools::test() or testthat. Great for TDD workflow.
| Name | Required | Description | Default |
|---|---|---|---|
| filter | No | Optional test filter pattern (regex) | |
| package_path | Yes | Path to the R package directory |
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 mentions using devtools::test() or testthat but does not disclose potential side effects, such as whether it installs dependencies or runs in a sandboxed environment. Lacks detail on error behavior or performance implications.
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 plus a tagline, with no wasted words. It is appropriately concise for the tool's simplicity.
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 low complexity (two simple parameters, no output schema), the description is mostly adequate but lacks behavioral transparency and usage guidelines, reducing completeness.
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 does not add any additional meaning beyond what the schema provides for the two 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 it runs tests for an R package using devtools::test() or testthat, and mentions TDD workflow. However, it does not explicitly distinguish itself from the sibling r_test_file tool, which runs tests for a single file.
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 phrase 'Great for TDD workflow' implies when to use it, but there is no explicit guidance on when not to use it or comparison with alternatives like r_test_file.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List objects in the R workspace
| Name | Required | Description | Default |
|---|---|---|---|
| pattern | No | Optional pattern to filter object names |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure. It does not state that the operation is read-only, nor does it mention side effects, permissions, or return format. A simple 'List' implies no modification, but an explicit safety note would improve 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 sentence that directly states the purpose. It is concise and front-loaded. However, it could include slightly more context without becoming verbose, such as clarifying that it lists all objects or that pattern filters names.
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 simple listing tool with one optional parameter and no annotations or output schema, the description is somewhat complete. It lacks details on what 'objects' includes (variables, functions, etc.) and the output format, which an agent might need for proper 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 input schema describes the pattern parameter with a brief description. The tool description adds no additional meaning beyond the schema, so baseline score of 3 is appropriate given 100% schema coverage.
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 'List objects in the R workspace' uses a specific verb 'List' and identifies the resource 'objects in the R workspace'. It clearly distinguishes from sibling tools like r_list_packages (which lists installed packages) and r_execute (which runs arbitrary code).
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 explicit guidance on when to use this tool versus alternatives. The context implies it is for listing workspace objects, but there is no mention of when to prefer it over other R tools. For a simple tool, this is acceptable but not exemplary.
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.1.0jamovi_build_modulejamovi_check_moduler_build_packager_check_packager_document_packager_executer_install_packager_list_packagesr_load_allr_test_filer_test_packager_workspace_lsScored across 12 tools
Each tool targets a distinct action: jamovi_* for module tasks, r_* for R package development and general execution. Even closely related tools like r_test_file and r_test_package are clearly differentiated by their scope.
Most tools follow a prefix_verb_noun pattern (e.g., r_build_package, r_check_package). Minor deviations like 'r_execute' (no noun) and 'r_workspace_ls' (noun_verb) are still clear and do not cause confusion.
With 12 tools, the set covers jamovi module work and comprehensive R package development (build, check, document, install, test, load) without being bloated. Each tool serves a clear purpose.
The R package development tools adequately cover the core lifecycle (build, check, document, test, install), but missing operations like package removal or update are minor gaps. Jamovi tools are limited to build and check, which is acceptable for a niche focus.
The OpenRouter MCP server plugs OpenRouter into the AI tools you already use. Once connected, your assistant can pull live OpenRouter data (models, prices, your credits, rankings, and docs) and send quick test messages, all without leaving your editor.
MCP server to assist with JxBrowser development.
The MCP server for Azure DevOps, bringing the power of Azure DevOps directly to your agents.
A MCP server built for developers enabling Git based project management with project and personal…
