How do I use AgentLedger?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@AgentLedger log my current reasoning trace" 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.

AgentLedger

by Benita2001

Overview Schema Source Related Servers Discussions Admin

TypeScript

Remote

AgentLedger

Your agent thinks. We store the proof.

AgentLedger is an MCP server that captures AI agent reasoning traces and stores them permanently on 0G Storage — decentralized, immutable, and verifiable. Every decision an agent makes gets a cryptographic root hash receipt. Decisions are chained — each one references the previous root hash so history cannot be rewritten without detection.

The entire system runs on 0G. Reasoning traces go to 0G Storage. The agent decision index lives in 0G KV Store. Zero local state. Nothing on your server.

Built for the 0G Zero Cup Hackathon.

TL;DR for Judges
What
Detail
What it is
MCP server plug into any AI agent in one config block
What it does
Captures every reasoning step an agent takes, stores it permanently on 0G Storage
0G usage
0G Storage (traces) + 0G KV Store (index) zero local state
Chain integrity
Each decision chains to the previous root hash tampering is mathematically detectable
Install
npm install -g @0xbeni/agentledger-mcp
No wallet needed
AgentLedger uses sponsored storage — we absorb all 0G gas costs
Live proof
3 real transactions on 0G Galileo testnet — see below
npm
@0xbeni/agentledger-mcp
Related MCP server: QuantaOptima
The Problem
AI agents are making increasingly consequential decisions financial, medical, legal, operational. But their reasoning is invisible and ephemeral. The moment a decision is made, the thinking behind it disappears forever.
When an AI trading agent says "I called BTC going up three weeks ago" — you cannot verify that. When an AI medical agent recommends a treatment there is no audit trail. When an AI legal agent drafts a contract clause nobody can prove what reasoning it used.
There is no accountability layer for AI decision-making. AgentLedger builds it.
The Solution
AgentLedger intercepts every agent decision and:
Captures the full reasoning chain every thought step, every tool called, every conclusion
Encodes it as structured JSON and uploads to 0G Storage via MemData returns a root hash as cryptographic proof
Chains each decision to the previous one via prev_decision_hash — tampering with any entry breaks the chain
Updates the agent's decision index in 0G KV Store — the complete ledger lives on-chain, nothing local
Any agent or human can then:
Retrieve any specific decision by root hash
Verify a decision hasn't been tampered with
Audit an agent's full decision history
Run chain integrity check — returns INTACT or BROKEN
Who Can Use AgentLedger
AgentLedger is infrastructure. Any AI agent that makes decisions benefits from an immutable, verifiable audit trail.
🤖 AI Trading Agents
Trading agents claim alpha. AgentLedger makes those claims verifiable. Every signal an agent generates the market data it analyzed, the reasoning it used, the confidence level, the final call gets stored on 0G with a timestamp and root hash. You can prove the agent made that call before the market moved. No cherry-picking, no revisionism.
Example: A trading agent logs every BUY, SELL, and HOLD decision to AgentLedger. A month later, the full reasoning chain for every decision is retrievable — timestamped and tamper-proof on 0G.
⚖️ Trading Signal Judges & Evaluators
Signal providers in crypto claim incredible track records. With AgentLedger, evaluators can audit any agent's full decision history on-chain. Every call is timestamped, every reasoning trace is verifiable. Run audit_agent and get cryptographic proof of whether the chain is INTACT or BROKEN.
Example: A fund evaluating an AI signal provider runs audit_agent on their AgentLedger history. The chain comes back INTACT 847 decisions, unbroken, fully auditable back to day one.
🏥 Medical AI Agents
Medical AI agents are making treatment recommendations, flagging drug interactions and prioritizing diagnoses. Regulators and hospitals need to audit these decisions. AgentLedger gives every medical agent decision a permanent, immutable reasoning trace what data it analyzed, what it considered, what it recommended, and why.
Example: An AI triage agent logs every patient prioritization decision to AgentLedger. When a decision is questioned, the full reasoning trace is retrieved by root hash immutable, timestamped, exactly as it was at the moment of decision.
📜 Legal AI Agents
Legal AI agents draft contracts, interpret clauses, and provide legal analysis. When a contract dispute arises, the question "what was the AI thinking when it drafted this?" needs an answer. AgentLedger stores every legal agent decision permanently so the reasoning is always retrievable.
Example: An AI contract drafting agent logs its clause selection reasoning to AgentLedger. In a dispute, the law firm retrieves the exact reasoning trace which precedents it considered, what risk factors it weighed, why it chose specific language.
⚙️ Autonomous Operations Agents
Agents running infrastructure, managing deployments, or making operational decisions at scale need accountability. When something goes wrong, you need to know exactly what the agent decided and why. AgentLedger gives every autonomous operations agent a tamper-proof decision log that cannot be altered after the fact.
Example: An AI DevOps agent logs every deployment decision to AgentLedger. When a deployment causes an outage, the full chain of decisions leading up to it is retrievable exactly what the agent was thinking at each step, in order, verified intact.
Live Proof — Real 0G Transactions
These transactions are live on the 0G Galileo testnet right now. Click to verify on StorageScan.
Decision
Action
Root Hash
Chain Position
StorageScan
1
BUY
0x98e57f97e94af6dd3fcb543b373cf464e5343c0bab916020a5ab54df4e50f8cf
#1 (prev: null)
View ↗
2
HEDGE
0xdfdf71328b2b52166494653a67e8bf68119b24642bb39204fd826cf9de02d20b
#2 (prev: 0x98e5...)
View ↗
3
HOLD
0xdc4ad86fd6055e953a7782b7014f2d83a9b66ccaa4bb0cea3342d6deee5a6d0b
#3 (prev: 0xdfdf...)
View ↗
Chain integrity: ✓ INTACT
How 0G Is Used
Component
How AgentLedger Uses It
0G Storage
Every reasoning trace uploaded as JSON via MemData. Returns root hash — permanent, content-addressed proof on the decentralized network
0G KV Store
Agent decision index stored on-chain. Key = agent_id, Value = array of StoredEntry objects with root hashes. Updated on every new decision
0G Galileo Testnet
Chain ID 16602. All transactions verifiable on StorageScan
Sponsored storage
AgentLedger holds the sponsored wallet — users pay zero gas, need zero wallet setup
Local state
None. Zero. Everything is on 0G
Chain Integrity — How Tamper Detection Works
Every reasoning trace includes a proof block:
{
  "proof": {
    "prev_decision_hash": "0x98e57f97e94af6dd3fcb543b373cf464e5343c0bab916020a5ab54df4e50f8cf",
    "chain_length": 2
  }
}
Each decision points to the previous one's root hash. This creates a chain:
Decision 1: root=0xAAA  prev=null
Decision 2: root=0xBBB  prev=0xAAA  ✓
Decision 3: root=0xCCC  prev=0xBBB  ✓
If anyone attempts to delete or modify Decision 2:
Decision 1: root=0xAAA  prev=null
Decision 3: root=0xCCC  prev=0xBBB  ✗ — 0xBBB no longer exists
audit_agent detects this instantly and returns BROKEN at position 2.
MCP Tools
Tool
Description
Returns
log_reasoning
Store a full agent reasoning trace on 0G Storage
root_hash, tx_hash, storagescan_url, chain_position
get_reasoning
Retrieve any reasoning trace by root hash
Full ReasoningTrace object
verify_reasoning
Cryptographically verify a trace is unchanged on 0G
{ verified: boolean, message }
get_agent_history
Full decision history for any agent from 0G KV
All StoredEntry objects + chain summary
audit_agent
Download and verify the complete decision chain
INTACT or BROKEN + position of break
Installation
No wallet needed. No testnet tokens. Just install and go.
AgentLedger uses sponsored storage all 0G gas costs are covered. You only need an AGENT_ID to identify your agent.
Option 1 — Global install (recommended)
npm install -g @0xbeni/agentledger-mcp
Step 1 — Find your Claude Desktop config file:
OS
Config file location
Mac
~/Library/Application Support/Claude/claude_desktop_config.json
Windows
%APPDATA%\Claude\claude_desktop_config.json
Step 2 — Add the AgentLedger block:
If the file is empty or new, paste this entire config:
{
  "mcpServers": {
    "agentledger": {
      "command": "agentledger-mcp",
      "env": {
        "AGENT_ID": "my-agent"
      }
    }
  }
}
If the file already has other MCP servers, add only the "agentledger" block inside the existing "mcpServers" object:
{
  "mcpServers": {
    "your-existing-server": { ... },
    "agentledger": {
      "command": "agentledger-mcp",
      "env": {
        "AGENT_ID": "my-agent"
      }
    }
  }
}
Step 3 — Replace AGENT_ID:
Set AGENT_ID to any name for your agent e.g. "my-trading-agent", "specter-v1", "legal-agent"
Step 4 — Restart Claude Desktop
Fully quit and reopen Claude Desktop. AgentLedger tools are now available.
Step 5 — Test it
In Claude Desktop, type:
Log my reasoning: I analyzed BTC price trends and the volume confirmed an uptrend. I decided to BUY with 0.78 confidence.
Claude will call log_reasoning, upload your reasoning to 0G Storage, and return a root hash + StorageScan URL as proof.
Option 2 — Clone and run locally (for developers)
# 1. Clone the repo
git clone https://github.com/Benita2001/Agentledger
cd agentledger

