What can you do with this server?

Summary: The R Best Practices MCP Server lets you detect, validate, and scaffold R projects while browsing a curated knowledge base of 70 best practices. * Detect the R workflow type from a directory path (e.g., package, shiny, quarto). * Validate an entire R project against best practices, with optional workflow, severity, category, and max-findings filters. * Validate a single R or Quarto file against best practices, with the same optional filters. * Retrieve detailed information about a specific best practice by ID. * List, search, and filter best practices by workflow, category, severity, tags, enforcement type, or free-text query. * Generate project scaffolds/templates for a specific R workflow with optional project name and author info. * Access the server via MCP tools, REST API, CLI, VS Code extension, or RStudio addin (per README).

Which integrations are available for this server?

Supports blogdown projects built with Hugo, offering detection, validation, and scaffolding for Hugo-based blogs and websites. Provides workflow detection, validation, and template generation for Quarto documents, enabling reproducible analysis and reporting best practices.

How do I use r-coding-mcp?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@r-coding-mcp run R CMD check on my package and summarize the results" 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.

r-coding-mcp

by alexseymer

Overview Schema Source Related Servers Discussions Admin

TypeScript

Local

R Best Practices MCP Server

Build Publish npm Docker Pulls License: MIT Node.js Version

An MCP (Model Context Protocol) server that enforces best practices across all standard R development workflows. Provides workflow detection, project validation, and template generation for R scripts, Quarto documents, Shiny applications, R packages, and more.

Overview

The R Best Practices MCP Server helps developers write better R code by:

Detecting the R workflow type from a directory structure
Validating projects against best practices with detailed findings
Generating scaffold templates for new projects
Providing knowledge base access to 70 best practices (59 checked automatically, 11 guidance-only)

Supported Workflows

Workflow	Description
r-script	Standalone R scripts for data processing and analysis
quarto	Quarto documents for reproducible analysis and reporting
shiny	Interactive web applications using Shiny
package	R packages for code organization and distribution
rmarkdown	R Markdown documents for dynamic reports
renv	Projects using renv for dependency management
targets	Pipeline projects using the targets framework
plumber	REST APIs built with Plumber
analysis	Data analysis projects with standard directory structure
bookdown	Books and theses created with bookdown
blogdown	Blogs and websites created with blogdown and Hugo
shinytest	Shiny apps with automated testing using shinytest

Related MCP server: mcp-github-pm

Features

🔍 Workflow Detection

Automatically detects the R project type with confidence scoring:

Analyzes file patterns and directory structure
Identifies workflow-specific files (DESCRIPTION, app.R, _targets.R, etc.)
Returns confidence percentage (0-100%)
Includes indicators of detected workflow

✓ Project Validation

Comprehensive validation against best practices:

Severity levels: critical, important, recommended, info
Categories: structure, naming, documentation, performance, security, testing
Actionable suggestions for every finding
File-level and project-level validation

🎯 Template Generation

Generate complete project scaffolds:

Realistic file structures for each workflow
Sample code demonstrating best practices
Configuration files (DESCRIPTION, .Rprofile, renv.lock, etc.)
Markdown documentation and setup instructions
Customizable project name and author info

📚 Knowledge Base

Access to 70 best practices:

Organized by workflow type (12 workflows)
Categorized by topic (documentation, testing, security, etc.)
Every practice has details, a "bad" and a "good" example, and references
Automated practices are checked by a validator rule with the same id; guidance practices are advice only and never produce findings
Searchable and filterable by workflow, category, minimum severity, tags, check type and free text

🔐 Security & Rate Limiting

Production-ready security features:

Path traversal protection — Prevents directory traversal attacks
Input sanitization — Removes shell metacharacters and validates paths
Rate limiting — 100 requests per 60 seconds per IP address
Request size limits — 50MB maximum request body
HTTPS/TLS support — Full SSL configuration with reverse proxy
See SECURITY.md for comprehensive security documentation

📊 API Documentation & Versioning

Professional API standards:

OpenAPI 3.0 specification — Access at /openapi.json
Swagger UI — Interactive API explorer at /api-docs
Pagination support — Offset-based pagination with metadata
Dual versioning — /api/ (v0 - backward compatible) and /api/v1/ (current - recommended)
Enhanced rate limit headers — X-RateLimit-* and X-Pagination-* headers
See API_VERSIONING.md for migration guides

Phase 3: Production Hardening (v0.3.0)

This release includes comprehensive security, standards compliance, and deployment improvements:

Phase 3A: Security Hardening

✅ Path traversal protection with canonical path validation
✅ Input sanitization removing shell metacharacters
✅ In-memory rate limiting (100 req/60s per IP)
✅ Request body size limits (50MB default)
✅ Client IP extraction from proxy headers
✅ Comprehensive test coverage (30 tests, 100% coverage)

Phase 3B: API Standards & Versioning

