What can you do with this server?

The ERDL MCP Server provides deterministic rule enforcement for AI agents, ensuring consistent, compliant behavior through mathematical condition matching rather than relying on LLM prompts. * Evaluate/Guard tool calls (erdl_evaluate): Intercept and check any planned tool call against loaded rules before execution, returning decisions like ALLOW, DENY, CORRECT, REQUEST_HUMAN, or EMERGENCY_HALT. * List active rules (erdl_list_rules): View all currently loaded rules, optionally filtered by category (coding, engineering, writing, design, security, performance, testing, compliance, accessibility, or custom). * Create rules from natural language (erdl_create_rule): Turn plain-language instructions (e.g., "Never use any in TypeScript") into persistent YAML rules saved to ~/.openoba/rules/, taking effect immediately. * Simulate rules before creating them (erdl_simulate): Test a proposed rule against 3 auto-generated scenarios to validate it works as intended before committing. * Explain decisions (erdl_explain): Get a full decision trail showing every rule checked and why a particular decision was made. * Access rules as resources: Query erdl://rules/list for all rules as JSON, or erdl://status for the server's runtime status. * Use 30 built-in preset rules across coding, engineering, writing, and design categories — active immediately with no configuration. * Integrate with any MCP-compatible client: Works with Claude Desktop, Cursor, OpenClaw, VS Code/GitHub Copilot, and more. * Pro/Enterprise features (with license): Includes advanced execution rings (ESCALATE, ROLLBACK, QUARANTINE), Guardian Agent Role, Audit Export (OCSF/OTLP), Team Rules, a Dashboard, and compliance packs for standards like NIST and EU AI Act.

Which integrations are available for this server?

Integrates with GitHub Copilot via VS Code MCP configuration, allowing Copilot to follow enforced rules.

How do I use ERDL MCP Server?

1. Click on "Install 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., "@ERDL MCP Server Create a rule that bans console.log in TypeScript files" 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.

ERDL MCP Server

by OpenOBA

Overview Schema Related Servers Score Discussions

TypeScript

Local

ERDL MCP Server

Stop reminding your Agent to behave. Teach it. One when/then sentence is all it takes.

npm version npm downloads license tests MCP MIT

📖 中文版

npx -y @openoba-ai/erdl-mcp

30 rules. 5 tools. Zero config. Unlimited custom rules. Free forever.

ERDL demo — intercepting rm -rf /

The Problem

You tell your Agent "don't use any", "keep it short", "ask before adding dependencies". It nods. Five turns later, it's back to its old habits.

Prompt-based rules don't work. LLMs forget. They reinterpret. They rationalize. You're not guiding them — you're negotiating with them.

Related MCP server: Claude Critical Rules MCP Server

The Solution

ERDL (Entity-Rule Definition Language) is a deterministic rule engine that runs as an MCP Server. Your Agent doesn't try to follow rules — the engine enforces them before every tool call.

You say	What actually happens
"Never use `any`"	Blocked. The engine intercepts `write_file` calls, scans the content, and rejects `any` before the write happens.
"Don't start with 'In today's world'"	Denied. Writing rules fire before every output. The Agent receives the correction before it speaks.
"Ask before adding npm dependencies"	Intercepted. `exec` of `npm install` is stopped. You approve it, or it doesn't happen.
"Why did you do that?"	Explained. `erdl_explain` shows exactly which rule fired, what condition matched, and what happened.

How It Works

┌─────────────────────────────────────────────────────────┐
│                    Agent Workflow                        │
│                                                         │
│  User says: "Write me a function"                       │
│       │                                                 │
│       ▼                                                 │
│  LLM plans: use write_file(path, code)                  │
│       │                                                 │
│       ▼                                                 │
│  ┌──────────────────────────────────────┐               │
│  │    ERDL Action Guard (MCP Server)    │  ← Protocol   │
│  │                                      │    Layer      │
│  │  1. Load 30 built-in rules           │               │
│  │  2. Evaluate: field/operator/value   │               │
│  │  3. Decision: ALLOW / DENY / CORRECT │               │
│  │  4. Return badge card + explanation  │               │
│  └──────────────────────────────────────┘               │
│       │                                                 │
│       ▼                                                 │
│  Tool executes (or is blocked)                          │
│                                                         │
│  No prompt engineering. No negotiation. Protocol-level. │
└─────────────────────────────────────────────────────────┘