# 2. Install dependencies
npm install

# 3. Run the demo to verify everything works
npm run demo
The demo uploads 3 real decisions to 0G Storage and prints root hashes + StorageScan URLs.
Then add to your Claude Desktop config:
{
  "mcpServers": {
    "agentledger": {
      "command": "npx",
      "args": ["tsx", "/absolute/path/to/agentledger/src/index.ts"],
      "env": {
        "AGENT_ID": "my-agent"
      }
    }
  }
}
Replace /absolute/path/to/agentledger with the actual path where you cloned the repo.
Run the Demo
npm run demo
This runs 3 chained trading decisions through AgentLedger end to end:
=== Decision 1: BUY ===
rootHash: 0x98e57f97e94af6dd3f...
StorageScan: https://storagescan-galileo.0g.ai/tx/0xbce441...

=== Decision 2: HEDGE ===
rootHash: 0xdfdf71328b2b5216...
StorageScan: https://storagescan-galileo.0g.ai/tx/0x5ff29f...

=== Decision 3: HOLD ===
rootHash: 0xdc4ad86fd6055e95...
StorageScan: https://storagescan-galileo.0g.ai/tx/0x00e147...

Chain integrity: ✓ INTACT
Every root hash is verifiable on StorageScan.
Project Structure
agentledger/
├── src/
│   ├── index.ts      # MCP server — 5 tools via FastMCP
│   ├── storage.ts    # 0G Storage upload/download via MemData
│   ├── kv.ts         # 0G KV Store — agent index management
│   ├── chain.ts      # Decision chaining + tamper detection
│   └── types.ts      # TypeScript interfaces
├── demo/
│   └── agent-demo.ts # End-to-end demo — 3 real 0G transactions
├── website/          # Landing page
├── mcp-config.json   # Ready-to-use MCP config
└── .env.example      # Environment template
Architecture
AI Agent (Claude, GPT, any MCP client)
       ↓ calls MCP tool