✅ OpenAPI 3.0 specification generation
✅ Swagger UI interactive documentation at /api-docs
✅ Offset-based pagination with metadata
✅ Dual versioning (v0 backward compatible, v1 current)
✅ Rate limit and pagination response headers
✅ 100+ total test cases (61 new tests for Phase 3)

Phase 3C: Documentation

✅ SECURITY.md — Comprehensive security best practices
✅ DEPLOYMENT_CHECKLIST.md — Production deployment guide
✅ API_VERSIONING.md — Versioning strategy and migration guides
✅ Updated README with new features and examples

Installation

Prerequisites

Node.js >= 18.0.0
npm >= 9.0.0

From npm Registry (Recommended)

# Install the published package
npm install r-best-practices-mcp

# Or install globally for CLI usage
npm install -g r-best-practices-mcp

From Source

# Clone the repository
git clone https://github.com/alexseymer/r-best-practice-mcp.git
cd r-best-practice-mcp

# Install dependencies
npm install

# Build TypeScript
npm run build

# Run tests
npm test

Docker Deployment

Run the server in a containerized environment with automatic dependency management:

Using Docker Hub (Recommended)

# Pull the latest image from Docker Hub
docker pull alexseymer/r-best-practices-mcp:latest

# Or use a specific version
docker pull alexseymer/r-best-practices-mcp:1.0.0

# Run the container
docker run -d \
  --name r-practices \
  -p 3000:3000 \
  alexseymer/r-best-practices-mcp:latest

# Verify it's running
curl http://localhost:3000/health

Using GitHub Packages

# Pull from GitHub Container Registry
docker pull ghcr.io/alexseymer/r-best-practices-mcp:latest

# Run the container
docker run -d \
  --name r-practices \
  -p 3000:3000 \
  ghcr.io/alexseymer/r-best-practices-mcp:latest

Using Docker Compose

# Clone and deploy with Docker Compose
git clone https://github.com/alexseymer/r-best-practice-mcp.git
cd r-best-practice-mcp

# Start the API server
docker-compose up -d

# Verify it's running
curl http://localhost:3000/health

Features:

🐳 Container-based deployment for any system
🔄 Auto-restart on failure
📊 Health checks configured
🔒 Security hardened (non-root user)
🌐 Optional Nginx reverse proxy with SSL support
📦 Volumes for mounting R projects

For complete Docker documentation, see DOCKER.md:

Configuration options
SSL/TLS setup
Production deployment
Troubleshooting
Performance tuning
Security best practices

Environment variables

Variable	Default	Purpose
`PORT`	`3000`	Port of the web server.
`NODE_ENV`	unset	`production` confines paths to `/projects` and disables `/metrics*` unless configured.
`ALLOWED_PROJECT_ROOTS`	`/projects` in production	Comma separated directories the web server may analyse.
`ALLOW_ANY_PATH`	`false`	`true` allows any absolute path (never on a public server).
`METRICS_TOKEN`	unset	Bearer token required for `/metrics*`.
`METRICS_PUBLIC`	`false`	`true` serves `/metrics*` without credentials (default outside production).
`TRUST_PROXY`	unset (trust nothing)	Reverse proxy hops whose `X-Forwarded-*` headers are trusted: a number (`1`) or an Express value (`loopback`). Needed behind a proxy for per-client rate limits and HSTS.
`MAX_BODY_BYTES`	`1048576`	Maximum JSON/form request body.
`GIT_SHA`, `BUILD_TIME`	unset	Build information returned by `/health` and `/api/config` (Docker build args of the same name).

LOG_LEVEL appears in docker-compose.yml but is not read by the server.

Verifying a deployment

curl -s https://your-host/health        # status, version, build.commit, build.builtAt
curl -s https://your-host/api/config    # active path roots, metrics mode, upload limits
curl -sI https://your-host/dashboard    # security headers (CSP, X-Frame-Options, HSTS over HTTPS)

Usage

Via MCP Server (Claude & other clients)

The server exposes 6 tools via the Model Context Protocol:

1. `detect_workflow` — Identify project type

// Input
{ "path": "/path/to/project" }

// Output
{
  "workflow": "package",
  "confidence": 95,
  "indicators": ["DESCRIPTION", "R/", "tests/testthat/"]
}

2. `validate_project` — Check best practices

// Input (everything except `path` is optional)
{
  "path": "/path/to/project",
  "workflow": "package",
  "minSeverity": "important",        // critical | important | recommended | info (at least this severe)
  "categories": ["testing", "documentation"],
  "maxFindings": 50                  // integer 1-1000
}

// Output
{
  "workflow": "package",
  "findings": [
    {
      "id": "pkg-tests",
      "severity": "important",
      "category": "testing",
      "message": "Add tests/ directory with testthat tests"
    }
  ],
  "summary": {                       // counted BEFORE the filters above
    "total": 7,
    "bySeverity": { "critical": 1, "important": 2, "recommended": 4, "info": 0 },
    "byCategory": { "testing": 1, "documentation": 3, "structure": 3 }
  },
  "duration": 45
}

