Setting Up the MCP Server
This page is for the developer who adds the MCP server to an application. The MCP server lets your users connect AI clients, such as Claude, to your rules, and lets your own automated agents work with them. This page explains what the server needs, how sign-in works, what each setting decides, and what your users need from you. The code itself is in the developer reference, linked from each step.
For the full technical reference, with code, see the Implementation Guide's MCP Server section, including Connecting Users to Your MCP Server.
The parts involved:
- The MCP server library (
CodeEffects.Rule.Mcp). It adds an MCP address to an ASP.NET Core application running on .NET 8. It works with the Rule Repository, with Audit, or with both, and offers the abilities of whichever you add. An application on the .NET Framework can run it as a separate .NET 8 application against the same database.
- Your application's sign-in. The MCP server has no sign-in of its own and never handles passwords. AI clients send people to your company's own sign-in page, and every request then carries proof of who signed in.
- A function you write that tells the server who each caller is and what they may do.
- The repository's and Audit's settings, which also apply to agents.
Step 1: Add the Server to Your Application
- Add the server with
AddCodeEffectsMcp(..), giving it the function that maps each signed-in caller (Step 3).
- Add the libraries you want agents to use:
WithRepository(..) with your database provider for the Rule Repository, and WithAudit(..) with your database provider for Audit. Add either or both.
- Publish the server at an address with
MapCodeEffectsMcp(..), usually /mcp, and require your application's sign-in on it.
var mcp = builder.Services.AddCodeEffectsMcp(o => o.MapCaller = mapCaller);
mcp.WithRepository(r => r.DbProvider = dbProvider);
mcp.WithAudit(a => a.DbProvider = dbProvider);
app.MapCodeEffectsMcp("/mcp").RequireAuthorization();
See McpServiceCollectionExtensions, RepositoryMcpExtensions, AuditMcpExtensions and McpEndpointRouteBuilderExtensions.
Step 2: Set Up Sign-In
People sign in to the MCP server through your company's identity provider, the same one your application uses, with its usual second step. Set up your application's standard sign-in validation against that provider. The MCP server then publishes the information AI clients need to find your sign-in page, so the server's address alone is enough for a client to connect.
The AI client must also be known to your identity provider. Depending on what your provider supports, the client identifies itself automatically, or your administrator registers each AI client (such as Claude) with the provider once and gives its client ID to the people who add the connector. Some widely used providers support only the second way.
For automated agents with no person to sign in, such as your own scheduled checks, issue a key or a client credential of your own; your mapping function (Step 3) turns it into a service user.
Two practical points:
- Cloud-hosted AI clients connect from their vendor's servers, not from the user's computer. Claude, for example, connects from Anthropic's servers, so your MCP address must be reachable from them; a firewall may allow the vendor's published addresses.
- Company AI plans usually let an administrator decide which connectors employees may add. Add yours there once, and each person only connects to it.
Step 3: Tell the Server Who Each Caller Is
Your mapping function receives the signed-in caller and returns an McpCaller:
- The user: ID, name and type, as for the repository. A person signing in through an AI client is a person (the default); your own automated agents are a service, or an AI agent working on its own.
- The agent: the AI client acting for the person, by an ID and a name your application takes from the sign-in itself, never from what the client says about itself. Every change made through the client then records both the person and the agent.
- The permissions: the same access mode and permission list you give the repository for that user.
Return nothing to refuse a caller. Whatever the permissions, an agent or a service can never make versions live, take them offline, approve, decline or delete; and an agent's saves always wait for a person's approval. A person's AI client sees only the abilities that person's permissions allow.
See McpCaller and CodeEffectsMcpOptions.
Step 4: Choose the Agent Settings
The settings that apply to agents are part of the repository's configuration, so the MCP server and the repository's own AI Assistant follow the same ones. Set them in WithRepository(..)'s Configure function, together with the repository's other settings, such as a translation or the notification function.
| Setting |
What it decides |
Default |
AgentTestLimits |
For AI agents: how many tests one request may run, how many per hour, and how many at the same time. |
10, 100, 2 |
ServiceTestLimits |
The same, for services. |
10, 100, 2 |
RecordAgentTestRuns |
Whether each agent test run is written to the activity log. The outcomes are recorded on the tests either way. |
Yes |
AgentDataSourceItems |
Whether agents may read the values of lists that come from your application, such as customers or accounts. |
Yes |
DataSourceItemFilter |
A function that lets only some of those values through, list by list and item by item. |
All values |
The test limits are counted on each server. If your application runs on several servers, the real limit is the setting times the number of servers.
See AgentSettings, TestRunLimits and RepositoryMcpOptions.
Connecting an AI client shares your source objects, rules and counts with that client's vendor. Real business data can reach an agent only through these, each under its own control:
- Values of lists that come from your application:
AgentDataSourceItems and its filter.
- Evaluations, and tests saved from them: the permissions to see evaluations and to save them as tests. Audit's excluded fields are never recorded at all.
- Test runs that call your application's real methods: the permission to run real calls, and, for a person, a confirmation every time.
Agents also read the descriptions and AI descriptions your developers give to fields; keep anything you would not want an AI vendor to read out of them.
Step 6: Tell Your Users How to Connect
Give your users the MCP address and point them to Connecting an AI Agent. If your administrator registers AI clients with your identity provider, include the client ID they need.