AgentLedger MCP Server (FastMCP / stdio)
       ↓ buildTrace() — links to prev_decision_hash
       ↓ uploadTrace() — 0G Storage via MemData → root hash
       ↓ updateAgentIndex() — 0G KV Store → agent ledger updated
       ↓ returns root hash + StorageScan URL
0G Decentralized Network
  ├── 0G Storage — reasoning trace stored across 4+ nodes worldwide
  └── 0G KV Store — agent index, fully on-chain
Sponsored Wallet (AgentLedger)
  └── pays all gas fees — users need zero wallet setup
Roadmap
Version
Feature
Status
v1.0.1
MCP server, 5 tools, 0G Storage + KV, chain integrity, npm package
✅ Live
v1.1
Sponsored storage no wallet needed, AgentLedger absorbs all gas costs
🔄 In progress
v1.2
Agent reputation leaderboard public rankings by chain length and integrity score
🗓 Planned
v1.3
Multi-chain support store on 0G, verify on any EVM chain
🗓 Planned
Built With
0G Storage SDK
FastMCP
TypeScript / Node.js 18+
ethers.js
zod
Network
Parameter
Value
Network
0G Galileo Testnet
Chain ID
16602
RPC
https://evmrpc-testnet.0g.ai
Indexer
https://indexer-storage-testnet-turbo.0g.ai
Explorer
https://storagescan-galileo.0g.ai
Faucet
https://faucet.0g.ai
Built for the 0G Zero Cup Hackathon · @0xbeni

