clawton-agentos
This server is a policy enforcement layer that lets an AI agent check proposed Binance trades and x402 payments against spend limits before they reach Binance's execution tools.
check_trade_intent— Validate a proposed Binance trade (symbol, side, USD value) against a $50 per-transaction cap and a shared $200 rolling 24-hour cumulative cap.check_payment_intent— Validate a proposed x402 payment (resource URL, USD value) against the same per-transaction and cumulative caps.Deny invalid or non-positive intents automatically.
Return a policy decision (
allowedordenied) that the agent uses to decide whether to proceed to Binance's MCP execution tools.Record each allowed or denied decision onchain to the Sepolia audit-log contract when
PRIVATE_KEYandRPC_URLare configured (otherwise logging is skipped and the policy check still runs).Does not execute trades or payments itself — it only gates them before execution.
Provides policy enforcement for Binance Agent OS, evaluating trade and payment intents against spend caps before any execution on a Binance Agentic sub-account.
Records every policy decision onchain to an audit-log smart contract on Ethereum Sepolia, providing an immutable audit trail of allowed and denied intents.
Click on "Install 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., "@clawton-agentosCheck a $30 BTCUSDT trade intent against policy before executing."
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.
clawton-agentos
A policy enforcement layer between an AI agent and Binance Agent OS's official MCP server.
Summary
Binance Agent OS gives AI agents direct trading and payment access to a dedicated Agentic sub-account through an official MCP server. That server handles execution and confirmation, but the pre-execution policy layer — spend caps, cumulative limits, onchain audit trails — is left to the developer to build.
clawton-agentos is a local MCP server that sits alongside Binance's official binance-mcp-server inside the same AI agent session (tested with both Claude Code and Claude Desktop). Before any trade or x402 payment intent reaches Binance's MCP tools, it is evaluated against a configurable policy — a per-transaction spend cap and a rolling daily cumulative cap — and every decision, allowed or denied, is recorded onchain to a dedicated audit-log smart contract on Ethereum Sepolia.
I had already built and tested this exact idea — a policy layer that gates an AI agent's trades before they execute — in Clawton, against Binance's Spot Testnet. When Binance launched Agent OS with an official MCP server, it was a natural next step: apply the same principle to the real, officially hosted infrastructure instead of a CLI-driven testnet flow.
Related MCP server: MandateGuard
Design principle
The policy decides, not the agent. The agent is instructed — and, per its own tool descriptions, expected — to call this server's policy-check tools before calling any Binance MCP execution tool. If the check fails, nothing is forwarded — no trade, no payment — regardless of how the agent frames the request.
Architecture

