Overview
The MCP server is one of three ways into KernelPort, beside the in-process SDK and the HTTP API. It exists so the agents you already run — built on any framework that speaks MCP — can propose writes to your systems without a bespoke integration, and so every proposal leaves a proof record.
- Mode
- Mode B · Attested advisory Attested advisory. Evaluated against your rules and recorded.
- Tools
- 34 in all: 18 read, 10 stage, 6 act.
- Behind it
- KernelPort v1. The same six calls, outcomes and records as every other transport; see KernelPort v1.
- Who uses it
- Third-party agents; elan1 Work Attach, against your own ERPNext; elan1 Decide and elan1 Run tooling, which may also use HTTP.
- Claims
- A third-party agent makes no claim to run on elan1 Govern until conformance tests C1–C14 pass. Until then it connects in Mode B.
Three tool classes
Every tool belongs to exactly one class. The class decides what the tool may do, which token it needs, and whether it can ever lead to a change in your system of record. An agent’s token decides which classes it can see at all.
| Class | Tools | May | May never | Token |
|---|---|---|---|---|
| Read | 18 | Read declarations, write types, obligations and proof records; verify a stretch of chain; preview scope. | Change anything, or write a proof record. | Read-only |
| Stage | 10 | Prepare and check a write intent, and resolve its scope, without committing it. | Climb the Right Path to an allow, or reach a system of record. | Read-only |
| Act | 6 | Send a write intent up the Right Path, withdraw one, and receive approval requests as requests for input. | Approve its own request, or answer an approval with an agent token. | Tenant token, act scope |
Counts are fixed. The exact names and split of capabilities inside each class are in the customer reference, so the lists below describe tools by what they do. Illustrative grouping.
Class 1 of 3
Read tools · 18
Read tools let an agent understand the rules before it proposes anything, and check what happened afterwards. They cannot change anything, and calling one is never a governed action.
| Capability | What the agent gets | KernelPort behind it |
|---|---|---|
| Declarations | A declaration and a named version: its seven blocks, and the write types it allows. | Reads what define registered |
| Write types | The payload shape a write type expects, so an intent is right first time. | Reads what define registered |
| Obligations | Whether a held write is still waiting, who must decide, and when the hold expires. | Reads the state assert and refuse leave |
| Proof records | A record by seq or by write_id: the sixteen Seal v6 fields. | Reads what seal wrote |
| Chain checks | Whether a stretch of chain is intact, or the findings if not. | verify |
| Scope preview | Residency domain, whether a write type is allowed, blast radius, autonomy level against its ceiling. | scope — advisory only |
At L1, chain checks need elan1. From L2, signed records are checkable offline with elan1-verify, without calling this server.
Class 2 of 3
Stage tools · 10
Stage tools let an agent build a write intent and check it before sending it: does the payload match the declared write type, is the record at the version the agent thinks, and where would the intent stand on scope and autonomy. A staged intent has no effect until an act tool sends it.
| Capability | What the agent gets |
|---|---|
| Build an intent | A typed write intent with a fresh write_id, the declaration and version pinned, and the payload hashed as the record will hash it. |
| Check the shape | Whether the payload meets the declared write type. A shape problem is found here, not as a contract error later. |
| Check the target | Whether the record is at the expected version, so a stale read is caught before it becomes a refusal. |
| Resolve scope | The blast radius and the autonomy outcome to expect — for example, that a person will have to approve. |
evaluate() to a decision, and assert resolves scope and autonomy again. Treat a clean stage result as “ready to propose”, nothing more.Class 3 of 3
Act tools · 6
Act tools are the only tools that send anything up the Right Path. Each one ends in a KernelPort outcome — committed, refused or escalated — and every outcome writes a proof record. A refusal is metered at 40% of one governed action.
| Capability | What happens | KernelPort behind it |
|---|---|---|
| Send a write intent | Climbs rungs 0b to 9 and answers synchronously. | assert |
| Withdraw an intent | Records a typed refusal for an intent the agent no longer wants. | refuse |
| Follow a held write | Waits on an obligation; the approver's answer arrives as a request for input to that person. | assert · refuse |
| Read the final outcome | Returns the original outcome, sequence and digest for a write_id. Replaying never writes twice. | Idempotent replay |
→ tools/call
{
"name": "<act tool · send a write intent>",
"arguments": {
"write_id": "wr_specimen_7c2",
"write_type": "journal_entry.post",
"declaration": { "id": "decl_month_end_close", "version": 7 },
"record": { "id": "je_specimen_5531", "expected_version": 1 },
"payload": { "...": "as the declared write type requires" }
}
}
← {
"outcome": "escalated",
"rung": 6,
"reason": "Above the autonomy ceiling. A named person, not the asker, decides.",
"obligation": "OB-specimen-0412",
"proof": { "seq": 1039, "digest": "sha256:3b9a51c2…7e04d1f8" }
}Tool names in angle brackets describe the capability; real names are in the customer reference.
Approvals over MCP
Where the autonomy level says a person must decide, the act tool answers escalated with an obligation. The approval then comes back through MCP as a request for input, addressed to the named approver. It shows the difference, the gates passed and the policy version.
← request for input (addressed to the named approver)
{
"obligation": "OB-specimen-0412",
"approver": "usr_specimen_approver",
"asker": "agt_specimen_gl02",
"shows": ["the difference", "gates passed", "policy version 2027.06.1"],
"choices": ["approve", "refuse"],
"expires_at": "2027-07-14T11:05:12+05:30"
}
→ answer from usr_specimen_approver: "approve"
← { "outcome": "committed", "proof": { "seq": 1042, "digest": "sha256:f2423aa3…5aca2c18" } }- The approver is a named person who is not the asker. An agent token can never answer a request for input; conformance test C11 checks both.
- If nobody answers before the hold expires, expiry is a refusal. It is recorded and metered at 0.4 of a governed action.
- A refusal by the approver is recorded through
refuse, with the approver as the actor (F09, F10). - Your MCP client must route the request to the approver, never auto-answer it. A host that cannot show it should leave the obligation to expire.
Pinned tool descriptions
An agent decides which tool to call by reading its description, so a description is part of the control surface. Each of the 34 tool descriptions is pinned by hash in the declaration. A changed description shows as a version change, never as a silent update.
→ tools/list
← {
"tools": [
{
"name": "<read tool · read a proof record>",
"class": "read",
"description": "Returns one proof record by seq or write_id. Changes nothing.",
"description_hash": "sha256:2c7e90a1…b14f63d2"
},
{
"name": "<act tool · send a write intent>",
"class": "act",
"description": "Sends one typed write intent up the Right Path. Answers committed, refused or escalated.",
"description_hash": "sha256:a05d3e88…9e21c7f0"
}
// … 34 tools in all: 18 read · 10 stage · 6 act
]
}- Read once per declaration version.
Cache
tools/listagainst the declaration version your intents pin. - Compare hashes.
If a description hash differs from the one you reviewed, treat it as a new version: review before your agent uses it.
- Pin in production.
Production keys pin declaration and policy versions; “latest” is rejected (conformance test C13).
Connecting a client
Point any MCP client at your elan1 Govern endpoint with a tenant-scoped token. The token decides which classes the agent sees: a read-only token sees read and stage tools; a tenant token with act scope also sees act tools.
{
"mcpServers": {
"elan1-govern": {
"url": "https://<your elan1 Govern endpoint>/mcp",
"headers": {
"Authorization": "Bearer <tenant token>",
"X-Tenant": "tnt_specimen_01"
}
}
}
}- Tenant
- One token, one tenant. Chains never cross tenants, and a cross-domain query is not slow; it is impossible.
- Missing grant
- An agent without a grant resolves to A0 Observe, the lowest autonomy level (conformance test C6).
- Unreachable
- If elan1 does not answer, nothing is allowed. elan1 Run tooling fails closed in this case; your agent should too.
What Mode B means here
Over MCP, elan1 Govern evaluates and records. Your system still holds the write credential and makes the write. That is why we call it attested advisory and never say a write was blocked.
| Outcome | Your agent should | The record says |
|---|---|---|
| Committed | Make the write through your own system, as proposed. | elan1 evaluated this intent against your rules and allowed it. |
| Escalated | Wait. Do not write until the obligation resolves. | A named person must decide. |
| Refused | Not write. Show the code to a person. | A rung, or a person, said no. Metered at 0.4 of a governed action. |
| No answer | Not write. Fail closed. | Nothing, until elan1 answers. |
Integration checklist
- Map the writes.
List the writes your agent makes and the declaration and write type each belongs to.
- Read before you stage.
Use read tools for the declaration version and write type shape; pin both.
- Stage, then act.
Build and check the intent with stage tools; send it with an act tool, with a write_id you persist first.
- Branch on the outcome.
Committed: write. Escalated: wait. Refused or no answer: do not write. See Errors and refusals.
- Route approvals to people.
Requests for input go to the named approver, never back to the agent.
- Run the suite.
Pass conformance tests C1–C14 before you claim your agent runs on elan1 Govern.
What the customer reference covers
- Tool names, argument names and the split of capabilities inside each class. The counts — 18, 10 and 6 — are fixed.
- The endpoint, transport and header names in the client configuration.
- The fields carried in a request for input beyond the obligation, the approver and the choices.
- Control-plane operations such as registering a declaration. They are control-plane calls on the HTTP API.