validate_file accepts the same three filters and returns the same summary. Invalid filter values are rejected with an INVALID_PARAMETER error (HTTP 400 on the REST API). Every finding id is a practice id (see get_practice).

3. `validate_file` — Check single file

// Input
{ "path": "/path/to/file.R" }

// Output
{
  "path": "/path/to/file.R",
  "findings": [...]
}

4. `generate_template` — Create scaffolds

// Input
{
  "workflow": "shiny",
  "projectName": "my-dashboard",
  "authorName": "John Doe"
}

// Output
{
  "workflow": "shiny",
  "files": [
    { "path": "app.R", "content": "..." },
    { "path": "README.md", "content": "..." }
  ],
  "directories": [...]
}

5. `get_practice` — Details about a practice

// Input
{ "id": "pkg-roxygen" }

// Output
{
  "id": "pkg-roxygen",
  "title": "Use roxygen2 for documentation",
  "workflow": "package",
  "category": "documentation",
  "description": "...",
  "examples": [...]
}

6. `list_practices` — Browse best practices

// Input (all optional)
{
  "workflow": "package",
  "category": "documentation",
  "minSeverity": "important",        // at least this severe
  "tags": ["roxygen"],               // practice has any of these tags
  "enforcement": "automated",        // automated | guidance
  "query": "namespace",              // case-insensitive text search (id, title, description, details, tags)
  "limit": 20                        // integer 1-200
}

// Output
{
  "practices": [...],
  "total": 3
}

The REST API accepts the same filters as query parameters on GET /api/practices and GET /api/v1/practices: workflow, category, minSeverity, tags (comma separated), enforcement, q (alias query), limit.

Via REST API (HTTP)

When running with Docker or the web server, access the same functionality via HTTP:

Recommended: v1 Endpoints (with pagination & enhanced features)

# Check server health
curl http://localhost:3000/health

# Detect workflow (v1)
curl -X POST http://localhost:3000/api/v1/detect-workflow \
  -H "Content-Type: application/json" \
  -d '{"path": "/path/to/project"}'

# Validate project (v1)
curl -X POST http://localhost:3000/api/v1/validate-project \
  -H "Content-Type: application/json" \
  -d '{"path": "/path/to/project", "workflow": "package"}'

# List practices with pagination and filters (v1)
curl "http://localhost:3000/api/v1/practices?limit=50&offset=0&workflow=package&minSeverity=important&enforcement=automated"

# Validate with filters (v1)
curl -X POST http://localhost:3000/api/v1/validate-project \
  -H "Content-Type: application/json" \
  -d '{"path": "/path/to/project", "minSeverity": "important", "maxFindings": 20}'

# Get practice details (v1)
curl http://localhost:3000/api/v1/practice/pkg-roxygen

# Generate template (v1)
curl -X POST http://localhost:3000/api/v1/generate-template \
  -H "Content-Type: application/json" \
  -d '{"workflow": "package", "projectName": "mypackage"}'

Upload a project (REST only)

POST /api/validate-upload validates a project posted from a browser (the server never sees a path). It is REST only, not an MCP tool, and is also listed in /openapi.json. The files are written to a private temporary directory, analysed and deleted immediately; nothing is stored.

curl -X POST http://localhost:3000/api/validate-upload \
  -H "Content-Type: application/json" \
  -d '{"files": [{"path": "DESCRIPTION", "content": "Package: demo\n"}, {"path": "R/a.R", "content": "a <- 1\n"}], "minSeverity": "important"}'

Uploaded files are written to a private temporary directory under UPLOAD_TMP_DIR (default: the system temp directory) and deleted as soon as the request finishes; point it at a tmpfs or a dedicated volume if you want uploads kept off the main disk.

Body: files ([{ path, content }], paths relative to the project root, / or \ separators) and optional workflow (detected when omitted), minSeverity, categories, maxFindings (same as validate-project), detectOnly (return only detected and upload, no findings).
Response data: the validate-project fields (filePath is the label uploaded project, finding file values are relative) plus detected (workflow, confidence, indicators) and upload (files, bytes, skipped).
Limits (also in GET /api/config under upload): 500 files, 1 MB per file, 5 MB in total, 260 characters per path, 20 levels deep; the JSON body may be 8 MB. Only text project files are accepted (.R .Rmd .qmd .md .yml .yaml .toml .json .lock .txt .dcf ... and files such as DESCRIPTION, NAMESPACE, .Rprofile); other files are skipped and counted in upload.skipped.
Errors: 400 INVALID_PARAMETER (not an array, empty, absolute path, ./../empty segment, control characters, duplicate path, wrong types, no supported files), 400 INVALID_WORKFLOW, 413 PAYLOAD_TOO_LARGE (file/total/count/body limits), 503 BUSY with Retry-After (at most 2 uploads are analysed at the same time).