Available Tools

5 tools

audit_agentB

Audit an agent's complete reasoning chain. Downloads every decision and verifies the chain has not been tampered with. Returns INTACT or BROKEN with details.

ParametersJSON Schema

Name	Required	Description	Default
`agent_id`	No

TDQS

B3.1/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Without annotations, the description must reveal behavioral traits. It mentions downloading decisions and verifying integrity, but omits side effects, resource usage, authentication needs, or whether the download is stored. For a tool with no annotations, this is moderate disclosure.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences are concise and front-loaded with the main action. However, details about output format are embedded rather than structured, and no parameter info is included.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers the core function and return values but lacks prerequisites (e.g., agent existence, required scopes), error handling, and details on the 'details' response. For a tool with no output schema, more would be expected.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0% and the description does not mention the 'agent_id' parameter at all. The parameter's purpose, format, or source is unexplained, leaving the agent to infer from the name alone.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it audits an agent's complete reasoning chain, downloads decisions, verifies tampering, and returns INTACT or BROKEN. This distinguishes it from sibling tools like get_reasoning or verify_reasoning by specifying the full chain download and integrity check.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives like verify_reasoning or get_agent_history. The description lacks when-not-to-use context or prerequisite conditions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_agent_historyC

Get the full reasoning history for an agent — all decisions they have ever logged to AgentLedger

ParametersJSON Schema

Name	Required	Description	Default
`agent_id`	No

TDQS

C2.7/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must carry the full burden. It only states that it gets the 'full reasoning history', but lacks disclosure about rate limits, access permissions, pagination behavior, or any side effects. The claim of 'all decisions' implies completeness but no confirmation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence that front-loads the core purpose. Every word adds value, with no extraneous content. It is efficient and easy to parse.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has no output schema, no annotations, and only one parameter, the description is minimal. It does not explain what the return value looks like, whether there is pagination, or any special behavior. The optional nature of the parameter is not addressed.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0% and the description adds no information about the single parameter 'agent_id'. It does not specify whether it is required (listed as 0 required), expected format, or any constraints. The description fails to compensate for the lack of schema documentation.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'Get' and the resource 'full reasoning history for an agent'. It specifies that it includes 'all decisions they have ever logged to AgentLedger', which defines scope. However, it does not distinguish from sibling tools like 'get_reasoning' or 'audit_agent', which likely have similar purposes.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool vs alternatives such as 'log_reasoning', 'get_reasoning', 'verify_reasoning', or 'audit_agent'. There is no mention of prerequisites, limitations, or contextual use cases.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_reasoningA

Retrieve a specific reasoning trace from 0G Storage using its root hash

ParametersJSON Schema

Name	Required	Description	Default
`root_hash`	Yes	The root hash returned when the trace was logged

TDQS

A3.6/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided; description only states retrieval action without disclosing read-only nature, error behavior, or access requirements.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence with no fluff, directly conveys purpose and mechanism.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers core functionality but lacks output structure or error scenarios; adequate for simple retrieval with one parameter.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage 100% with parameter description already explaining root_hash's origin. Description adds no new semantic value beyond schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states verb 'Retrieve', resource 'reasoning trace', and method 'using its root hash'. Distinguishes from siblings: log_reasoning (logging), verify_reasoning (verification), get_agent_history (history), audit_agent (audit).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Implies usage when root hash is known, but no explicit when-to-use, when-not-to-use, or comparison with siblings.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

log_reasoningA

Log an AI agent reasoning trace permanently to 0G Storage. Every decision step is stored immutably with a root hash receipt. Decisions are chained so history cannot be tampered with.

ParametersJSON Schema

Name	Required	Description
`input`	Yes	The question or task the agent was given
`action`	Yes	The final decision or action taken
`agent_id`	No	Agent identifier. Defaults to env AGENT_ID
`metadata`	No	Any extra context
`confidence`	Yes	Confidence score 0-1
`reasoning_steps`	Yes	The agent's step by step reasoning
`reasoning_summary`	Yes	One sentence summary of why this decision was made