Quick Start

# One command. 30 rules active immediately.
npx -y @openoba-ai/erdl-mcp

That's it. No account. No API key. No configuration.

Chinese / 中文：

npx -y @openoba-ai/erdl-mcp --lang zh

Add it to your MCP client:

{
  "mcpServers": {
    "erdl": {
      "command": "npx",
      "args": ["-y", "@openoba-ai/erdl-mcp@latest"]
    }
  }
}

Or let ERDL generate the config:

npx @openoba-ai/erdl-mcp@latest --setup

Supported clients: Claude Desktop · Cursor · VS Code / Copilot · OpenClaw · WorkBuddy · any MCP-compatible client.

ERDL vs Prompt Rules

	Prompt / SKILL.md	ERDL
Enforcement	LLM "tries" to follow	Deterministic engine — guarantees execution
Reliability	May forget after 5 turns	Condition match is mathematical — zero hallucination
Visibility	Can't tell if it worked	`erdl_explain` shows every decision, every rule
Testing	Manual verification	`erdl_simulate` — 3 auto-generated scenarios
Portability	Tied to one platform	All MCP-compatible Agents
Overridability	LLM can "reinterpret"	Protocol-layer block — Agent cannot bypass

What's Included

30 Built-in Rules

Category	Count	Covers
`engineering`	13	Pipeline gates, no shortcuts, self-verify, decision logging, no force-push, no stash
`coding`	6	No `any`, no `@ts-ignore`, naming conventions, one-commit-one-change, dependency hygiene
`security`	6	No eval with input, no hardcoded secrets, no string SQL, validate all input, security headers, no stack traces
`testing`	2	Coverage never drops, no behavior without test
`writing`	2	Direct tone, no AI jargon
`observability`	1	No secrets in logs

5 MCP Tools

Tool	Use it when
`erdl_evaluate`	Before every tool call — mandatory Action Guard
`erdl_simulate`	Test a rule against 3 scenarios before creating it
`erdl_create_rule`	User says "remember this" → create a rule from NL
`erdl_list_rules`	User asks "what rules are active?"
`erdl_explain`	User asks "why did you do that?" → full decision trail

2 Resources

Resource	Purpose
`erdl://rules/list`	All active rules as JSON
`erdl://status`	Runtime status: rule counts by category, agent role

Creating a Rule

Turn your pain points into rules, one sentence at a time — banned, period. Turn your experience into rules, one sentence at a time — shared, forever.

Every pain point is a when(…) then(…) sentence:

when [trigger] · then [action]

Variable	Meaning	Example
when	What triggers it	code contains `any` · logs contain secrets · `git stash` used
then	What happens	Block it · Correct it · Allow with a warning · Pause for approval

Fill in the blanks:

when code contains any then block it.

That's a rule.

You →   "Never use `any` in TypeScript."

Agent → 1. erdl_simulate   → tests against 3 scenarios
        2. erdl_create_rule → saves to ~/.openoba/rules/
        3. Rule is active.  → next `any` is blocked.

You →   "Why was my code rejected?"

Agent → erdl_explain → full decision trail:
         ✅ no_any: tool.name in [write_file, edit, apply_patch] AND content contains "any"
         → DENY: Do not use `any` type.

Or write rules by hand in ~/.openoba/rules/ (ERDL SPEC §5 format):

protocol: "erdl/v1"
version: "1.0.0"