API Documentation

# View OpenAPI 3.0 specification
curl http://localhost:3000/openapi.json

# Access interactive Swagger UI
open http://localhost:3000/api-docs

# Check rate limit metrics
curl http://localhost:3000/metrics/rate-limit

Legacy: v0 Endpoints (backward compatible)

v0 endpoints are still available for backward compatibility (no pagination, legacy format):

# v0 endpoints (deprecated for new code)
curl http://localhost:3000/api/detect-workflow
curl http://localhost:3000/api/practices
curl http://localhost:3000/api/practice/practice-id

See API_VERSIONING.md for migration guides from v0 to v1.

Docker Hub: Pull pre-built images from Docker Hub

See DOCKER.md for complete API documentation, including:

Request/response schemas
Query parameters and pagination
Rate limiting configuration
Error handling
Security configuration

Project Structure

r-best-practice-mcp/
├── src/
│   ├── engine/
│   │   ├── detector.ts            # Workflow detection (208 lines)
│   │   ├── validator.ts           # Project validation (503 lines)
│   │   └── template-generator.ts  # Template generation (833 lines)
│   ├── data/
│   │   └── knowledge-base.ts      # Loads the 70 practices from data/practices/
│   ├── analysis/                  # Phase 6: Advanced features
│   │   ├── complexity.ts          # Complexity analysis
│   │   ├── dependencies.ts        # Dependency tracking
│   │   ├── performance.ts         # Performance profiling
│   │   ├── auto-fixes.ts          # Automated fixes
│   │   └── index.ts               # Exports
│   ├── cli/                       # Phase 4: CLI interface
│   │   ├── index.ts               # Command setup
│   │   └── commands/
│   │       ├── detect.ts          # Detect workflow
│   │       ├── validate.ts        # Validate project
│   │       ├── template.ts        # Generate template
│   │       └── report.ts          # Generate report
│   ├── config/
│   │   └── rules-engine.ts        # Custom validation rules
│   ├── types/
│   │   ├── workflow.ts, finding.ts, practice.ts, etc.
│   ├── utils/
│   │   ├── file.ts, logger.ts
│   │   ├── security.ts            # Path validation, input sanitization (Phase 3A)
│   │   ├── rate-limiter.ts        # Rate limiting middleware (Phase 3A)
│   │   ├── pagination.ts          # Pagination utilities (Phase 3B)
│   │   └── openapi.ts             # OpenAPI spec generation (Phase 3B)
│   ├── server.ts                  # MCP server (358 lines)
│   ├── web-server.ts              # Express web server with security (Phase 3A/3B)
│   └── index.ts
├── vscode-extension/              # Phase 5: VS Code integration
│   ├── package.json
│   ├── src/
│   │   ├── extension.ts           # Main extension
│   │   ├── client.ts              # MCP communication
│   │   ├── diagnostics.ts         # VS Code diagnostics
│   │   └── commands.ts            # Command handlers
├── rstudio-addin/                 # Phase 7: RStudio integration
│   ├── DESCRIPTION, NAMESPACE
│   ├── R/
│   │   ├── addins.R               # 4 addin functions (337 lines)
│   │   └── utils.R                # MCP utilities (300+ lines)
│   ├── inst/rstudio/
│   │   └── addins.dcf             # RStudio registration
│   └── tests/
├── tests/
│   ├── unit/                      # Unit tests (100+ tests)
│   │   ├── detector.test.ts
│   │   ├── validator.test.ts
│   │   ├── template-generator.test.ts
│   │   ├── knowledge-base.test.ts
│   │   ├── security.test.ts       # Phase 3A: 30 tests
│   │   ├── rate-limiter.test.ts   # Phase 3A: 10 tests
│   │   └── pagination.test.ts     # Phase 3B: 21 tests
│   └── fixtures/
├── dist/, jest.config.js, tsconfig.json, package.json
├── CLAUDE.md                      # Architecture & development guide
├── SECURITY.md                    # Security best practices (Phase 3C)
├── DEPLOYMENT_CHECKLIST.md        # Production deployment guide (Phase 3C)
├── API_VERSIONING.md              # API versioning strategy (Phase 3C)
├── DOCKER.md                      # Docker deployment guide
├── CONTRIBUTING.md
└── README.md

CI/CD Pipeline

This project uses GitHub Actions for automated testing, building, and releasing:

Build Workflow — Runs on every push and PR
- ESLint linting
- TypeScript building
- Jest unit tests with coverage
- Type checking
- Matrix testing on Node 18.x and 20.x
Publish Workflow — Triggered by version tags (v*..)
- Runs full test suite
- Publishes to npm registry
- Builds and pushes Docker images to:
  - Docker Hub (alexseymer/r-best-practices-mcp)
  - GitHub Packages (ghcr.io/alexseymer/r-best-practices-mcp)