The two servers are independent — there is no direct code link between them. The agent itself is the bridge: it is expected to call clawton-agentos's tools first, and only proceed to Binance's execution tools if the policy check returns allowed: true.
Components
File | Purpose |
| Core policy logic: |
| MCP server exposing |
| Unit tests for the policy logic, run in isolation (no live network calls) |
Policy rules
Per-transaction cap: $50 per trade or payment
Daily cumulative cap: $200, tracked in a rolling 24-hour window, shared across both trade and payment intents
Any invalid intent (missing fields, non-positive value) is denied
Every decision — allowed or denied — is logged onchain when
PRIVATE_KEYandRPC_URLare set in the environment of the session running the MCP server; if they are not set, onchain logging is skipped (logged as{skipped: true}) and the policy check still runs normally
Onchain audit log
Every policy decision is written to a logDecision(string,string,string,string,string) event on an audit-log smart contract deployed on Ethereum Sepolia:
Contract address: 0x86b8ED1803c99768D67a81ed1d1a1F9f8f517269 (view on Etherscan)
This contract was already deployed and independently security-reviewed (Slither, Aderyn, Mythril static/symbolic analysis) prior to this project, with 100% unit test line coverage — it is not new code written for this submission. Reusing an already-audited, already-deployed contract for onchain logging here was a deliberate choice over deploying a new, unaudited one under time pressure.
What's been verified end-to-end
Real OAuth connection to Binance Agent OS's official MCP server (
https://agent.binance.com/mcp/agentic) from Claude Code, authenticated against a real Binance.com accountLive market data retrieval through the connected Binance MCP server (real-time BTCUSDT price and 24h stats)
A trade intent ($25 BTCUSDT) evaluated by
check_trade_intent, approved by policy, and correctly halted by the agent when the Agentic sub-account had no funds — no order was attempted against an empty accountA real trade executed end to end: with the Agentic sub-account funded with $3, a $2 BNB market buy was approved by
check_trade_intentand then placed throughbinance-mcp-server, filling for 0.006 BNB at ~$750.52. The resulting balance (0.00599550 BNB plus USDT change) was independently confirmed via a separate balance query againstbinance-mcp-server, not just the agent's own summary of the trade.A payment intent ($15, x402-style) evaluated by
check_payment_intentand approved by policyOnchain audit logging, confirmed independently multiple times: trade-intent and payment-intent checks produced real Sepolia transactions when
PRIVATE_KEY/RPC_URLwere present in the session, and a separate, latercast logsquery against the deployed contract confirmed the event data matches exactly what was reported at check timeBoth
clawton-agentosandbinance-mcp-serverconnected successfully as MCP servers from both Claude Code and Claude Desktop
Known limitations (honest, current state)
Onchain logging depends on environment variables being present in the exact session running the MCP server.
PRIVATE_KEY/RPC_URLmust be exported in the same terminal session before launching Claude Code (or set in Claude Desktop's process environment) — a new session or a differently-launched client will silently skip onchain logging ({skipped: true}) even though the policy check itself still runs correctly. This was observed directly during testing: one trade execution completed successfully without a prior onchain log because the session lacked these variables, while a subsequent explicit policy check in a properly configured session did produce a real onchain transaction.Local ledger, not onchain-derived. The daily cap is tracked in a local JSON file (
spend-log.json), not read from an onchain cumulative-spend contract. This is a simpler, faster-to-build approach appropriate for this project's scope.Claude Desktop integration is less stable than Claude Code. The MCP connection to
clawton-agentosfrom Claude Desktop was observed disconnecting unexpectedly at least once during testing, and required re-adding to its config file. Claude Code is the fully verified, stable integration path; Claude Desktop support is best-effort.The new server code itself is not independently security-audited. The audit-log contract it writes to was previously reviewed;
policy.jsandindex.jsare unit-tested but have not been through static analysis.Testnet-only for logging. All onchain logging targets Ethereum Sepolia. The Binance Agent OS connection itself is necessarily against a real Binance account (Binance Agent OS has no sandbox/testnet); testing was done with a small, intentionally limited real balance ($3) in the Agentic sub-account.
Setup
Prerequisites
Node.js 18+
A real Binance.com account (Binance Agent OS has no sandbox/testnet)
Claude Code or Claude Desktop, both of which support connecting to multiple MCP servers in one session
(Optional, for onchain logging)
PRIVATE_KEYandRPC_URLenvironment variables for a funded Sepolia wallet, exported in the same session that launches the client, andcast(Foundry) installed
Install
git clone <this-repo-url>
cd clawton-agentos
npm installConnect to Claude Code
claude mcp add clawton-agentos --transport stdio node $(pwd)/index.js
claude mcp add binance-mcp-server --transport http https://agent.binance.com/mcp/agentic
claudeInside Claude Code, run /mcp, select binance-mcp-server, and authenticate — this opens Binance's real OAuth consent screen and creates (or reuses) an Agentic sub-account.
Connect to Claude Desktop
Add to ~/.config/Claude/claude_desktop_config.json (Linux path):
{
"mcpServers": {
"clawton-agentos": {
"command": "node",
"args": ["/absolute/path/to/clawton-agentos/index.js"]
}
}
}Restart Claude Desktop, then add binance-mcp-server via Settings → Connectors → Add custom connector, using https://agent.binance.com/mcp/agentic.
Run the unit tests
node test-policy.jsTry it
In either client, once both servers are connected:I want to buy $25 of BTCUSDTThe agent should call check_trade_intent before attempting anything on binance-mcp-server. If your Agentic sub-account is unfunded, execution will correctly stop there.
Background
This project builds on Clawton, an existing, actively developed personal project applying the same "the policy decides, not the agent" principle to Binance Spot Testnet trading and x402 payments via a Newton Protocol (Rego/WASM) policy engine.
Clawton is not a from-scratch build for this hackathon — it predates it, and it has been run and verified end to end, not just written:
Security-reviewed: its three original smart contracts were run through three independent static/symbolic analysis tools (Slither — 101 detectors, clean; Aderyn — 63 detectors, one real finding found and fixed, test-proven with a passing Foundry reinitialization test; Mythril — symbolic execution, no new findings).
Unit-tested: 26 Foundry tests across its three contracts, with 92%+ line coverage and 100% function coverage on each.
Actually executed on Sepolia, not just deployed: real, verifiable transactions exist for both an allowed and a denied Binance trade, and both an allowed and a denied x402 payment, each independently inspectable on Etherscan from Clawton's own README.
Price-feed integrity checked: a live price-anomaly guard (sanity + deviation checks) was added, tested in isolation, and then verified end-to-end by deliberately triggering a false anomaly and confirming both the denial and its onchain audit record.
The audit-log contract this project (clawton-agentos) writes to — ClawtonTradeLog at 0x86b8ED1803c99768D67a81ed1d1a1F9f8f517269 — is reused unmodified from that already-verified system. clawton-agentos itself targets a different, newer surface (Binance's officially hosted Agent OS MCP infrastructure) with a simpler local policy engine suited to that scope, rather than Clawton's full Rego/WASM evaluation pipeline.
License
MIT
Available Tools
2 toolscheck_payment_intentCheck x402 Payment Intent Against PolicyA
Evaluates a proposed x402 protocol payment against a per-transaction spend cap and a rolling daily cumulative spend cap, shared with trade intents. Call this BEFORE signing or sending any x402 payment.
| Name | Required | Description | Default |
|---|---|---|---|
| usdValue | Yes | Estimated USD value of the payment | |
| resourceUrl | Yes | The x402-protected resource URL being paid for |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral burden. It discloses the evaluation criteria and that the cap is shared with trade intents, and 'before signing or sending' implies a preflight check. However, it does not state whether the call has side effects, what the result/verdict looks like, or how policy violations are returned.
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 with no wasted words: the first states the core behavior, the second provides actionable timing. The structure is front-loaded and easy to parse.
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?
Given no output schema and no annotations, the description omits important return semantics: what does the check return when the payment is allowed versus blocked? It also does not explicitly confirm non-mutation. The shared-cap note and timing are helpful, but an agent still cannot fully anticipate the tool's response or failure 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?
Schema coverage is 100%, so the parameters are already documented in the schema. The description reinforces that usdValue is checked against the caps and resourceUrl identifies the x402 resource, but it adds no new format, unit, or constraint details beyond the schema. 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: it 'evaluates a proposed x402 protocol payment' against identified spend caps. It also notes the caps are shared with trade intents, which helps position it relative to the sibling, though it does not explicitly contrast the two tools.
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 an explicit call timing: 'Call this BEFORE signing or sending any x402 payment.' This is clear contextual guidance, though it does not explicitly state when to use check_trade_intent instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
check_trade_intentCheck Trade Intent Against PolicyA
Evaluates a proposed Binance trade against a per-transaction spend cap and a rolling daily cumulative spend cap before it is forwarded to the official Binance MCP server for execution. Call this BEFORE calling any Binance MCP trading tool.
| Name | Required | Description | Default |
|---|---|---|---|
| side | Yes | Trade side | |
| symbol | Yes | Trading pair symbol, e.g. BTCUSDT | |
| usdValue | Yes | Estimated USD value of the trade |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It does explain the tool evaluates policy caps and is a pre-execution gate rather than the actual trading action. However, it does not disclose what happens when a cap is exceeded, whether the call has side effects, or what the returned result signifies.
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 long, front-loads the core purpose, and immediately gives the critical usage instruction. Every sentence adds value, and there is no redundant or vague phrasing.
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 input side is well covered by the schema and all three parameters are required. However, there is no output schema and the description does not explain what kind of result this tool returns or how an agent should interpret it when deciding whether to proceed with the trade.
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 parameters are already fully documented in the schema. The description adds no parameter-specific detail beyond indicating the trade context, which matches the baseline expectation for high schema 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?
The description clearly states the tool's specific action — evaluating a proposed Binance trade against per-transaction and daily cumulative spend caps — and distinguishes it from executing the trade itself. The verb "Evaluates" plus the targeting of a specific resource makes 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?
The description gives an explicit when-to-use instruction: "Call this BEFORE calling any Binance MCP trading tool." It does not directly mention alternatives or exclusions, but the placement guidance is strong and leaves little doubt about the intended call order.
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.
2 tool updates
v1.0.0- First observed
check_payment_intent - First observed
check_trade_intent
TDQS
Scored across 2 tools
The two tools are cleanly separated by intent type: one evaluates x402 payments and the other evaluates Binance trades. Their names and descriptions make the correct choice obvious, with no functional overlap despite both being pre-flight checks.
Both tools follow the same check_<intent> convention: check_payment_intent and check_trade_intent. The pattern is predictable and makes the set easy to navigate.
Two tools is slightly below the typical 3-15 range, but the server appears intentionally scoped to guardrail checks for two specific intent types. Each tool earns its place and there is no redundant surface.
For the stated purpose of payment and trade safety checks, the server covers both target intents. It lacks any cap-management or status tools, but those may be intentionally external and agents can proceed with the checks provided.
Maintenance
Resources
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.
Related MCP Connectors
Pre-spend firewall for AI agents. Approves, blocks, flags transactions against policy rules.
Policy-gated MCP treasury for AI agents — x402 subscribe, 50+ tools, multi-chain.
AI/LLM agent output audit MCP: policy eval, tamper-evident chain, AI safety, x402 USDC on Base.
Pre-execution governance for AI agents. Deterministic PASS/FAIL/REVIEW verdicts, replayable proof.
Related MCP Servers
- AlicenseAqualityCmaintenanceCryptographic proof of consent for AI agents. Sign before you act. Policy engine enforces spending caps, action whitelists, and escalation rules. Independently verifiable by anyone.102Apache 2.0
- AlicenseNot gradedqualityAmaintenanceDeterministic, auditable payment policy enforcement for AI agents. It provides pre-action authorization with scopes, budgets, allowlists, and signed mandates via an MCP server.MIT
- FlicenseNot gradedqualityCmaintenanceEnables AI agents to propose wallet payments while a local, human-authored policy decides whether each transaction is approved, requires human confirmation, or is refused, and records every decision in a signed, append-only ledger.-
- FlicenseNot gradedqualityCmaintenanceEnables AI agents to trade on Binance through a governed MCP proxy that enforces configurable policies, requires a recorded rationale before orders, detects prompt injection, logs all actions in a tamper-evident audit trail, and blocks execution until a human approves.-