rules:
  - name: "no_console_log"
    description: "Don't commit console.log statements"
    priority: 10
    when:
      logic: AND
      conditions:
        - field: "tool.name"
          operator: in
          value: ["write", "edit", "apply_patch"]
        - field: "tool.args"
          operator: match
          value: "console\\.log"
    then: DENY
    message: "Remove console.log before committing"

📚 Full Tutorial → · 📖 Rule Reference (30 rules) →

Free vs Pro

	Free	Pro
5 MCP Tools	✅	✅
30 Preset Rules	✅	✅
Unlimited Personal Rules	✅	✅
Chinese / English	✅	✅
All 11 Operators	✅	✅
MIT Open Source	✅	✅
Execution Rings 1–2 (REQUEST_HUMAN, ESCALATE, ROLLBACK, QUARANTINE)	—	✅
Guardian Agent Role	—	✅
Audit Export (OCSF / OTLP)	—	✅
Team Rules	—	✅
Dashboard (hit statistics)	—	✅
Enterprise Compliance (GB/Z 185, NIST, EU AI Act)	—	Enterprise

Get a Pro License →

CLI Reference

npx @openoba-ai/erdl-mcp@latest           # Start (auto-latest via npx)
npx @openoba-ai/erdl-mcp@latest --lang zh  # Chinese mode
npx @openoba-ai/erdl-mcp@latest --upgrade   # Force upgrade
npx @openoba-ai/erdl-mcp@latest --uninstall # Clean removal
npx @openoba-ai/erdl-mcp@latest --setup     # Show MCP config
npx @openoba-ai/erdl-mcp@latest --help      # Full usage

From Source

git clone https://github.com/OpenOBA/erdl-mcp-server.git
cd erdl-mcp-server
npm install
npm run build
npm test        # 92 tests
node bin/erdl-mcp.js

Contributing

ERDL MCP Server is MIT-licensed and open to contributions. See CONTRIBUTING.md for guidelines.

Star History

If ERDL helps your workflow, give us a ⭐ on GitHub — it helps others discover the project.

License

MIT · OpenOBA · @OpenOBA

Deterministic architecture, not prompt engineering.

Available Tools

5 tools

erdl_create_ruleCreate ERDL RuleA

Create a new ERDL rule from natural language. Use this when the user corrects your behavior and wants you to "remember" it.

EXAMPLE SCENARIOS:

User: "Never use 'any' types" → Create: coding rule, intent: "write typescript code", DENY if "any" appears
User: "Don't start with 'in today's world'" → Create: writing rule, intent: "write blog post", DENY
User: "Always use Tailwind, never inline styles" → Create: design rule, intent: "create UI", ALLOW with instruction

The rule is saved to ~/.openoba/rules/ and takes effect immediately (no restart needed).

ParametersJSON Schema

Name	Required	Description
`category`	Yes	Rule category
`decision`	Yes	ALLOW with instruction, or DENY with reason, CORRECT with correction, REQUEST_HUMAN for approval
`keywords`	No	Tool names or arg values to match against
`triggers`	No	Tool names that should trigger this rule (e.g., ["exec", "write_file"])
`instruction`	Yes	What the Agent should do (for ALLOW) or the reason for blocking (for DENY)
`naturalLanguage`	Yes	The rule described in natural language, e.g., "Never use TypeScript any type, use unknown instead"

TDQS

A4.2/5.0

Behavior4/5

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

No annotations are provided, so the description must convey behavioral traits. It states the rule is saved to ~/.openoba/rules/ and takes effect immediately with no restart needed. While it could mention potential side effects like overwriting existing rules, the provided information is adequate for understanding the basic 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?

The description is well-structured with a clear purpose statement followed by relevant example scenarios. It is concise (three short paragraphs) and front-loaded, though the examples could be slightly trimmed. No unnecessary information is present.

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?

