Production Environment

MCP Server Documentation

Integrate RuleMesh's technical compliance engine directly into your AI development environment. Programmatic GDPR enforcement, automated evidence collection, and real-time risk signal scanning.

Quick Start

terminal Claude Code

OAuth (recommended)

claude mcp add rulemesh https://api.rulemesh.com/mcp

API Key

claude mcp add --transport http rulemesh https://api.rulemesh.com/mcp --header "X-Api-Key: rm_YOUR_KEY"

settings_input_component JSON Configuration

Cursor / VS Code

{
  "mcpServers": {
    "rulemesh": {
      "transport": "http",
      "url": "https://api.rulemesh.com/mcp"
    }
  }
}

URL	https://api.rulemesh.com/mcp
Transport	Streamable HTTP
Auth header	X-Api-Key: rm_...
Protocol	MCP (JSON-RPC over SSE)

Prerequisites

check_circle
RuleMesh account with an organization
Sign up and create or join an organization to access compliance features.
check_circle
API key (starts with rm_)
Generate at Settings → API Keys.
check_circle
MCP-compatible client
Claude Code, Cursor, Windsurf, or VS Code Copilot with MCP enabled.
check_circle
Network Access
Outbound HTTPS access to api.rulemesh.com on port 443.

Configuration

The RuleMesh MCP server uses environment-specific variables to tailor compliance scanning and evidence collection to your specific jurisdiction and data sensitivity levels.

RM_REGION

Compliance Region

Defaults to EU-West-1 (GDPR Primary). Set to US-East-1 for CCPA/CPRA focus.

RM_STRICT_MODE

Enforcement Level

Boolean. If true, non-compliant data structures will throw blocking implementation errors.

RM_EVIDENCE_RETENTION

Artifact Storage

Integer (Days). Duration that captured evidence signals are cached for audit logs.

Implementation Workflow

get_compliance_plan→get_bundle_tasks→implement→report_evidence→get_progress

chatExample Conversation

You: "What's my GDPR compliance plan?"

Agent: [calls get_compliance_plan] → shows 15 bundles in 2 phases

You: "Start with the encryption bundle"

Agent: [calls get_bundle_tasks] → gets 5 tasks with checklists

Agent: [implements each task, calls report_evidence after each]

You: "What's my progress?"

Agent: [calls get_progress] → shows overall score, recent evidence

`get_compliance_plan`

Returns a prioritised list of IT Requirement Bundles. Each bundle is a domain of compliance work (e.g., encryption, access control, data retention). Filter by regulation, cloud platform, or risk level.

`get_bundle_tasks`

Returns actionable implementation tasks for a specific bundle. Each task includes a compliance checklist (acceptance criteria), scope hints (which architectural layers and cloud services to implement in), an evidence template, and done criteria.

If your organization's environment is configured, tasks are tailored to your cloud platform, application type, and data sensitivity level.

Implement

The agent writes code, configuration, and tests based on the task requirements. This step happens in your codebase — the MCP server provides the guidance, the agent does the work.

`report_evidence`

Records what was implemented. Evidence is stored against the bundle and, when a Jira ticket exists, automatically forwarded to the Jira issue. See the evidence signals section below for detail.

`get_progress`

Cross-session compliance dashboard. Returns overall compliance score, status breakdown by bundle, high-risk items remaining, recent evidence, and recommendations for what to work on next.

Guided prompts

MCP Prompts orchestrate multiple tools into a single workflow. They require client support for prompts/get (Claude Code supports this; Cursor and some VS Code extensions do not).

Prompt	Purpose
implement_bundle	Full implementation workflow — fetches tasks, implements each, reports evidence
review_bundle	Read-only review of a bundle's status, tasks, evidence, and gaps
plan_compliance	Generate a prioritised compliance roadmap (planning only, no implementation)

Evidence Signals

What evidence signals are

Evidence signals are structured records of compliance implementation. When your agent implements a control — writing encryption configuration, adding access control logic, configuring retention policies — it reports what was done as an evidence signal.

Each signal captures the bundle it belongs to, the type of evidence (code, configuration, test, documentation, or manual), a short label describing the control, and a description of what was implemented. Optionally, it includes the source file and a confidence score.

Evidence signals create a traceable chain from regulatory requirement to implementation. They serve three audiences: internal governance teams verifying controls are active, external auditors requiring proof of technical implementation, and enterprise customers conducting security reviews.

How evidence reporting works

Task includes an evidence template

When you call get_bundle_tasks, each task returns an evidence_template with pre-filled parameters — the bundle identifier and requirement ID are already set. The agent just needs to fill in what it implemented.

