This server exposes a single MCP tool for submitting confidential zero-knowledge intent commitments to Midnight Blockchain.
Execute rohan_zk_handshake to cryptographically commit an intent, transaction, or inter-agent agreement without exposing confidential parameters.
Provide the initiating agent's DID/identifier via required agentId and the semantic action plan, payload, or agreement terms via required intent.
Optionally identify a counterparty agent via counterpartyId.
Note: the provided schema only declares rohan_zk_handshake; the README's read and verify tools are not present in this server schema.
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 │
│ (State Mutation) │ │ (State Inspection) │ │ (Agreement Audit) │
└──────────┬───────────┘ └──────────┬───────────┘ └──────────┬───────────┘
│ │ │
│ 1. rohan_zk_handshake │ 2. rohan_get_ledger_state│ 3. rohan_verify_commitment
│ (Confidential Payload)│ (Read Anchored Root) │ (RFC 8785 In-Memory JCS)
▼ ▼ ▼
┌────────────────────────────────────────────────────────────────────────────────────────┐
│ Rohan Protocol Relayer │
│ Midnight Preprod L1 Settlement & Paymaster │
└────────────────────────────────────────────────────────────────────────────────────────┘Step 1 — Write (rohan_zk_handshake): Agent Alpha commits an intent. The Relayer verifies proof commitments and anchors the state root on Midnight Preprod L1.
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 — Verify (rohan_verify_commitment): Agent Beta mathematically audits received plaintext against the on-chain commitment in local RAM (0 Gas, 0 ms).
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. |
| Audit / Verify | 0 Gas | <1 ms (Local RAM) | Cryptographically audits plaintext against on-chain commitments via RFC 8785 JCS + SHA-256. |
| Inspection / Read | 0 Gas | <1 ms (RAM Cache) | Reads current anchored state root, block height, and tx receipt from the 15s write-through cache. |
@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.
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.
Cryptographically audits and verifies whether a plaintext payload matches an on-chain commitment using RFC 8785 JSON Canonicalization and SHA-256. Zero gas cost, executes instantly in local RAM.
| Name | Required | Description | Default |
|---|---|---|---|
| payload | Yes | The plaintext contract, agreement, or intent data to be verified. | |
| expectedDigest | Yes | The 64-character hexadecimal SHA-256 intent commitment (accepts raw hex, 0x, or sha256: prefixes). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral burden. It usefully discloses the cryptographic method (RFC 8785 JSON Canonicalization and SHA-256), zero gas cost, and local RAM execution, but it does not describe what happens on mismatch, whether the operation is read-only, or what the verification result looks like.
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 with no wasted wording. The core verification purpose is front-loaded, followed by relevant execution characteristics.
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 is adequate for a two-parameter verification tool with fully documented parameters, and it adds methodological context. However, with no output schema and no annotations, it should do more to explain the return behavior, mismatch handling, and any preconditions for verification.
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 in the input schema. The description adds useful context by naming the canonicalization and hashing method, but it does not add parameter-level semantics beyond what the schema already provides.
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 ('audits and verifies') and resource ('plaintext payload matches an on-chain commitment'), and it names the cryptographic mechanism used. It is clear what the tool does, though it does not explicitly differentiate itself from the sibling tools rohan_zk_handshake and rohan_get_ledger_state.
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 that the tool is zero-gas and runs locally in RAM, which hints at when it may be preferable to an on-chain operation. However, it gives no explicit when-to-use guidance, no exclusions, and does not mention the sibling tools or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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, the description does useful work by disclosing that confidential payloads are RFC 8785-canonicalized and hashed in client RAM and never exposed on-chain or in model logs. However, it never states that this is a mutating, likely irreversible on-chain state transition, nor what authorization or failure behavior applies — significant omissions for a write tool with zero annotation coverage.
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 sentences, front-loaded with the operation and its domain, followed by the most decision-relevant behavioral fact (no leakage of confidential data). No filler or restated field names.
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 high-complexity ZK state-transition tool with no annotations and no output schema, the description covers the privacy model but leaves out return values, authorization requirements, and the consequences/irreversibility of the state transition. It is adequate on the confidentiality dimension but incomplete for an agent to invoke correctly with confidence.
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 all five parameters including the confidentialPayload object are already documented, establishing a baseline of 3. The description only reinforces the confidentialPayload handling and adds nothing about the required agentId, the actionSummary/intent legacy relationship, or counterpartyId semantics beyond what the schema says.
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 — 'Executes a confidential zero-knowledge state transition on Midnight Blockchain' — which is clearly distinct from the sibling tools rohan_verify_commitment and rohan_get_ledger_state. It stops short of naming those siblings to explicitly differentiate, but the resource is 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?
There is no statement of when to call this tool versus rohan_verify_commitment or rohan_get_ledger_state, and no prerequisites (DID auth, registration, commitment preconditions) are given. The only implied guidance is that confidential parameters are handled automatically, which is a behavior note rather than a usage rule.
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.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 3 tools
The three tools target distinct operations: executing a ZK state transition, verifying a commitment match, and reading anchored ledger state. However, verify_commitment and get_ledger_state both involve reading on-chain data, so an agent may occasionally pause between them for a read-only audit versus a state read.
All tools share a consistent rohan_ prefix, and two follow a verb_noun pattern (verify_commitment, get_ledger_state). rohan_zk_handshake is a noun phrase that deviates slightly from that pattern, but it is still readable and thematically clear.
Three tools is on the thin side for a protocol server; each tool has a clear place, but the surface feels minimal and leaves little room for common lifecycle operations. It is borderline rather than clearly well-scoped.
The surface covers a write path (handshake), verification, and state reading, but notable gaps remain: no operations for creating/issuing commitments, listing historical proofs or transactions, managing keys, or updating protocol state. Agents can perform the core confidential-transition flow but will hit dead ends for broader lifecycle tasks.
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.