- Creates GitHub Release with installation instructions
- Uses semantic versioning for tags

Publishing is fully automated via GitHub Actions:

Push a version tag: git tag v1.0.0 && git push origin v1.0.0
The workflow automatically publishes to npm and Docker registries
GitHub Release is created with release notes

For detailed publishing instructions, see PUBLISH.md and docs/versioning.md.

Development

Scripts

# Build TypeScript
npm run build

# Run all tests with coverage
npm test

# Watch mode for development
npm run test:watch

# Run specific test suite
npm test -- detector.test.ts

# Linting
npm run lint

# Code formatting
npm run format

Testing

Comprehensive test coverage (91 tests):

✓ Workflow detection for all 9 types
✓ Project validation across workflows
✓ Template generation and content
✓ Knowledge base functionality
✓ File system utilities

Best Practices Coverage

The knowledge base includes 70 best practices. 59 are automated (a validator rule reports violations); 11 are guidance only (they need R to run, runtime behaviour or judgement, so they never produce findings):

R Scripts (7) — Headers, functions, naming, sections, error handling, cleanup
Quarto (7) — Chunk labels and options, YAML, caching, figures, tables, narrative
R Markdown (4) — YAML, chunks, options, inline code
Shiny (8) — Structure, separation, modules, validation, reactivity, feedback
Packages (10) — roxygen2, NAMESPACE, DESCRIPTION, tests, vignettes, license, check, coverage
renv (4) — Init, lock, snapshot, restore
targets (4) — Structure, naming, dependencies, branching
Plumber (6) — Paths, docs, validation, responses, status codes, errors
Analysis (3) — Directory structure, README, version control
bookdown (6) — Config, index, chapter naming, output formats, cross-references, README
blogdown (5) — Config, content structure, themes, front matter, deployment
shinytest (6) — Test structure, app, setup, recordings, unit tests, CI

Browse them in the dashboard (Practices tab), via list_practices, or GET /api/practices.

Examples

Validate an R Package

# Using the MCP server
mcp_tool_call "validate_project" '{"path": "/path/to/mypackage"}'

# Response includes:
# - Missing DESCRIPTION file (critical)
# - No tests/ directory (important)
# - Missing LICENSE (critical)
# - No README.md (recommended)

Generate a Shiny Template

# Using the MCP server
mcp_tool_call "generate_template" '{
  "workflow": "shiny",
  "projectName": "my-app",
  "authorName": "Jane Doe"
}'

# Returns scaffold with:
# - app.R with UI/server structure
# - README.md with setup instructions
# - .gitignore configured

Detect Project Type

# Using the MCP server
mcp_tool_call "detect_workflow" '{"path": "/path/to/project"}'

# Automatically identifies:
# - Workflow type with confidence
# - Detected indicators
# - Timestamp

Performance

Detection: ~50-100ms per project
Validation: ~100-500ms depending on project size
Template Generation: <10ms
Knowledge base queries: <5ms

Dependencies

Runtime

@modelcontextprotocol/sdk — MCP protocol

Development

typescript — Type safety
jest — Testing framework
ts-jest — TypeScript support
@types/jest — Jest types
@types/node — Node.js types

Contributing

Fork the repository
Create a feature branch
Make your changes
Run tests: npm test
Submit a pull request

Interfaces Available

🌐 REST API (HTTP)

Deploy as a web service with Docker for easy integration:

Express.js HTTP server on port 3000
All 6 tools available via REST endpoints
Health checks and API introspection
Optional Nginx reverse proxy with SSL/TLS
Perfect for self-hosted VPS deployment
Start with docker-compose up or node dist/web-server-entry.js
See Docker documentation

🖥️ MCP Server

The core MCP server exposing 6 tools for Claude and other MCP clients. Start with node dist/index.js.

💻 CLI Tool (Phase 4)

Local command-line tool for developers:

detect — Identify project workflow type
validate — Check projects against best practices
template — Generate project scaffolds
report — Create HTML validation reports
--watch mode for continuous monitoring

📌 VS Code Extension (Phase 5)

Real-time validation within VS Code:

Inline diagnostics with severity coloring
Quick fix suggestions
Workflow detection
HTML report generation in WebView
Keyboard shortcut: Shift+Alt+V

🎨 RStudio Addin (Phase 7)

In-IDE validation for RStudio:

Validate Project gadget with findings table
Detect Workflow dialog
Generate Template interactive UI
Show Report with statistics
Access via RStudio Addins menu

Advanced Features (Phase 6)

Complexity Analysis — Cyclomatic complexity, nesting depth, LOC metrics
Dependency Tracking — renv.lock, DESCRIPTION, library() analysis
Performance Profiling — Operation timing and optimization suggestions
Automated Fixes — roxygen2, imports, formatting, style fixes
Custom Rules — Pattern-based validation rules

Roadmap (Future Phases)