TDQS

A3.7/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively communicates key traits: permanent storage, immutability, chaining of decisions, and a root hash receipt. These details help the agent understand the irreversible and security-sensitive nature of the action.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two concise sentences with no filler. The main purpose is front-loaded, and every sentence adds value. The description is well-structured for quick comprehension.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (7 parameters, nested objects) and no output schema, the description does not explain the return value or output format. It mentions a 'root hash receipt' but lacks specifics about what the agent can expect as a response. The description is complete for understanding the action but incomplete for anticipating the tool's output.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3. The description does not add parameter-specific meaning beyond the schema; it provides general context about the overall operation but not how each parameter affects behavior.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'log', the resource 'AI agent reasoning trace', and the storage destination '0G Storage'. It distinguishes itself from sibling tools (get, verify, history, audit) by focusing on writing/recording, not reading or verification.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit guidance on when to use this tool versus alternatives. Sibling tools exist but are not mentioned. The description implies usage for logging reasoning, but does not specify when not to use it or compare with other tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

verify_reasoningA

Verify a reasoning trace exists unchanged on 0G Storage. Returns true if the data is intact, false if tampered or missing.

ParametersJSON Schema

Name	Required	Description	Default
`root_hash`	Yes

TDQS

A3.8/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description carries full burden. It clearly states the tool is a read-only check, returns a boolean, and doesn't modify state. Minor gap: no mention of error handling or performance.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence, front-loaded with the primary action, no unnecessary words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 1 parameter, no output schema, and no annotations, the description is adequate for a simple verification tool. However, it lacks parameter explanation and does not integrate with sibling tools context.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0% and the description does not explain the root_hash parameter. It assumes the agent knows what a root hash is and where to get it, adding minimal semantic value beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states the verb (verify), resource (reasoning trace), and purpose (check existence and integrity). It distinguishes from siblings like log_reasoning (write), get_reasoning (read), and audit_agent (audit).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied from the purpose, but there is no explicit guidance on when to use this tool over alternatives or when not to use it. No exclusions or references to sibling tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

5 tool updatesv1.0.1Jul 30, 2026
- First observedaudit_agent
- First observedget_agent_history
- First observedget_reasoning
- First observedlog_reasoning
- First observedverify_reasoning

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A3.6/5.0

Scored 2026-07-30 05:30 across 5 tools

Disambiguation5/5

Each tool has a clearly distinct purpose: logging, retrieving, verifying, listing history, and auditing. No overlap or ambiguity.

Naming Consistency5/5

All names use a consistent verb_noun pattern in snake_case (e.g., log_reasoning, get_reasoning, verify_reasoning). Even get_agent_history and audit_agent fit the pattern with different nouns.

Tool Count5/5

Five tools are appropriate for the focused domain of immutable reasoning logging. Each tool earns its place without unnecessary bloat or deficiency.

Completeness4/5

Core operations (create, read, list, verify, audit) are covered. Missing a way to discover agent IDs, but the immutable nature justifies no delete/update. Minor gap in agent discovery.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

Need Help?

Related Servers

Related MCP Connectors

Proofable MCPOAuth
io.github.proofable
Hosted MCP server for AI agent identity, permissions, verification, and reusable proof.
Security Agent Orchestration Autonomous Agents
1
Synapse Layer — Trust Infrastructure for AI Agents B
io.github.SynapseLayer
MCP-native Trust Infrastructure for AI Agents. Persistent encrypted memory with Trust Quotient.
Knowledge & Memory Autonomous Agents Security
13313
mcp-agentcore A
com.geiant
AI governance MCP server for EU AI Act compliance and jurisdiction verification
Legal & Compliance AI & Machine Learning Government Data
32
mcp A
com.everstake
MCP server connecting AI agents to non-custodial staking data across 130+ networks.
Blockchain Cryptocurrency
1111

Related MCP Servers