Given 6 parameters (4 required), no output schema, and no annotations, the description covers the core use case and provides examples. However, it lacks information about return values (e.g., rule ID or success message) and error conditions. This is a minor gap, resulting in an adequate but not comprehensive description.

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 baseline is 3. The description provides example scenarios that map natural language to category and decision, but does not add detailed semantics beyond what the schema provides. The examples help contextualize parameter usage, which justifies the baseline score.

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

Purpose5/5

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

The description clearly states 'Create a new ERDL rule from natural language.' and provides specific example scenarios that illustrate the tool's purpose. This distinguishes it from sibling tools like erdl_evaluate, erdl_explain, erdl_list_rules, and erdl_simulate.

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

Usage Guidelines5/5

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

The description explicitly says 'Use this when the user corrects your behavior and wants you to "remember" it.' This provides clear guidance on when to invoke this tool versus alternatives, and the example scenarios further illustrate appropriate usage.

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

erdl_evaluateERDL Action Guard — Tool Call InterceptorA

ERDL Action Guard — evaluates planned tool call against loaded rules BEFORE execution.

YOU MUST call this BEFORE every tool call (exec, write_file, edit, web_search, etc). This is MANDATORY. The Guard cannot be bypassed.

After calling, check the decision:

ALLOW → proceed with the tool call, follow any instructions
DENY → STOP. Do not execute the tool. Tell the user what was blocked.
CORRECT → fix the request and retry
REQUEST_HUMAN → ask the user for approval before proceeding

Always show the result to the user as a badge card.

RESPONSE (compact badge card format):

"ALLOW": ✅ ERDL Guard · N rules
"DENY": 🛑 ERDL Blocked · reason
"REQUEST_HUMAN": 👤 ERDL Approval · reason
"CORRECT": 🔧 ERDL Correct · correction
"EMERGENCY_HALT": 🚨 ERDL HALT · reason
"PASS": 🔵 ERDL Pass · N rules checked

ParametersJSON Schema

Name	Required	Description
`agent_id`	No	Optional agent identity for audit context
`tool_args`	No	Arguments being passed to the tool
`tool_name`	Yes	Name of the tool being called (e.g., "exec", "write_file", "web_search")
`session_id`	No	Optional session identifier for audit chain

TDQS

A4.2/5.0

Behavior4/5

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

Without annotations, the description provides adequate behavioral insight: it evaluates rules, returns a decision, and does not execute the tool itself. It could add that no state is modified, but the core behavior is clear.

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

Conciseness3/5

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

The description is longer than necessary, including a full response format with badges and detailed decision handling. While well-structured, it could be more concise by moving the response format to a separate section or simplifying it.

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?

Given 4 parameters, one required, and nested objects, the description covers the essential usage. It lacks details on error cases (e.g., no rules loaded) but is sufficient for basic operation. The output schema is absent, so the description compensates with response format details.

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 baseline is 3. The description repeats the parameter names but does not add meaningful meaning beyond the schema's brief descriptions. For example, 'tool_args' is described as 'arguments being passed to the tool', which is obvious.

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

Purpose5/5

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

The description clearly states that the tool evaluates a planned tool call against loaded rules before execution. It distinguishes from sibling tools like erdl_create_rule, erdl_explain, etc., which handle rule management rather than evaluation.

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

Usage Guidelines5/5

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

The description explicitly says 'YOU MUST call this BEFORE every tool call' and provides clear instructions for handling each decision outcome (ALLOW, DENY, CORRECT, REQUEST_HUMAN). This gives unambiguous guidance on when and how to use the tool.

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

erdl_explainExplain ERDL DecisionA

Show the FULL decision trail for the last action. Answers "why did you do that?" — shows every rule that was checked and whether it fired.

Use this when:

User asks "why did you act that way?"
User is confused about a DENY or unexpected ALLOW
You want to show transparency in your decision-making

ParametersJSON Schema

Name	Required	Description	Default
`tool_args`	No	The same tool arguments you used for erdl_evaluate
`tool_name`	Yes	The tool name to explain (same as you used for erdl_evaluate)

TDQS

