Rohan Shield MCP server lets AI agents submit confidential Midnight Blockchain handshakes and inspect/audit anchored settlement state.
Execute a confidential zero-knowledge state transition (rohan_execute_handshake) with an agent DID, public action summary, optional counterparty, and optional confidential payload canonicalized via RFC 8785 and hashed in RAM.
Read the current anchored ledger state (rohan_get_ledger_state), including state root, block height, and last transaction hash.
List recent settlement transactions and receipts (rohan_get_transaction_history) with a configurable limit.
Verify a plaintext payload against an expected SHA-256 digest (rohan_verify_commitment) using RFC 8785 canonicalization locally at zero gas.
The Sovereign Privacy & Settlement Layer for Autonomous AI Agents on the Midnight Blockchain.
Rohan Protocol equips autonomous AI agents with zero-knowledge intent commitments, confidential state transitions, and a complete, verifiable audit lifecycle. Sensitive parameters (budgets, vendor contracts, PII) are strictly canonicalized (RFC 8785) and hashed in client RAM—never exposed on-chain or leaked in LLM context windows.
Rohan Protocol eliminates the classic "dead-end" MCP agent problem by establishing a complete, multi-turn lifecycle between coordinating agents:
┌───────────────────┐ ┌───────────────────┐ ┌───────────────────┐ ┌───────────────────┐
│ Agent Alpha │ │ Agent Beta │ │ Agent Beta │ │ Agent Beta │
│ (State Mutation) │ │ (State Inspection)│ │ (History Review) │ │ (Agreement Audit) │
└─────────┬─────────┘ └─────────┬─────────┘ └─────────┬─────────┘ └─────────┬─────────┘
│ │ │ │
│ 1. rohan_execute_handshake│ 2. rohan_get_ledger_state│ 3. rohan_get_transaction_history│ 4. rohan_verify_commitment
│ (Confidential Payload)│ (Read Anchored Root) │ (Settlement Receipts) │ (RFC 8785 In-Memory JCS)
▼ ▼ ▼ ▼
┌────────────────────────────────────────────────────────────────────────────────────────┐
│ Rohan Protocol Relayer │
│ Midnight Preprod L1 Settlement & Paymaster │
└────────────────────────────────────────────────────────────────────────────────────────┘Step 1 — Write (rohan_execute_handshake): Agent Alpha commits an intent. The Relayer verifies proof commitments and anchors the state root on Midnight Preprod L1. The legacy rohan_zk_handshake name remains accepted.
Step 2 — Read (rohan_get_ledger_state): Agent Beta inspects the contract's anchored state root, block height, and transaction receipt from cache (0 Gas, <1 ms).
Step 3 — History (rohan_get_transaction_history): Agent Beta lists recorded settlement transactions and receipts (0 Gas).
Step 4 — Verify (rohan_verify_commitment): Agent Beta checks plaintext against its canonical SHA-256 payload digest in local RAM (0 Gas). This is the inner payload digest, not the outer on-chain intentHash.
Related MCP server: mem9-guard-mcp
Tool | Category | Gas Cost | Latency | Description |
| Mutation / Write | Subsidized (Paymaster) | ~30s (L1 Block) | Executes a confidential state transition anchored on Midnight Preprod. The legacy |
| Inspection / Read | 0 Gas | <1 ms (RAM Cache) | Reads current anchored state root, block height, and tx receipt from the 15s write-through cache. |
| Inspection / Read | 0 Gas | <1 ms (SQLite) | Lists recent recorded settlement transactions and receipts. |
| Audit / Verify | 0 Gas | <1 ms (Local RAM) | Checks plaintext against its payload digest via RFC 8785 JCS + SHA-256; supply the inner payload digest, not the outer on-chain |
@rohan-protocol/sdk: Core TypeScript SDK with cryptographic zeroization, RFC 8785 canonicalization, and state inspection client.
@rohan-protocol/mcp: Official Model Context Protocol (MCP) server for Claude Desktop, Cursor, Cline, and Gemini.
@rohan-protocol/webmcp: Browser-native WebMCP shield with zero-width character sanitization (V-07).
npm install @rohan-protocol/sdkimport { RohanClient, canonicalizeJson } from '@rohan-protocol/sdk';
const client = new RohanClient({
contractAddress: '585ac0c4448257507d8ffa2a89e2aa00abd86ec9e94bdb6f553bc83e05f4dd0e',
});
// 1. Inspect on-chain state (Read)
const state = await client.getLedgerState();
console.log('Current Root:', state.currentStateRoot, 'Block:', state.blockHeight);
// 2. Submit a confidential handshake (Write)
const receipt = await client.submitHandshake({
agentId: 'did:midnight:agent-alpha',
intent: 'Vendor Purchase Order #1042',
privateData: { budgetUsd: 75000, approvalCode: 'AUTH-99' },
});
console.log('Confirmed TxHash:', receipt.txHash);
// 3. Verify plaintext commitment locally (Verify)
const audit = await client.verifyCommitment(
{ budgetUsd: 75000, approvalCode: 'AUTH-99' },
receipt.intentHash
);
console.log('Cryptographic match?', audit.valid);RFC 8785 JSON Canonicalization Scheme (JCS): Deterministic, cross-platform key sorting and whitespace elimination.
DoS & ReDoS Guarding: Recursive depth ceiling (max. 32 levels) and RAM payload bounds (max. 256 KB).
Zeroize RAM Sanitation: Sensitive witnesses and private keys are scrubbed from RAM immediately after commitment derivation.
Optimistic Credit Escrow: Atomic balance reservations prevent concurrent quota-drain exploits.
Apache-2.0. Copyright (c) 2026 Rohan Protocol Authors.
Executes a confidential zero-knowledge state transition on Midnight Blockchain. Confidential parameters are automatically canonicalized (RFC 8785) and hashed in client RAM—never exposed on-chain or in model logs.
| Name | Required | Description | Default |
|---|---|---|---|
| intent | No | Legacy fallback for actionSummary | |
| agentId | Yes | Decentralized Identifier (DID) of the initiating agent | |
| actionSummary | No | Public high-level action label (e.g. 'Vendor Agreement Execution', 'Database Audit Anchor') | |
| counterpartyId | No | Optional counterparty agent identifier | |
| confidentialPayload | No | OPTIONAL confidential parameters (budgets, deals, PII). Automatically canonicalized via RFC 8785 and hashed in local memory. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations supplied, the description carries the full behavioral burden. It usefully discloses that confidential parameters are canonicalized via RFC 8785 and hashed in client RAM, never exposed on-chain or in model logs, which is meaningful privacy context. However, it does not describe authorization requirements, irreversibility or side effects of the state transition, error behavior, or what a successful execution returns.
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 concise sentences with the purpose front-loaded and the confidentiality behavior immediately following. Every sentence adds value, and there is 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?
For a state-transition tool with no annotations and no output schema, the description covers the privacy mechanism well but leaves out operational details such as permissions, failure modes, and what happens after execution. It is adequate but incomplete for an agent deciding whether and how to invoke a confidential write operation.
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?
Schema description coverage is 100%, so the input schema already documents all five parameters, including agentId, actionSummary, counterpartyId, and confidentialPayload. The description reinforces the confidentialPayload handling but does not add parameter-level meaning beyond the schema, such as clarifying the legacy intent fallback or expected actionSummary formats. Baseline 3 is appropriate.
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 states a specific verb and resource: executing a confidential zero-knowledge state transition on Midnight Blockchain. It is clear enough to distinguish a write/execute operation from read-oriented siblings like rohan_get_ledger_state, but it does not explicitly differentiate itself from rohan_verify_commitment or explain what _handshake_ means.
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 explains what the tool does but gives no explicit when-to-use guidance, no when-not-to-use conditions, and no named alternatives among the sibling tools. An agent must infer that this is for submitting confidential state transitions rather than reading or verifying existing state.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Reads the current anchored state of the Rohan Protocol smart contract on Midnight Preprod L1. Returns the state root, block height, and last mined transaction hash from memory cache.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full burden; it does usefully disclose that data comes "from memory cache" and enumerates the returned fields (state root, block height, last mined tx hash). However, it never addresses cache staleness, L1 confirmation semantics, or failure behavior, which matter for a state-read tool.
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, zero filler, with the resource and chain scope front-loaded before the return-value detail. Every clause 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?
With no output schema, the description usefully names the return fields, and for a zero-param read it covers what an agent needs to invoke it. The only gap is the absence of any note on cache freshness or refresh behavior.
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 takes zero parameters, so the baseline is 4; nothing in the schema needs elaboration and the description correctly implies no inputs are required.
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?
States a specific verb ("Reads") and a precisely scoped resource (the current anchored state of the Rohan Protocol contract on Midnight Preprod L1), which is enough to separate it from a handshake or commitment-verification call. It does not explicitly name its siblings, so it stops short of a 5.
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 read-only framing implies when the tool is appropriate (fetching current on-chain state), but there is no explicit when-to-use, when-not-to-use, or routing to rohan_zk_handshake / rohan_verify_commitment. Usage must be inferred from the purpose statement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lists historical settlement transactions and receipts anchored on Midnight Preprod L1.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of historical transactions to return (default: 10, max: 50). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It establishes that this is a historical listing operation scoped to Midnight Preprod L1, but it omits permissions, ordering, pagination behavior, and whether receipts are returned inline or separately.
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 definition is a single front-loaded sentence with no filler. It states the core action and scope immediately.
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 one-parameter listing tool this covers the essential purpose and network scope. However, with no output schema and only a generic mention of transactions and receipts, it leaves the return shape and retrieval constraints underspecified.
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 fully documents the single limit parameter, including default and maximum. The description adds no parameter-level meaning beyond the schema, so the baseline 3 is appropriate.
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 uses a specific verb and resource: "Lists historical settlement transactions and receipts." It also scopes the data to "Midnight Preprod L1," which helps distinguish it from ledger-state or commitment-verification siblings, though it does not name those alternatives directly.
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 implies usage through "historical" but gives no explicit when-to-use guidance, prerequisites, or comparison to sibling tools like rohan_get_ledger_state. An agent must infer the selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Verifies a plaintext confidential payload against its SHA-256 digest using RFC 8785 JSON Canonicalization. Supply the inner payload digest, not the outer on-chain intentHash. Zero gas cost; runs in local memory.
| Name | Required | Description | Default |
|---|---|---|---|
| payload | Yes | The plaintext contract, agreement, or intent data to be verified. | |
| expectedDigest | Yes | The expected SHA-256 digest of the canonicalized confidential payload (the inner payload digest referenced as digest: sha256:<hash> in actionSummary), not the outer timestamp-salted on-chain intentHash. Accepts raw hex, 0x, or sha256: prefixes. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations supplied, the description carries the full burden and does disclose two meaningful traits: zero gas cost and execution in local memory, telling the agent this is an off-chain, non-mutating computation. It omits what happens on digest mismatch (returned boolean vs. thrown error) and what the response looks like, which is the remaining behavioral gap.
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 short sentences, front-loaded with the action and the canonicalization method, followed by the critical digest disambiguation and then the cost/locality traits. Every sentence contributes and nothing is repeated.
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 two-parameter, fully-described, non-mutating verification tool the description covers the key pitfalls (digest choice, off-chain cost) well. However, no output schema exists, and the description never states the return value or mismatch behavior, leaving the agent guessing how to interpret the result.
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?
Schema description coverage is 100%, so both parameters are already documented, including the same inner-vs-outer digest warning and the accepted hash prefixes. The description reinforces that distinction but adds no new syntax, format, or constraint information beyond what the schema already states, so the baseline 3 applies.
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?
States a specific verb and resource: verifying a plaintext confidential payload against its SHA-256 digest, with the canonicalization standard named (RFC 8785). That is far more specific than the sibling tools (handshake, transaction history, ledger state), though it never explicitly names or contrasts a sibling, so it falls short of a 5.
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?
Gives an explicit input-level exclusion: supply the inner payload digest, not the outer on-chain intentHash. This is real routing guidance for the most error-prone choice an agent faces here. It does not say when to call this versus other verification or lookup paths, so it stops short of naming alternatives.
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.7.1rohan_execute_handshakerohan_get_transaction_historyrohan_verify_commitment1 field changedInput schema / properties / expectedDigest / descriptionPrevious value: -"The 64-character hexadecimal SHA-256 intent commitment (accepts raw hex, 0x, or sha256: prefixes)."New value: +"The expected SHA-256 digest of the canonicalized confidential payload (the inner payload digest referenced as digest: sha256:<hash> in actionSummary), not the outer timestamp-salted on-chain intentHash. Accepts raw hex, 0x, or sha256: prefixes."rohan_zk_handshakev0.7.0rohan_get_ledger_staterohan_verify_commitmentrohan_zk_handshake6 fields changedInput schema / properties / actionSummaryAdded value: +{
+ "description": "Public high-level action label (e.g. 'Vendor Agreement Execution', 'Database Audit Anchor')",
+ "type": "string"
+}Input schema / properties / agentId / descriptionPrevious value: -"Decentralized Identifier (DID) or identifier of the initiating agent"New value: +"Decentralized Identifier (DID) of the initiating agent"Input schema / properties / confidentialPayloadAdded value: +{
+ "description": "OPTIONAL confidential parameters (budgets, deals, PII). Automatically canonicalized via RFC 8785 and hashed in local memory.",
+ "type": "object"
+}Input schema / properties / counterpartyId / descriptionPrevious value: -"Optional identifier of counterparty agent"New value: +"Optional counterparty agent identifier"Input schema / properties / intent / descriptionPrevious value: -"Semantic action plan, payload, or agreement terms to be cryptographically committed"New value: +"Legacy fallback for actionSummary"Input schema / requiredPrevious value: -[
- "agentId",
- "intent"
-]New value: +[
+ "agentId"
+]v0.1.0rohan_zk_handshakeScored across 4 tools
Each tool maps to a clearly distinct action/resource: executing a confidential state transition, verifying a commitment digest, reading the current ledger state, and listing transaction history. The boundary between reading ledger state and listing transaction history is clear from the descriptions.
All tools use the same rohan_ prefix followed by a consistent verb_noun pattern (execute_handshake, get_transaction_history, verify_commitment, get_ledger_state). The convention is predictable throughout.
Four tools is well-scoped for a focused blockchain protocol server, and each tool has a clear, non-redundant role. There is no padding or extreme thinness given the domain.
The surface covers core operations: execute, verify, read state, and list history. Minor gaps exist, such as direct transaction/receipt lookup by hash or richer protocol query operations, but agents can likely work around them via history and state reads.
Real-time MCP & A2A prompt-injection, jailbreak, and tool-schema poisoning firewall for AI agents.
Zero-secret MCP gateway for AI agents: risk-scored, audited calls with human-in-the-loop approval.
MCP server for your apps' tools and custom tools, plus hosted AI agents and approval-gated workflows
Security firewall for AI agents — scans MCP calls for injection, secrets, and risks.