An MCP server offers tools: actions an AI agent may call, each with a name, a description the agent reads, and the arguments it takes. The Code Effects server's tools are the Rule Repository's and Audit's own operations, and they are the same tools the in-app AI Assistant and AI Rule Editor use. Skills are short guides that teach an agent how to use the tools for a whole task, such as writing a rule or investigating a decision.
Why it matters to you. The tool list decides what an AI can do with your rules. It follows each caller's permissions, so you control it through the permission sets you already give people, and a few things are refused to every agent regardless.
- Only what the permissions allow is listed. A caller with view-only permissions sees the read tools for the core objects; one who may write rules sees the authoring tools, and so on. Only the tools of the libraries you added (
WithRepository, WithAudit) exist at all.
- Every call is checked again. A refused call is a tool error that names the missing permission, so the agent can tell the person.
- Errors the agent can fix (a wrong value, a version that no longer exists) come back as tool results it can act on; malformed calls are protocol errors. Both carry Code Effects control numbers.
- Reads are marked read-only, and nothing deletes. Writes are marked as non-destructive; updates as safe to repeat.
- Lists page. Every find tool takes a cursor and a page size.
- What an agent reads about an object is its description (at most 512 characters), never users' notes.
- Every write is recorded with the user and the agent, as RR's own saves are.
Added by WithRepository.
Find and read
| Tool |
What it does |
source_list |
Lists the source objects |
source_version_find |
Finds a source object's versions |
member_find |
Finds the fields, in-rule methods, actions and enumerations a rule can use, by words, with their types, bounds, operators, labels, descriptions and AI aliases |
data_source_find |
Finds the current items of a data source (needs the AgentDataSourceItems agent setting) |
rule_find, rule_get |
Finds rules; reads one |
rule_version_find, rule_version_get |
Finds rule versions; reads one |
draft_find, draft_get |
Finds drafts; reads one |
usage_find |
Which rule versions use given members, directly or through rules they call |
rules_overview |
Every rule of a source in one answer: type, live version, versions awaiting approval, drafts, recent runs, callers |
Write
| Tool |
What it does |
rule_validate |
Checks a rule written in the agent format against a source version, saving nothing: complete, unfinished or wrong, with each problem at its place |
rule_save |
Saves a new rule, a new version of a rule, or a draft. Always requests approval; a change to an existing rule needs the person's confirmation |
rule_update, rule_version_update |
Renames or describes a rule or a rule version |
source_update, source_version_update |
Renames or describes a source object or a source version |
draft_update, draft_convert |
Changes a draft; turns it into a version |
change_impact |
Before a change: the live rules that call the rule, its tests, versions waiting, and how many recent production decisions the proposed rule would decide differently (replayed from the record, nothing runs for real) |
Test
| Tool |
What it does |
rule_try |
Runs a rule on plain values and answers the verdict, the deciding conditions and what it would set. Records nothing |
test_outline |
What a rule version or draft reads and calls, as a test's values name them |
test_find, test_get |
Finds saved tests; reads one |
test_create, test_update |
Saves or changes a test |
test_run |
Runs saved tests, within the agent test-run limits |
test_run_confirm |
Runs tests that call production methods, after the person said yes (see below) |
value_template_find, value_template_get, value_template_create, value_template_update |
Reusable sets of test values |
History
| Tool |
What it does |
activity_find, activity_get |
The user activity: who changed what, when, through which agent |
rule_history |
A rule's history |
Production (the evaluations Audit records in the same database)
| Tool |
What it does |
evaluation_summarize |
Totals for a period: how many evaluations, outcomes, errors |
evaluation_find, evaluation_get |
Finds recorded evaluations; reads one with the values the rule read |
evaluation_explain |
Replays one evaluation step by step |
evaluation_analyze |
Totals, rates, averages, breakdowns and trends over the evaluations |
explain_outcome |
Why a call got a value: which rule set it, through which branch, on which values |
outcome_rates |
How often a field took a value, by segment and before and after a change |
Added by WithAudit, when the Rule Repository's tools are not added: evaluation_find, evaluation_get and evaluation_summarize, read with Audit's own queries. With both libraries, the Rule Repository's tools of the same names serve instead, with the explaining and analyzing tools beside them.
Confirmations for Production Calls
A test whose rule calls one of your methods that has no test method would run that method for real. Such a run needs permission 66 and the person's yes, every time:
- A client that can ask the person (MCP's elicitation):
test_run asks through the client ("This run calls Notify for real. Run it?") and continues with the answer.
- A client that cannot:
test_run answers with the calls it would make and a confirmation id. The agent must ask the person and then call test_run_confirm with the id. Being a separate tool, it shows up in clients that ask the person before tool calls.
A confirmation is signed, tied to the caller and to that exact run, valid for ten minutes and usable once, checked in the database so it holds across servers. A service, or an agent acting with no person behind it, runs such tests on permission 66 alone.
What No Agent Can Do
Whatever the permissions: make a version live, take one offline, approve, decline, delete, read notes, or read every user's AI conversations. Everything an agent saves requests approval and appears in RR for a person to review.
Skills
Code Effects ships six skills with the server:
| Skill |
Teaches the agent to |
codeeffects-author-rule |
Write or change a rule from the person's own words: find the source and members, ask when a name is ambiguous, check until complete, read the rule back, save as a version or a draft |
codeeffects-test-rule |
Write test values, keep them as value templates, save and run tests within the limits, and ask before production calls |
codeeffects-investigate-evaluations |
Answer questions about how rules behaved in production and why one decision came out as it did |
codeeffects-analyze-evaluations |
Answer analytics questions: rates, averages, breakdowns and trends |
codeeffects-check-document |
Check a policy, guideline or contract against the rules, clause by clause, and offer drafts for the gaps |
codeeffects-review-history |
Answer who changed what, when and through which agent |
The server serves them over MCP to clients that load skills that way, and they are also shipped in the CodeEffects.Rule.Mcp package's skills folder as plain SKILL.md folders, so a person can install them in a client that loads skills from files. Not every client loads skills yet, so the server's own instructions carry the essentials for every agent. Add your own skills beside these with SkillsFolder (see Setting Up the Server).