A4.3/5.0

Behavior4/5

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

No annotations provided, but description discloses the tool shows 'every rule that was checked and whether it fired' and references 'the last action', giving insight into internal state retrieval. Missing limitations (e.g., requires prior evaluation) but sufficient.

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?

Short, front-loaded with purpose, bullet points for usage. Every sentence serves a purpose; no redundancy.

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?

No output schema, but description does not explain the return format or structure of the decision trail. Mentions 'shows every rule' but not how it's presented. Incomplete for a complex tool with nested objects.

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

Parameters4/5

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

Schema covers 100% of parameters. Description adds value by linking tool_name and tool_args to 'same as you used for erdl_evaluate', providing cross-tool context. No additional format details, but helpful.

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

Purpose5/5

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

Description clearly states 'Show the FULL decision trail for the last action' and answers 'why did you do that?'. It distinguishes from siblings like erdl_evaluate (which runs evaluation) by focusing on explanation after an action.

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

Usage Guidelines4/5

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

Explicitly lists when to use: when user asks why, confused about DENY/unexpected ALLOW, or for transparency. No explicit exclusion, but context is clear and actionable.

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

erdl_list_rulesList ERDL RulesA

List all currently loaded ERDL rules. Use this when the user asks "what rules do you have?" or wants to see what constraints are active. Categorize by type: coding, engineering, writing, design, security, performance, testing, compliance, accessibility, custom.

ParametersJSON Schema

Name	Required	Description	Default
`category`	No	Filter by category. Use "all" or omit to show everything.

TDQS

A4.3/5.0

Behavior4/5

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

No annotations exist, so the description bears the full burden. It describes a read-only listing operation with no mention of side effects, which is appropriate for a list action. The behavioral impact is minimal and predictable, fulfilling transparency needs adequately.

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?

The description is concise (three sentences) with no wasted words. Each sentence adds value: purpose, usage guidance, and categorization hint. Structure is logical and front-loaded with the core action.

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

Completeness5/5

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

Given the tool's simplicity (one optional parameter, no output schema), the description covers all essential aspects: what it does, when to use, and how to categorize results. There is no significant missing information.

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%, so the baseline is 3. The description adds a categorization hint ('Categorize by type: ...') that mirrors the enum in the schema but does not provide additional meaning beyond what the schema already offers.

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

Purpose5/5

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

The description clearly states the action (list) and resource (ERDL rules). It includes usage examples ('what rules do you have?') and naturally distinguishes from sibling tools like erdl_create_rule or erdl_evaluate which have different purposes.

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

Usage Guidelines4/5

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

Provides explicit guidance on when to use the tool (when user asks about rules or constraints). Lacks explicit when-not-to-use or alternative tools, but the context of sibling names and the examples make the usage scope clear.

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

erdl_simulateSimulate ERDL RuleA

Test a potential rule against 3 scenarios BEFORE creating it. This prevents "wishful thinking" rules that sound right but don't work.

Always call this BEFORE erdl_create_rule when the user says "remember this" or "create a rule". Show the simulation results and ask if the user wants to proceed.

ParametersJSON Schema

Name	Required	Description
`category`	Yes	Rule category
`decision`	Yes	What happens when rule matches
`keywords`	Yes	Tool names or args values to match
`ruleName`	Yes	Proposed rule name
`triggers`	No	Tool name triggers (e.g., ["exec", "write_file"])
`instruction`	Yes	The instruction or reason

TDQS

A4.1/5.0

Behavior3/5

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

Description implies it is a safe, non-destructive simulation ('test... BEFORE creating'), but without annotations it does not explicitly state it is read-only or has no side effects. Additional statements about safety 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.

Conciseness4/5

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

Three sentences with front-loaded purpose and clear flow. Efficient and easy to parse, though it could be slightly more concise.

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?

