Skip to main content
Glama
0xR-1

clawton-agentos

by 0xR-1

clawton-agentos

License: MIT Node.js MCP

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

clawton-agentos 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

policy.js

Core policy logic: checkSpendIntent — per-transaction cap, rolling 24h cumulative cap, local JSON ledger (spend-log.json), onchain audit logging via cast send

index.js

MCP server exposing check_trade_intent and check_payment_intent as tools, via @modelcontextprotocol/sdk (stdio transport)

test-policy.js

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_KEY and RPC_URL are 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 account

  • Live 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 account

  • A real trade executed end to end: with the Agentic sub-account funded with $3, a $2 BNB market buy was approved by check_trade_intent and then placed through binance-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 against binance-mcp-server, not just the agent's own summary of the trade.

  • A payment intent ($15, x402-style) evaluated by check_payment_intent and approved by policy

  • Onchain audit logging, confirmed independently multiple times: trade-intent and payment-intent checks produced real Sepolia transactions when PRIVATE_KEY/RPC_URL were present in the session, and a separate, later cast logs query against the deployed contract confirmed the event data matches exactly what was reported at check time

  • Both clawton-agentos and binance-mcp-server connected 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_URL must 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-agentos from 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.js and index.js are 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_KEY and RPC_URL environment variables for a funded Sepolia wallet, exported in the same session that launches the client, and cast (Foundry) installed

Install

git clone <this-repo-url>
cd clawton-agentos
npm install

Connect 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
claude

Inside 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.js

Try 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 tools
check_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.

ParametersJSON Schema
NameRequiredDescriptionDefault
usdValueYesEstimated USD value of the payment
resourceUrlYesThe x402-protected resource URL being paid for

TDQS

A3.7/5.0
Behavior3/5

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.

Conciseness5/5

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.

Completeness3/5

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.

Parameters3/5

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.

Purpose4/5

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.

Usage Guidelines4/5

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.

ParametersJSON Schema
NameRequiredDescriptionDefault
sideYesTrade side
symbolYesTrading pair symbol, e.g. BTCUSDT
usdValueYesEstimated USD value of the trade

TDQS

A3.9/5.0
Behavior3/5

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.

Conciseness5/5

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.

Completeness3/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines4/5

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.

  1. 2 tool updatesv1.0.0
    • First observedcheck_payment_intent
    • First observedcheck_trade_intent

TDQS

A4/5.0

Scored across 2 tools

Disambiguation5/5

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.

Naming Consistency5/5

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.

Tool Count4/5

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.

Completeness4/5

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

ActivityMaintained
ResponsivenessNo issues

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

Related MCP Servers

  • A
    license
    A
    quality
    C
    maintenance
    Cryptographic proof of consent for AI agents. Sign before you act. Policy engine enforces spending caps, action whitelists, and escalation rules. Independently verifiable by anyone.
    10
    2
    Apache 2.0
  • F
    license
    Not graded
    quality
    C
    maintenance
    Enables 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.
    -
  • F
    license
    Not graded
    quality
    C
    maintenance
    Enables 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.
    -