MCP Server

Model Context Protocol is a shared standard that lets an AI client connect directly to a tool and take actions in it, instead of reading documentation and guessing. It is supported natively by ChatGPT, Claude, Cursor, Gemini, Microsoft Copilot, and others.

The DecisionRules MCP Server is the connection between your AI client and your DecisionRules Space. Once connected, your assistant can create rules, explain them, generate test data, run them against real input, manage versions and tags, and trace dependencies.

No. You connect with the DecisionRules account you already have and choose which Space the assistant works in during setup.

Yes. The Space must have a Management API Key configured. Apart from that, the Space can be empty and your first request can create something in it.

Yes. The optional Distribution server serves DecisionRules documentation, templates, and reusable functions into your conversation with no login required. It never touches your Space.

Learn more: related documentation

Claude, ChatGPT, GitHub Copilot, VS Code, and Codex have their own connector entries. Cursor and other MCP-compatible clients connect through Smithery. DecisionRules is also published in the Docker MCP Catalog and Azure MCP Center.

Open the connector list in your client, find DecisionRules, sign in, and pick a Space. Clients that cannot complete a sign-in flow can authenticate with a Management API Key instead.

It defines everything the assistant can see and touch. It cannot reach rules in another Space and will not switch on its own. For a first trial, use a sandbox Space rather than one running production decisions.

Usually the wrong Space was selected. Connect again and check the Space picker, especially when your account has several Spaces.

Check that your client is in agent mode rather than plain chat mode. In Copilot and Cursor this is a separate toggle, while the tools can remain visible in either mode.

Anything from a full rule to a single lookup. Common requests include creating a Decision Table from a description, turning an attached price list into a new version, generating test cases, running a rule against input, comparing versions, and finding dependencies.

No. Generation runs through the DecisionRules AI Assistant, the same one built into the editor, trained on real rule logic and best practices and aware of your table structure.

Learn more: related documentation

Yes. You can solve a rule against any input and receive the result in the conversation. For a full pass and fail test suite, use Rule Tests in the editor.

Yes. MCP clients can hold several server connections at once, and your assistant can use them in one request. Each server is connected separately and DecisionRules does not need to know the others exist.

The assistant can change rules, but access is scoped to one Space, every change lands in version history, and nothing reaches callers until a version is published. Event Logs record every change and who initiated it.

Rule history captures every save, versions are explicit snapshots, and both support rollback in one click. The worst realistic outcome is a rollback.

No. Requests run under enterprise terms with no training on your data. DecisionRules holds SOC 2 and ISO 27001 certifications, with configurable data residency and SSO available. When you use your own model provider, its terms determine the no-training guarantee.

The API is for systems and repeatable calls. MCP is for conversations, authoring, and debugging. Most teams author and debug through MCP, then promote and keep changes in sync through the API.

No. Anything scheduled, reproducible, or high-volume belongs on the Management API. A pipeline that occasionally interprets instructions differently is not a pipeline.

Yes. Rules can be authored and debugged through MCP, then promoted and kept in sync through the API. MCP writes the draft, and the API ships it.