Covers the essential workflow: test before creation, show results, ask to proceed. However, it does not explain what the '3 scenarios' are or how they are generated, leaving minor ambiguity for the agent.

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 description does not add extra meaning beyond what is already in the parameter descriptions. Baseline 3 is appropriate.

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

Purpose5/5

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

The description specifies 'Test a potential rule against 3 scenarios BEFORE creating it,' providing a specific verb ('test'), resource ('rule'), and scope ('before creation'). This clearly differentiates it from the sibling tool erdl_create_rule.

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

Usage Guidelines5/5

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

Explicit instructions: 'Always call this BEFORE erdl_create_rule when the user says "remember this" or "create a rule".' It also tells the agent to show results and ask for confirmation, leaving no ambiguity about when and how to use the tool.

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

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.3/5.0

Disambiguation5/5

Each tool has a clearly distinct purpose: create, evaluate, explain, list, simulate. No overlap or ambiguity between them.

Naming Consistency5/5

All tools use a consistent 'erdl_' prefix and verb-based naming (e.g., create_rule, evaluate, explain, list_rules, simulate). Minor variation in noun inclusion is acceptable.

Tool Count5/5

5 tools is well-scoped for a rule management server. Each tool covers a necessary function without redundancy or bloat.

Completeness3/5

The tool set covers creation, evaluation, explanation, listing, and simulation, but lacks update and delete capabilities for rules, which are notable gaps for a rule management system.

Maintenance

ActivitySlowing

ResponsivenessSyncing

Resources

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Agent Module A
dev.agent-module
Deterministic compliance and vertical knowledge bases for autonomous agents. Free 24hr trial.
Autonomous Agents Knowledge & Memory RAG Systems
722
mcp-server
io.decisionrules
Create, manage, and test business rules directly from your AI agent via the DecisionRules platform.
App Automation Developer Tools
1
boundaryai
ai.boundaryai
Deterministic runtime safety for AI agents: scan PII, gate tool actions, verify LLM output.
Security AI & Machine Learning Agent Orchestration
2
PolicyLayer
com.policylayer
The system of record for AI agent authority: playbooks, routed policy questions, reusable rules.
Autonomous Agents
2

Related MCP Servers

focal-mcp
Developer Tools Coding Agents
BAESI
A
license
Not graded
quality
C
maintenance
Centralizes AI behavior rules and applies them across tools like Codex, Claude Code, and Cursor, enabling agents to fetch up-to-date rules before responding.
Updated 7 months ago (2026-02-04 09:58 UTC)
1
MIT
Claude Critical Rules MCP
Developer Tools Documentation Access Testing & QA Tools
optimaquantum
A
license
A
quality
C
maintenance
Enforces 21 critical rules derived from 96+ documented failure patterns to prevent common AI assistant mistakes. Provides automatic compliance checklists, rule summaries, and auto-updates.
Updated 8 months ago (2026-01-10 13:29 UTC)
5
15
7
MIT
sop-mcp
Autonomous Agents Agent Orchestration
ValueArchitectsAI
A
license
A
quality
A
maintenance
Enables AI agents to execute multi-step Standard Operating Procedures step by step, with enforcement of completion at each step, making LLM behavior predictable and auditable.
Updated 5 days ago (2026-08-29 15:46 UTC)
5
3
Apache 2.0
gnt MCP Serverofficial
Legal & Compliance Autonomous Agents
gnt-ai
A
license
Not graded
quality
A
maintenance
Enables AI agents to query live, human-approved rules before taking actions, ensuring compliance and reducing errors.
Updated 10 days ago (2026-08-25 09:42 UTC)
27
Apache 2.0

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/OpenOBA/erdl-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server

ERDL MCP Server

The Problem

The Solution

How It Works

Quick Start

ERDL vs Prompt Rules

What's Included

30 Built-in Rules

5 MCP Tools

2 Resources

Creating a Rule

Free vs Pro

CLI Reference

From Source

Contributing

Star History

License

Available Tools

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

gnt MCP Serverofficial

Latest Blog Posts

MCP directory API