Publish VS Code extension to marketplace
Publish CLI tool to npm registry
Publish RStudio addin to CRAN
Web dashboard
Additional workflows (bookdown, blogdown)
Community rule library

License

MIT License

Documentation

CLAUDE.md — Architecture, design decisions, development workflow
SECURITY.md — Security best practices, configuration, hardening
DEPLOYMENT_CHECKLIST.md — Production deployment guide with Docker & K8s
API_VERSIONING.md — API versioning strategy and migration guides
DOCKER.md — Docker deployment, SSL/TLS, production configuration
CONTRIBUTING.md — Contributing guidelines

Support

Issues: GitHub Issues
Questions: GitHub Discussions
Security: Email alexseymer@gmail.com with security concerns
Publishing: PUBLISH.md
Versioning: docs/versioning.md

Available Tools

6 tools

detect_workflowC

Detect the R workflow type from a directory path

ParametersJSON Schema

Name	Required	Description	Default
`path`	Yes	Directory path to analyze

TDQS

C2.9/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full behavioral burden. 'Detect' implies a read-only inspection, but the description never says what happens with a non-R directory, what workflow types can be returned, or whether detection can fail — leaving real gaps for an unannotated tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

A single tight sentence with the purpose front-loaded and zero filler. It is efficient, though it is so terse that it borders on under-specification rather than deliberate brevity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple one-parameter read tool this is minimally viable, but with no output schema the description should have described the possible return values (the workflow types) and behavior on unrecognized directories. As written, an agent knows what it does but not what it gets back.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% and there is only one parameter, so the schema already documents 'path' fully. The description's 'from a directory path' adds no meaning beyond the schema's 'Directory path to analyze', so the baseline of 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb ('Detect'), a specific resource ('the R workflow type'), and the input domain ('from a directory path'). It is clearly distinguishable from siblings like validate_file, validate_project, or generate_template, though it never explicitly names those alternatives.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no statement of when to use this tool versus the validation siblings, no prerequisites, and no exclusions. The only implied guidance is that a directory path is needed, which the schema already supplies.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

generate_templateC

Generate a project template for a specific R workflow

ParametersJSON Schema

Name	Required	Description
`workflow`	Yes	Workflow type (r-script, quarto, shiny, package, rmarkdown, renv, targets, plumber, analysis)
`authorName`	No	Optional author name
`authorEmail`	No	Optional author email
`projectName`	No	Optional name for the project

TDQS

C2.9/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It does not state that this creates files, where they are written, whether existing files are overwritten, or what permissions are needed—details critical for a generation tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

A single front-loaded sentence with zero waste. Every word earns its place, and the purpose is immediately clear.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool performs a creation action but has no annotations and no output schema, so the description should explain return values and side effects. It omits any such context, leaving the agent uninformed about outcomes or file system impact.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents all four parameters thoroughly, including the workflow options. The description adds no parameter meaning beyond what the schema provides, fitting the baseline of 3.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (generate) and resource (project template) scoped to a specific R workflow. Clear on its own, but does not distinguish itself from siblings like detect_workflow or validate_project, so it misses the top score for sibling differentiation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The single sentence only states what the tool does. There is no guidance on when to choose it over alternatives such as detect_workflow or validate_project, nor any prerequisites or exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_practiceC

Get details about a specific best practice

ParametersJSON Schema

Name	Required	Description	Default
`id`	Yes	Practice ID

TDQS

C2.9/5.0

Behavior2/5

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 doesn't state whether the practice could be missing (error behavior), whether the ID format matters, or what fields are returned. For a read tool with no annotations, this is thin.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

One short sentence, front-loaded and free of filler. Appropriately sized for a single-parameter lookup.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No annotations, no output schema, and no return-value explanation. An agent cannot tell what 'details' includes, how to handle a missing ID, or how it relates to list_practices. The description is underspecified for correct invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and the single 'id' parameter is documented as 'Practice ID' in the schema. The description adds no format or source hints beyond the schema, so baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (get) and resource (best practice) with detail scoping ('details about a specific'). However, it doesn't differentiate from siblings like list_practices, which a reader must infer from the singular 'specific best practice' phrasing alone.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this versus list_practices, nor any prerequisites or exclusions. The singular/plural distinction is left entirely to inference.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_practicesC

List best practices, optionally filtered by workflow, category, minimum severity, tags, enforcement type (automated check or guidance only) or free-text query

ParametersJSON Schema

Name	Required	Description
`tags`	No	Only practices having at least one of these tags (REST: comma separated list)
`limit`	No	Maximum number of practices to return (1-200). On /api/v1 this is the page size, capped at 100.
`query`	No	Case-insensitive text search over id, title, description, details and tags (REST alias: q)
`category`	No	Optional category (structure, naming, documentation, etc.)
`workflow`	No	Optional workflow type (r-script, quarto, shiny, package, etc.)
`enforcement`	No	'automated' = a validator rule reports violations; 'guidance' = advice only
`minSeverity`	No	Only practices at least this severe (critical > important > recommended > info)