Agent reports after implementing

After implementing a control, the agent calls report_evidence with the filled template. The signal is stored against the bundle and requirement.

Evidence forwards to Jira

When a Jira ticket exists for the bundle, evidence is automatically forwarded: the signal is added to the Jira issue and the progress panel is updated. Forwarding is non-fatal — evidence is always stored regardless of Jira availability.

Signal Type	Definition	Compliance Value
history_eduConsent Log	Timestamped record of user agreement to data processing terms.	Article 7 Proof
enhanced_encryptionAccess Audit	Verification of who accessed sensitive PII and the authorization scope used.	Article 32 Logs
data_thresholdingDeletion Trace	Cryptographic proof of data erasure following a 'Right to be Forgotten' request.	Article 17 Receipt
monitoringTransfer Proof	Network trace documenting the geo-location of data at rest and in transit.	Article 44 Validation

Evidence types

Type	When to use
code	Wrote or modified source code implementing a control
config	Modified infrastructure configuration (Terraform, YAML, environment variables)
test	Wrote or ran tests validating compliance controls
documentation	Created compliance documentation or policies
manual	Identified something requiring human action

codeEvidence Template Example

Each task in get_bundle_tasks includes a pre-filled template. After implementing, the agent fills in signal and description and passes it to report_evidence.

{
  "anchor_hash": "abc123",
  "requirement_id": "itreq-gdpr-art-32-para-1-req-1",
  "evidence_type": "code",
  "signal": "encryption-at-rest",
  "description": "Configured S3 SSE with KMS key rotation"
}

Sensitivity Scaling

The amount of evidence required per task depends on your organization's data sensitivity level, configured during Jira onboarding. RuleMesh uses a dynamic sensitivity algorithm to adjust scanning intensity based on the data volume and classification.

At high sensitivity, risk levels are amplified — low-risk requirements become moderate, moderate become high — and evidence must include both code and tests.

Basic PII

Min 1 signal

Sensitive

Min 2, code req

Critical

Min 3, code+test

speed

Auto-Scaling

Enabled

Sensitivity	Depth	Min evidence	Required types
Basic	Minimum viable	1	—
Moderate	Robust	2	code
High	Defense in depth	3	code, test

Compliance Scanning

shield_lock

The scan_compliance tool evaluates your existing implementations against GDPR requirements. Your agent describes what it observes in the codebase — encryption configuration, logging setup, access control policies — and the MCP server evaluates those observations against the structured requirement model.

Each finding is scored as satisfied, partial, or gap, with an overall compliance score for the scoped requirements.

verified_userPolicy Matching

analyticsRisk Scoring

account_treeFlow Validation

gavelLegal Context

scan_compliance parameters

Parameter	Required	Description
regulation	Yes	Regulation name (e.g. "GDPR")
context	Yes	Description of what's implemented (the agent provides this)
platform	No	Cloud platform filter (AWS, Azure, GCP)
bundle	No	Scope to a specific bundle

Scanning provides verification assistance, not automatic compliance certification. Human review remains part of the governance workflow.

Discovery tools

Three additional tools help agents explore the regulatory model.

Tool	Purpose
list_regulations	All supported regulations with status and tier access
list_frameworks	All control frameworks (AWS, Azure, NIST-CSF, OWASP Top 10, OWASP Mobile)
lookup_definition	Look up a legal term from a regulation (e.g. "personal data", "controller")

Troubleshooting

ERR_INVALID_AUTHAuthentication Required

Your API key doesn't have an organization. Ensure the key belongs to a user who is a member of an organization. Check that your X-Api-Key header is correctly formatted and has not expired.

ERR_INVALID_REGInvalid Regulation

Only GDPR is currently supported. NIS2 and DORA are on the roadmap.

ERR_EMPTY_BUNDLENo tasks returned for a bundle

The bundle exists but the data pipeline hasn't processed those articles yet. This is a temporary state.

ERR_NO_ENVNo environment block in get_bundle_tasks

Your organization hasn't completed Jira onboarding (which sets cloud platform, application type, and data sensitivity). The agent will ask you for this information via clarifications.

ERR_TIMEOUTConnection refused or timeout

Production endpoint: https://api.rulemesh.com/mcp. If you're getting timeouts, check your network connection and API key validity. Verify your firewall allows HTTPS traffic to api.rulemesh.com.

ERR_SCHEMA_MISMATCHValidation Error

The data payload provided does not match the expected schema defined in your policy. Use the inspect_schema tool to view the required fields.

← Back to documentation