Provides tools for interacting with a Cardano stake pool, including monitoring health, checking backend diagnostics, auditing operational logs, and managing KES key rotation plans with safety modes and execution controls.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@experimental-cardano-pool Check pool health and create a rotation plan for the next KES period."
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.
Unmaintained — September 2026. BEACN's own pool retired at epoch 656, so this starter will not receive updates. It stays public as a reference; read the safety notes below before adapting any of it. BEACN archive
v0.1.0-experimental — reference implementation, not a turnkey mainnet product.
An MCP server for inspecting the design of guarded pool maintenance and adapting it to your own infrastructure. Built from work on a private BEACN deployment. This distribution contains no private deployment configuration or Git history.
The default is a local simulation in SAFE mode. It does not contact Cardano, read real signing keys, use SSH, or control system services. Every successful simulation response is labeled. Its health values are synthetic.
The included Linux/SSH adapters can affect a live block producer only after separate operator integration. Bugs, wrong configuration or failed recovery can interrupt block production. No independent security audit or production acceptance is claimed for this public version. Validate an isolated testnet deployment before considering mainnet.
Download the experimental starter, unzip it, and open the extracted folder in a terminal. Follow the quickstart below to try the local simulation first. Fork the repository to adapt it. Do not point an AI at your production node and ask it to install this blindly.
For a deeper review: three-mode simulation, architecture and safeguards, production integration requirements, and what the tests establish.
Related MCP server: CodexPro Runtime
Linux with Python 3.12 or newer. Use an ordinary user, not sudo.
python3 -m venv .venv
.venv/bin/python -m pip install -r requirements.lock
.venv/bin/python -m pip install --no-deps .
.venv/bin/python scripts/smoke_mcp.pyThe smoke test uses the actual MCP SDK/stdio transport. It reads simulated health, creates an inert plan and verifies that SAFE mode refuses execution. It neither enables maintenance nor connects to a real node.
Register the following with an MCP client, replacing only the executable path:
{
"mcpServers": {
"experimental-cardano-pool": {
"command": "/absolute/path/to/checkout/.venv/bin/cardano-pool-mcp",
"args": []
}
}
}No API token is required for this local MCP. The client may have its own model provider/account requirements. The default demo is temporary and resets when the server exits. Persistent simulation and mode exercises demonstrate assisted approval, experimental execution and failure recovery.
Mode | Authority |
SAFE (default) | Observation and inert plan/audit writes; no node maintenance. |
ASSISTED | A separate operator approves an exact, expiring plan digest. |
EXPERIMENTAL | Explicit opt-in, accepted backend/release, allowed periods and an expiring grant. Disabled by default; maximum 90 days. |
Neither approvals nor mode changes are MCP tools. In production they must be controlled by an independent operator identity. The demo uses your local user for both sides to make experimentation convenient; it does not prove OS privilege isolation. An agent with that user's shell access can change demo policy. An administrator can also bypass a production MCP using separate access.
Tool | Effect |
| Read health, authority, KES coverage and transaction state. |
| Read backend diagnostics; demo results are explicitly synthetic. |
| Read a hash-chain-verified operational event log. |
| Write an inert plan for a pre-signed KES period. |
| Read the outcome for the same transaction ID. |
| Execute only an authorized plan; SAFE refuses it. |
No shell tool, arbitrary file reader, cold-key path, approval flag or mode setter is accepted in an MCP request. Strict schemas and runtime validation reject unexpected fields, invalid types, duplicate JSON keys and oversized frames.
The engine records intent, stages a verified pair, rechecks authority, stops the
services, atomically switches the credential generation, restarts, checks health
and commits. Failure attempts a checked rollback. Unsafe recovery ends in
RECOVERY_REQUIRED with startup inhibited. See architecture.
Fresh cold-key signing is not implemented. The signer interface returns
SIGNER_REQUIRED; a finite pre-signed inventory is the only autonomous source.
Do not copy someone else's KES ladder, counter, genesis anchors or acceptance
record. This adapter supports a conservative same-counter ladder whose
counter matches the observed chain state. Unknown counters and fresh issuance
require a separate operator review. Integration limits.
Runnable stdio MCP simulation, three modes and operator-only demo controls.
Durable transaction engine, atomic generation logic, approval and audit code.
Signature verification and a signer abstraction that refuses fresh signing.
Linux/SSH/broker/launcher/monitor reference adapters and invalid-by-default example configuration; no production installer.
Synthetic tests for input rejection, approval tampering, commit/rollback, process death, storage failure, startup guards and protocol boundaries.
MIT license and security reporting guidance.
The private deployment's dashboard, personal host automation, VM power helpers,
real certificates, logs, operational receipts and credentials are excluded.
pool_status and pool_checks provide the monitoring interface for an optional
dashboard. No public website, HTTP listener or automatic cron is installed.
.venv/bin/python -m pytest -q
.venv/bin/python scripts/release_check.pySee validation for what was actually tested. Passing tests does not establish safety for another operator's production setup.
Read integrity-checked sanitized audit events.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, openWorldHint=false, and destructiveHint=false, so the safety profile is covered. The description adds the context that events are integrity-checked and sanitized, but does not explain those terms or disclose other behaviors such as authentication, output limits, or ordering.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, compact statement with no filler words. Every adjective adds relevant context about the nature of the returned audit events.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, read-only, idempotent tool, the description tells the agent what it will receive and that no input is required. A minor gap is that 'integrity-checked' and 'sanitized' are not elaborated, and there is no output schema, but this is sufficient for a simple no-argument read.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters and 100% schema description coverage, which is the baseline-4 case. The description has no parameter semantics to supply because no parameters exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific action ('Read') and resource ('audit events') with qualifiers ('integrity-checked sanitized') that clarify what kind of data is returned. It does not explicitly reference sibling tools, but 'audit events' is clearly distinct from pool_status, pool_checks, rotation_plan, rotation_status, and rotation_execute.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided for when to use this tool versus alternatives such as pool_checks or rotation_status. There are no explicit conditions, exclusions, or references to sibling tools, leaving selection entirely to inference from the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read-only readiness checks: binary pins, public certificate signature, clock, storage, relay and standby witnesses. Never rotates, starts the vault or signs.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark this as readOnly, idempotent, and non-destructive. The description adds the concrete statement that the tool never rotates, starts the vault, or signs – behavior not covered by the annotations. This reinforces the passive nature of the check and gives agents confidence about side-effect-free invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no filler. The core purpose is front-loaded, followed by a compact list of concrete check subjectsabb, and the safety boundary is stated in a short final sentence. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool with no output schema, the description covers what it checks, that it is read-only, and what it will never do. The only unaddressed area is the exact return shape (e.g., pass/fail or detailed report), but this is a minor gap given the simple no-input nature and the safety annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero properties and zero required parameters, so with 0 params the baseline is 4. The description contributes no parameter details, but none are needed because the tool takes no arguments. There are no schema-documentation gaps to compensate for.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description begins with 'Read-only readiness checks,' a specific verb-noun combination, then enumerates the exact resources being checked: binary pins, public certificate signature, clock, storage, relay and standby witnesses. The closing sentence explicitly separates this tool from rotation and vault-starting operations, making the purpose highly distinguishable from siblings like rotation_execute.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear negative usage guidance ('Never rotates, starts the vault or signs'), which prevents misuse. However, it does not explicitly mention alternative tools like rotation_execute or pool_status for when rotation or status queries are needed. Usage is implied through the exclusions rather than positively flagged with alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read BP health, versions, KES, policy and ladder coverage. Never starts a vault.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the basic safety profile. The description adds 'Never starts a vault,' which reinforces read-only behavior and gives a concrete guarantee. It does not disclose return format, rate limits, or auth requirements, but given the annotations, this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no fluff. It front-loads the core action ('Read BP health, versions, KES, policy and ladder coverage') and then adds a critical safety constraint. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a no-parameter, read-only tool with rich annotations, the description covers what it reads and a key behavioral constraint. The lack of an output schema means it does not describe return format, but for a status read it is reasonably complete for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the description has no parameter semantics to add. The baseline for 0 params is 4, and the description correctly avoids adding any unnecessary parameter-related content.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Read' and the specific resources: BP health, versions, KES, policy and ladder coverage. It further distinguishes itself by adding 'Never starts a vault,' which differentiates it from rotation_execute. However, it does not explicitly name sibling alternatives like pool_audit or pool_checks, so it stops short of fully differentiating among all siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies a read-only, safe status tool and explicitly excludes vault-starting behavior via 'Never starts a vault.' This gives a negative usage guideline but does not explicitly state when to use this tool over pool_audit or pool_checks, nor does it mention any alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
May restart the live BP and Mithril. Disabled in SAFE. Requires independent human approval or explicitly enabled EXPERIMENTAL AUTONOMOUS policy. Never signs with a cold key.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (destructiveHint=true, readOnlyHint=false), the description adds critical behavioral context: it may restart systems, requires approval, never signs with a cold key, and is disabled in SAFE. This goes well beyond what annotations alone convey.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences, front-loaded with the core action and immediately followed by the key constraints. No filler, every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers operational constraints and safety policies well, but omits parameter semantics and any indication of success/failure response. For a complex operation with one required parameter, this leaves the agent without enough to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema coverage is 0% and the description does not mention the 'id' parameter at all. With only one parameter, the agent has no guidance on what identifier to provide, which is a significant gap given no supporting schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('restart') and the resources ('live BP and Mithril'), distinguishing it from the status/planning sibling tools. It also adds immediate constraints (disabled in SAFE, approval requirements), making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides explicit conditionals for when the tool can be used (requires human approval or autonomous policy, disabled in SAFE). It implies it is the execution counterpart to rotation_plan, though it doesn't explicitly state 'use after rotation_plan' or 'not for planning/status checks'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Persist an inert rotation plan. No key access, signing or node changes.
| Name | Required | Description | Default |
|---|---|---|---|
| period | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral context beyond annotations: 'No key access, signing or node changes' and 'inert' clarify that while it persists something, it does not perform other rotation actions. This is valuable given that readOnlyHint and destructiveHint are both false.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two tight sentences. The primary action is front-loaded, and the clarification about what it does not do is placed immediately after, with no unnecessary wording.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although the tool has low complexity (one required parameter, no output schema), the description does not explain what 'period' means or what a successful call returns. It also omits behavior on repeated calls (overwrite vs. create), leaving the agent with significant gaps for safe invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must compensate for the 'period' parameter but does not. It does not explain the unit, meaning, or effect of period for an inert rotation plan, leaving the agent to guess.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('Persist') and resource ('inert rotation plan'), and explicitly says it does not perform key access, signing, or node changes. This differentiates it from siblings like rotation_execute and rotation_status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description conveys that this is for saving an inert plan and not for executing changes, which gives clear context. However, it does not explicitly name an alternative like rotation_execute or state when to prefer it over that sibling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read transaction outcome. Use after any timeout; never assume no change.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only and idempotent behavior. The description adds valuable context beyond that: it warns that a timeout does not mean nothing happened and that this tool should be used to resolve ambiguity. This is useful behavioral guidance not present in the schema or annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, no filler. The core purpose is front-loaded, and the usage guidance is stated in a compact, memorable imperative. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only status tool with one parameter, the description covers the core purpose and the critical timing context. It does not describe return values or error behavior, but no output schema exists and the low complexity makes this acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema gives only a generic `id` with a hex pattern and no description. The phrase 'transaction outcome' lets an agent infer that `id` is the transaction identifier, but the description never explicitly connects the parameter to the transaction. This is minimally adequate but not fully compensating for the 0% schema description coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Opens with a concrete verb and resource: 'Read transaction outcome.' This clearly differentiates it from the mutation-oriented rotation_execute and from pool_status, which covers pool state rather than transaction outcome.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
'Use after any timeout; never assume no change' gives explicit timing guidance for when to call this tool. It does not mention alternatives or exclusions, but the context is clear enough for an agent to select it correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0pool_auditpool_checkspool_statusrotation_executerotation_planrotation_statusScored across 6 tools
pool_status, pool_checks, and pool_audit are all read-only but distinguish themselves by focus: live health/versions, readiness gates, and sanitized audit events. The rotation_plan/rotation_status/rotation_execute tools form a clear lifecycle, so an agent can generally select the right tool without confusion.
Tool names consistently use a domain_suffix snake_case pattern, split into pool_ and rotation_ families. The main deviation is rotation_execute being verb-last while the other suffixes are noun-like, but the overall pattern is predictable.
Six tools is a well-scoped set for a specialized Cardano pool operations server. Each tool covers a distinct operational need without redundancy.
The read side covers status, checks, and audit events, while the rotation side covers plan, execute, and status. Minor gaps exist, such as no explicit cancel/abort or plan inspection, but the core operational workflow is covered.
Preflight, approve, and prove consequential agent actions with signed evidence and x402 tools.
Governance runtime for compliance: verified, human-approved writes to a tamper-evident record.
Simulate farms, validate GardenScript and compare policies with Rust. No outbound LLM calls.
Pre-execution governance for AI agents. Deterministic PASS/FAIL/REVIEW verdicts, replayable proof.