TDQS

C2.9/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full behavioral burden. It does not state that this is a safe read-only operation, how results are ordered, how pagination beyond the limit works, or what the response contains for a 7-parameter tool. The only behavioral clue, the parenthetical clarifying enforcement semantics, describes a parameter rather than tool behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

A single front-loaded sentence that enumerates the filter dimensions with no filler. It is efficient, though the parenthetical 'automated check or guidance only' is slightly redundant against the schema enum.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 7-parameter list tool with no output schema and no annotations, the description covers the filter surface but omits retrieval behavior, ordering, and return shape. It is minimally adequate for an agent to pick the tool but not complete enough to predict results.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents every parameter including enum meanings and tag combination logic, making 3 the baseline. The description merely restates the available filters without adding format, matching, or combination semantics beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (List) and resource (best practices) with the full set of filtering dimensions. It is clearly distinguished from the singular get_practice sibling, though the relationship is implied rather than named.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The word 'optionally' signals that all filters are optional, but there is no explicit when-to-use guidance, no statement of what this offers over get_practice or detect_workflow, and no exclusions. Usage must be inferred.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

validate_fileA

Validate a single R or Quarto file. Optional filters narrow the returned findings; the summary always counts all findings.

ParametersJSON Schema

Name	Required	Description
`path`	Yes	File path to validate
`categories`	No	Only return findings in these categories (omit for all categories)
`maxFindings`	No	Return at most this many findings after other filters (1-1000). The summary still counts all findings.
`minSeverity`	No	Only return findings at least this severe (critical > important > recommended > info)

TDQS

A3.6/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full behavioral burden. It usefully discloses the filter/summary interaction ('filters narrow the returned findings; the summary always counts all findings'), but this is also stated in the maxFindings schema description, and nothing is said about read-only nature, permissions, or error behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two tight sentences, no waste, and the core action is front-loaded before the filtering caveat. Every clause earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a read-style validation tool with no output schema and no annotations, the description covers the action and the one non-obvious output behavior (summary counts are unaffected by filters). It does not sketch the shape of a finding or severity semantics, but the schema covers severity levels and the gap is minor.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents path, categories, maxFindings and minSeverity including their defaults and bounds. The description's generic 'optional filters' adds no syntax or format detail beyond that, which is the expected baseline when the schema does the heavy lifting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Validate a single R or Quarto file') and the scope word 'single' implicitly separates it from the sibling validate_project. It stops short of naming that sibling explicitly, so the differentiation is inferred rather than stated.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is only implied: the 'single file' framing suggests when this applies versus project-level validation, but there is no explicit when-to-use, when-not-to-use, or alternative named. Adequate but leaves the routing decision to inference.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

validate_projectA

Validate an R project against best practices. Optional filters narrow the returned findings; the summary always counts all findings. If no project type is detected the result has no findings and a warnings array: that means no checks ran, not that the project is clean.

ParametersJSON Schema

Name	Required	Description
`path`	Yes	Directory path to validate
`workflow`	No	Optional workflow type (auto-detected if omitted)
`categories`	No	Only return findings in these categories (omit for all categories)
`maxFindings`	No	Return at most this many findings after other filters (1-1000). The summary still counts all findings.
`minSeverity`	No	Only return findings at least this severe (critical > important > recommended > info)

TDQS

A3.7/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full behavioral burden, and it does meaningful work: it warns that filtered findings do not change the summary counts, and that a missing project-type detection yields empty findings plus a warnings array — i.e. no checks ran rather than a clean bill of health. That non-obvious disclosure prevents a serious misread; it stops short of describing severity semantics or output shape in depth.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences, front-loaded with the core purpose and then the two highest-value caveats. The final sentence is long but earns its length by preventing the 'no findings = clean' misinterpretation.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema exists, so the description must hint at returns, and it does (findings, summary, warnings array). For a read-only validation tool with fully documented parameters, this is close to complete; only severity semantics and the findings record shape are left unstated.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3. The description reinforces that filters (categories, minSeverity, maxFindings) narrow returned findings while the summary still totals everything, but this largely restates what the maxFindings schema already says, adding little beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a clear verb+resource: 'Validate an R project against best practices.' Scope ('project', not file) implicitly distinguishes it from the sibling validate_file, though it never names that sibling explicitly.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied rather than stated: the description covers how filters behave and one edge case, but gives no guidance on when to reach for this tool versus validate_file or detect_workflow. An agent must infer the selection criteria.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

6 tool updatesv1.0.0Oct 5, 2026
- First observeddetect_workflow
- First observedgenerate_template
- First observedget_practice
- First observedlist_practices
- First observedvalidate_file
- First observedvalidate_project

Deploy Server

Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.comAd

TDQS

A3.6/5.0