mcp-witness
Security Legal & Compliance
edwiniac
A
license
Not graded
quality
D
maintenance
Cryptographic proof of every AI decision. An immutable, verifiable audit trail MCP server.
Updated 2 months ago (2026-07-03 02:24 UTC)
1
MIT
QuantaOptima
Security AI & Machine Learning
jdhart81
A
license
A
quality
B
maintenance
MCP server that provides cryptographic audit trails for AI agent actions, making every action tamper-evident via HMAC-SHA256 signed hash chains.
Updated 2 days ago (2026-09-12 23:20 UTC)
10
Apache 2.0
agent-audit-trail
Security Legal & Compliance
dtjohnson83
A
license
Not graded
quality
C
maintenance
MCP server providing immutable audit logging, policy enforcement, and compliance reporting for AI agent workflows, enabling regulatory compliance and chain integrity verification.
Updated 19 days ago (2026-08-26 22:28 UTC)
MIT
a2a-trustgate
Security Autonomous Agents
jyswee
A
license
Not graded
quality
D
maintenance
MCP server for AI agent compliance that screens actions before execution and records decisions in an immutable, SIEM-ready audit trail.
Updated a month ago (2026-08-08 08:05 UTC)
54 npm
-

What	Detail
What it is	MCP server plug into any AI agent in one config block
What it does	Captures every reasoning step an agent takes, stores it permanently on 0G Storage
0G usage	0G Storage (traces) + 0G KV Store (index) zero local state
Chain integrity	Each decision chains to the previous root hash tampering is mathematically detectable
Install	`npm install -g @0xbeni/agentledger-mcp`
No wallet needed	AgentLedger uses sponsored storage — we absorb all 0G gas costs
Live proof	3 real transactions on 0G Galileo testnet — see below
npm	@0xbeni/agentledger-mcp

Decision	Action	Root Hash	Chain Position	StorageScan
1	BUY	`0x98e57f97e94af6dd3fcb543b373cf464e5343c0bab916020a5ab54df4e50f8cf`	#1 (prev: null)	View ↗
2	HEDGE	`0xdfdf71328b2b52166494653a67e8bf68119b24642bb39204fd826cf9de02d20b`	#2 (prev: 0x98e5...)	View ↗
3	HOLD	`0xdc4ad86fd6055e953a7782b7014f2d83a9b66ccaa4bb0cea3342d6deee5a6d0b`	#3 (prev: 0xdfdf...)	View ↗

Component	How AgentLedger Uses It
0G Storage	Every reasoning trace uploaded as JSON via `MemData`. Returns root hash — permanent, content-addressed proof on the decentralized network
0G KV Store	Agent decision index stored on-chain. Key = `agent_id`, Value = array of `StoredEntry` objects with root hashes. Updated on every new decision
0G Galileo Testnet	Chain ID 16602. All transactions verifiable on StorageScan
Sponsored storage	AgentLedger holds the sponsored wallet — users pay zero gas, need zero wallet setup
Local state	None. Zero. Everything is on 0G

Tool	Description	Returns
`log_reasoning`	Store a full agent reasoning trace on 0G Storage	`root_hash`, `tx_hash`, `storagescan_url`, `chain_position`
`get_reasoning`	Retrieve any reasoning trace by root hash	Full `ReasoningTrace` object
`verify_reasoning`	Cryptographically verify a trace is unchanged on 0G	`{ verified: boolean, message }`
`get_agent_history`	Full decision history for any agent from 0G KV	All `StoredEntry` objects + chain summary
`audit_agent`	Download and verify the complete decision chain	`INTACT` or `BROKEN` + position of break

OS	Config file location
Mac	`~/Library/Application Support/Claude/claude_desktop_config.json`
Windows	`%APPDATA%\Claude\claude_desktop_config.json`

Version	Feature	Status
v1.0.1	MCP server, 5 tools, 0G Storage + KV, chain integrity, npm package	✅ Live
v1.1	Sponsored storage no wallet needed, AgentLedger absorbs all gas costs	🔄 In progress
v1.2	Agent reputation leaderboard public rankings by chain length and integrity score	🗓 Planned
v1.3	Multi-chain support store on 0G, verify on any EVM chain	🗓 Planned

Parameter	Value
Network	0G Galileo Testnet
Chain ID	16602
RPC	https://evmrpc-testnet.0g.ai
Indexer	https://indexer-storage-testnet-turbo.0g.ai
Explorer	https://storagescan-galileo.0g.ai
Faucet	https://faucet.0g.ai