Scored 2026-10-05 14:50 across 6 tools

Disambiguation5/5

Each tool has a clearly distinct target: detect_workflow (identify type), validate_file vs validate_project (different scopes of validation), get_practice vs list_practices (single vs collection), and generate_template. No two tools could reasonably be confused for one another.

Naming Consistency5/5

All six tools follow a consistent verb_noun snake_case convention (detect_workflow, validate_file, validate_project, get_practice, list_practices, generate_template). The pattern is predictable throughout with no deviations.

Tool Count5/5

Six tools is well-scoped for an R best-practices/validation server, with no redundancy. Each tool covers a distinct capability (detection, validation, practice lookup, template generation).

Completeness4/5

The surface covers the core lifecycle: detection, validation at file and project level, practice discovery, and template generation. Some gaps remain, such as auto-fix/remediation of findings, but the essential workflows are covered.

Maintenance

ActivityMaintained

ResponsivenessUnresponsive

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

AgentSEO C
dev.agentseo.www
Live SEO workflow tools for Claude Code, Codex, and AI agents.
Marketing Browser Automation
454
validatethat-mcp
io.github.RyanByrne
Run UX research from Claude — create card sort studies, list studies, pull headline stats.
Research & Data Product Management
2
mcp A
ai.promptarch
Research-backed lint + generation for agent context files (CLAUDE.md, AGENTS.md) + prompt enhancer.
Agent Orchestration Developer Tools
42
opchain A
io.github.asfbay-bit
Claude Code / MCP skills for the dev pipeline: discover, spec, design, build, ship, operate.
Developer Tools CI/CD & DevOps Project Management
2

Related MCP Servers

Claude Code Starter Kit MCP
Testing & QA Tools Code Analysis Penetration Testing
dachivadachkoria
A
license
C
quality
C
maintenance
Enables AI-powered automated testing, security scanning, code review, and maintenance tasks directly within Claude Code or desktop.
Updated 7 months ago (2026-03-08 21:09 UTC)
12
4
MIT
mcp-github-pm
Version Control Project Management
lordbasilaiassistant-sudo
A
license
B
quality
D
maintenance
Enables GitHub project management from Claude, supporting issue creation, milestones, labels, changelog generation, and repository stats.
Updated 7 months ago (2026-03-07 14:58 UTC)
8
5 npm
1
MIT
GitHub Context MCP Server
Version Control Developer Tools
Haavi97
F
license
A
quality
D
maintenance
Enables Claude to access and manage GitHub repositories dynamically at runtime, including private repos, with tools for browsing files, searching code, and viewing commits, pull requests, and issues.
Updated 7 months ago (2026-03-30 11:13 UTC)
11
1
-
github-analyzer-mcp
Version Control Code Analysis
MidhunaMohanraj
A
license
Not graded
quality
D
maintenance
Enables Claude to analyze GitHub repositories with tools for health scoring, contributor analysis, issue tracking, code search, and more.
Updated 7 months ago (2026-03-27 19:55 UTC)
MIT

R Best Practices MCP Server

Overview

Supported Workflows

Features

🔍 Workflow Detection

✓ Project Validation

🎯 Template Generation

📚 Knowledge Base

🔐 Security & Rate Limiting

📊 API Documentation & Versioning

Phase 3: Production Hardening (v0.3.0)

Phase 3A: Security Hardening

Phase 3B: API Standards & Versioning

Phase 3C: Documentation

Installation

Prerequisites

From npm Registry (Recommended)

From Source

Docker Deployment

Using Docker Hub (Recommended)

Using GitHub Packages

Using Docker Compose

Environment variables

Verifying a deployment

Usage

Via MCP Server (Claude & other clients)

1. detect_workflow — Identify project type

2. validate_project — Check best practices

3. validate_file — Check single file

4. generate_template — Create scaffolds

5. get_practice — Details about a practice

6. list_practices — Browse best practices

Via REST API (HTTP)

Recommended: v1 Endpoints (with pagination & enhanced features)

Upload a project (REST only)

API Documentation

Legacy: v0 Endpoints (backward compatible)

Project Structure

CI/CD Pipeline

Development

Scripts

Testing

Best Practices Coverage

Examples

Validate an R Package

Generate a Shiny Template

Detect Project Type

Performance

Dependencies

Runtime

Development

Contributing

Interfaces Available

🌐 REST API (HTTP)

🖥️ MCP Server

💻 CLI Tool (Phase 4)

📌 VS Code Extension (Phase 5)

🎨 RStudio Addin (Phase 7)

Advanced Features (Phase 6)

Roadmap (Future Phases)

License

Documentation

Support

Available Tools

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

1. `detect_workflow` — Identify project type

2. `validate_project` — Check best practices

3. `validate_file` — Check single file

4. `generate_template` — Create scaffolds

5. `get_practice` — Details about a practice

6. `list_practices` — Browse best practices