Provides read-only MCP tools for querying the x207-circle contract on NEAR, enabling agents to inspect live testnet circle state without signing or needing a key.
This server has a remotely hosted endpoint. Open its connector listing for connection details, authentication requirements, and setup instructions:
TypeScript packages that let an x402 agent pay and sell in a clearing circle: the x402 batch-settlement binding on the network x207:<circleId>, plus a reference facilitator, an MCP server and test vectors. Part of x207.
The SDK is how agents meet the contract without knowing NEAR. A buyer wraps fetch once and pays with signed vouchers; a seller adds one middleware and its 402 answer offers the voucher entry next to exact; the facilitator verifies vouchers and registers them on chain. spec/ holds the voucher format and test vectors that the TypeScript and Rust CI share.
Folder | Package | Contents |
|
| Voucher types and signing, client for the |
|
| x402 binding per role: |
|
| MCP server: read tools by default, signs nothing |
|
| Reference facilitator: |
|
| |
|
|
flowchart LR
subgraph Agent["Buyer agent"]
X[x402 fetch wrapper] --> PC[X207PaymentClient]
end
subgraph Seller["Seller"]
MW[x207Middleware]
end
PC -- "voucher" --> MW
MW -- "/verify, /settle" --> FA[Facilitator]
FA -- "register_cumulative" --> CT[(x207-circle)]
CO["@x207/core"] -.-> PC
CO -.-> FA
MCP["@x207/mcp: read tools"] --> CTRelated MCP server: obolpay-x402-mcp
Ask an AI client about the live testnet circle through the MCP server, with no key (needs Node 22.22.2 or newer):
X207_CIRCLE_CONTRACT=x207-v013.testnet X207_CIRCLE_ID=agents-main \
X207_BACKEND_URL=https://x207.boxd.sh npx -y @x207/mcpThis starts a stdio server for an MCP client, so it waits for input. Configuration for Claude Desktop and Cursor: docs in the umbrella. To pay as a buyer:
npm install @x207/core @x207/scheme @x402/fetchThe snippet is ESM (top-level await): put "type": "module" in your package.json, or save it as a .mts file.
import { wrapFetchWithPayment } from "@x402/fetch";
import { X207PaymentClient, headroomFromRpc } from "@x207/scheme";
const secretKey = process.env.X207_VOUCHER_KEY as `ed25519:${string}`; // the voucher key, see below
const client = new X207PaymentClient({ payer: "agent.near", secretKey, headroom: headroomFromRpc({}) });
const paidFetch = wrapFetchWithPayment(fetch, client);
const response = await paidFetch("https://seller.example/api/summarize");secretKey is the voucher key: one ed25519 key used only for vouchers, never a NEAR access key (Voucher key security). X207PaymentClient registers x207:* and falls back to the other entry of the 402 answer (normally exact) when headroom runs out. A 200 response carries the header PAYMENT-RESPONSE; extensions.x207.registration is pending, retrying or registered.
Joining a circle (onboardMember: voucher key, join, stake, wait for active) is in the quickstart. Selling: docs/seller-quickstart.md. Full tested examples: examples/buyer, examples/seller.
Needs Node ≥ 22.22.2 and npm 11 (the lockfiles are made with it; package.json enforces only the Node version). All dependencies are pinned exactly.
npm install
npm run build
npm test # unit tests
npm run test:sandbox # needs a near-sandbox binary and the contract wasm (../contracts/target/near/*.wasm)
npm run conformance # suite for other implementations of the bindingThe sandbox binary is looked up in X207_SANDBOX_BIN, or in the build output of the contracts repository after cargo test has run once. Copy .env.example to .env for the facilitator; secrets live only in .env, which is not committed.
Costs: when there is an on-chain transaction · FAQ for agent builders
epoch_length and the wait for payment · Payment guarantees for sellers
Overview, live demo links and the claims map: x207-labs/x207.
Apache-2.0
Start here: the circle itself, i.e. its record and rules (get_circle, get_params) plus a page of its members (read API GET /members, or the contract view list_members when no read API is set). Use x207_member_inspect for one member in detail and x207_epoch_report for one epoch. Returns {contract, circleId, circle, params, members, membersSource, warnings}; amounts are strings in the smallest unit (6 decimals). If the members part fails it shows up in warnings and the rest is still returned; an unreachable contract RPC is an error.
| Name | Required | Description | Default |
|---|---|---|---|
| members_limit | No | Size of the members page, 1 to 200 (default 20); the circle may have more members than this. | |
| members_status | No | Keep only members with this status, e.g. active, suspended or exiting. Read API only; ignored on the contract fallback. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only declare safety (read-only, idempotent, non-destructive, open-world); the description adds real behavioral detail beyond them: partial-failure semantics where a failed members fetch is reported in `warnings` while the rest still returns, and the contrasting hard failure when the contract RPC is unreachable. That distinction materially changes how an agent should handle a result.
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?
Front-loaded with the routing cue 'Start here', then purpose, alternatives, return shape, and failure behavior in a compact block with zero filler. Dense and slightly jargon-heavy (get_circle, get_params, membersSource), but every clause carries information an agent needs.
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 supplies the return shape ({contract, circleId, circle, params, members, membersSource, warnings}) and the numeric encoding, plus error vs partial-failure behavior. For a zero-required-parameter read tool, that covers everything an agent needs to call it and interpret the result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the two parameters are already fully documented, including the members_status read-API-only caveat. The description adds limited extra param meaning, though its note that amounts are strings in the smallest unit (6 decimals) clarifies the data domain the parameters operate over. Slightly above baseline because of that unit note.
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 concrete resource and composition: the circle's record and rules (get_circle, get_params) plus a page of members, and names the entry point with 'Start here'. The explicit contrast with x207_member_inspect and x207_epoch_report makes it distinguishable from siblings at a glance.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives both when-to-use ('Start here') and when-not: use x207_member_inspect for a single member, x207_epoch_report for a single epoch. It also documents the data-source fork (read API GET /members vs contract view list_members when no read API is set), so the agent understands which path it will get.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
One epoch of the circle: its phase and deadlines from the contract (get_epoch), and from the read API the summary, the metrics (cleared ratio: the share of debt that netting removed, so only the net cash moves) and the settlements, i.e. who owes whom what in cash. Use it after an epoch closed; use x207_simulate_clearing to test a proposal before it is submitted. Returns {epoch, contract, summary, metrics, settlements, source, warnings}. An epoch that does not exist is an error; if the read API is down the contract record is still returned, with the failures in warnings.
| Name | Required | Description | Default |
|---|---|---|---|
| epoch | No | Epoch number, 0 or more. Leave out for the current epoch, which is still open and has no settlements yet. | |
| settlements_limit | No | How many settlement rows to return, 1 to 200 (default 20). A busy epoch has more; raise it to see them all. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnly/idempotent annotations, the description discloses failure behavior: a nonexistent epoch is an error, and if the read API is down the contract record is still returned with failures surfaced in `warnings`. That partial-degradation contract is genuinely useful context an agent cannot get from annotations, though it says nothing about rate limits or result size beyond settlements_limit.
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?
Front-loaded with the purpose, then usage, then return shape and failure modes — a sensible order. The parenthetical definitions are dense and slightly run-on, but each clause carries information; no filler sentences.
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 compensates by naming every top-level return key {epoch, contract, summary, metrics, settlements, source, warnings} and explaining the two non-obvious ones. Combined with the error and degraded-mode behavior, an agent has enough to call this correctly and interpret results.
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%, and the schema already explains that omitting `epoch` yields the current open epoch and that `settlements_limit` caps returned rows. The description adds domain meaning to what settlements and metrics represent (who owes whom in cash; cleared ratio as debt removed by netting), which helps interpretation but is output semantics rather than parameter guidance, so the baseline 3 holds.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb-and-resource: retrieves one epoch's phase and deadlines from the contract plus summary, metrics and settlements from the read API. It explicitly names the sibling it is not (x207_simulate_clearing) and enumerates the returned components, so an agent can distinguish it from sibling tools without opening schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives an explicit timing condition ('use it after an epoch closed') and an alternative route for the other case ('use x207_simulate_clearing to test a proposal before it is submitted'). When-to-use and when-to-use-something-else are both present, leaving little to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
One member of the circle: status, stake, outstanding debt and credit limit (read API GET /members/{account} and /limits, or the contract views member and limit when no read API is set). Use it after x207_circle_overview has shown the account ids, or before paying a member; for epoch-level amounts use x207_epoch_report. Returns {account, member, limits|limit, source, warnings}. An account that is not a member is an error ("not a member" or a 404 from the read API); a failed limits lookup is only a warning.
| Name | Required | Description | Default |
|---|---|---|---|
| account | Yes | The member to look up: its NEAR account id, or for an EVM agent its lower-case 0x address. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare this as a read-only, idempotent, non-destructive operation, and the description adds substantial context beyond that. It discloses the data sources (read API GET endpoints or contract view fallback), the return object fields, and the distinction between a hard non-member error and a soft limits warning. This is unusually complete behavioral detail for a 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?
The description is front-loaded with purpose and usage, then return shape, then error behavior. It is dense but mostly earns its space; the parenthetical endpoint and contract-view fallback detail is useful but makes the first sentence heavy. Overall it remains readable and free of obvious filler.
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?
Although there is no output schema, the description supplies the return shape, source field, and warnings field. It covers when to call it, what it returns, and how failures are surfaced. Nothing essential is missing for a one-parameter read tool.
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%, and the account parameter already documents the NEAR account id or lower-case 0x address format. The description adds useful context that account ids come from x207_circle_overview and shows the account in the return shape, but it does not add significant syntax or semantic detail beyond the schema. A 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: inspecting one circle member for status, stake, outstanding debt, and credit limit. It distinguishes itself from siblings by naming x207_circle_overview for account discovery and x207_epoch_report for epoch-level amounts. It also gives the exact return shape, so the agent knows what this tool produces.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives explicit usage context: use after x207_circle_overview has shown account ids, or before paying a member. It also names the alternative for epoch-level amounts. Error behavior is specified, including that a non-member account is an error while a failed limits lookup is only a warning.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Orders of the circle's marketplace (read API GET /orders). With a hash: one order with its parties, budget, milestones and status. Without a hash: a page of orders, filtered by party and status. Use x207_search_listings to find offers before an order exists. An unknown hash is an error ("no order ... in circle"); an empty list is a normal result. Needs the read API (X207_BACKEND_URL).
| Name | Required | Description | Default |
|---|---|---|---|
| hash | No | The order hash. Leave out to list orders. | |
| limit | No | Page size, 1 to 200 (default 20); listing only. | |
| party | No | Only orders where this account is buyer or seller (listing only). | |
| cursor | No | The nextCursor of the previous page; listing only. | |
| status | No | Only orders in this state, e.g. open, delivered or disputed (listing only). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already establish read-only, idempotent, non-destructive behavior. The description adds meaningful context beyond that: the backend environment variable requirement, the difference between an unknown-hash error and an empty-list result, and the return contents for single-order lookup.
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 dense but front-loaded and every clause contributes operational information: resource, hash/no-hash behavior, alternative sibling tool, error semantics, and environment dependency. There is no redundant restatement of the schema.
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 read-only tool with five optional parameters and no output schema, the description covers the key behavioral branches, return contents for single-order lookup, filtering behavior for listing, error semantics, and backend dependency. Nothing essential for correct invocation is missing.
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 baseline is 3. The description still adds useful meaning by explaining that hash switches between single-order retrieval and listing, and that listing can be filtered by party and status; cursor and limit details remain schema-driven.
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 names the specific resource (orders in the circle's marketplace), the underlying read API, and the two distinct modes: hash lookup for one order versus paginated listing. It also distinguishes this tool from x207_search_listings, making sibling selection clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly says when to use a hash versus no hash, and directs the agent to x207_search_listings when looking for offers before an order exists. It also clarifies that an unknown hash is an error while an empty list is normal, which prevents misuse.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find offers on the circle's marketplace (read API GET /listings): what an account offers and what it wants. Use it to discover who sells a service; for an order that already exists use x207_order_status. Returns {items, nextCursor}; pass nextCursor as cursor for the next page. No match gives an empty list, not an error. Needs the read API (X207_BACKEND_URL) and fails with a clear message without it.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Page size, 1 to 200 (default 20). | |
| cursor | No | The nextCursor of the previous page; leave out for the first page. | |
| status | No | Listing state to match; open when left out, all for every state. | |
| account | No | Only listings of this account. | |
| wantType | No | Asset type the lister wants in return, same form as offerType. | |
| offerType | No | Asset type the lister offers, e.g. service:summary; exact match. | |
| wantClass | No | Same, for the wanted asset. | |
| offerClass | No | Settlement class of the offered asset (A to D, X for other); keep only listings of this class. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, non-destructive, and open-world, so the bar is lower, yet the description still adds the HTTP route, the prerequisite (X207_BACKEND_URL) and its failure mode, and the no-match-yields-empty-list semantics. That is meaningful operational context beyond the structured fields.
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?
Front-loads what the tool does, then the alternative, then the return shape, then the empty-result and prerequisite caveats. Every sentence carries distinct information with no padding.
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?
No output schema exists, yet the description supplies the response envelope {items, nextCursor} and the pagination contract, plus prerequisite and error behavior. Nothing an agent needs to call this eight-parameter read tool correctly is missing.
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 baseline is 3, but the description goes beyond it by explaining the cursor round-trip (pass the returned nextCursor as `cursor`) and the purpose of the search (offer/want discovery across accounts). It stops short of clarifying filter interactions such as offerClass vs offerType.
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?
Names a specific verb and resource ('Find offers on the circle's marketplace') plus the underlying route (GET /listings), and explicitly contrasts with the sibling order tool. An agent can distinguish it from x207_order_status without opening either schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives a concrete when-to-use ('discover who sells a service') and routes existing-order questions to x207_order_status. It does not spell out when-not conditions for the filter dimensions (e.g. use status=all vs default open), so it falls just short of fully explicit routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Dry run of a netting proposal: asks the contract (view simulate_clearing) whether the edges would be accepted for an epoch and how much debt they would cancel. Use it to check a proposal before a solver submits it; to see what a finished epoch actually netted use x207_epoch_report. Returns {epoch, edgeCount, result}. An invalid proposal (unknown member, amount above the debt, wrong epoch phase) comes back as an error text from the contract. Read-only, sends nothing.
| Name | Required | Description | Default |
|---|---|---|---|
| edges | Yes | 1 to 300 debt edges; a cycle of edges nets to zero cash. | |
| epoch | Yes | The epoch the proposal is for; it must be one that can still accept a clearing. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint, so "Read-only, sends nothing" largely restates them. What the description does add beyond the annotations is genuinely useful: the failure mode (invalid proposal returns an error text from the contract) and the enumerated invalid causes (unknown member, amount above debt, wrong epoch phase). That is real added context, but the return shape is the only other disclosure and pagination/size behavior is untouched.
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?
Front-loaded with the core purpose, then routing, then return shape, then error semantics – a sensible order with no filler. The return-shape sentence is justified because there is no output schema; the "Read-only, sends nothing" clause is the only near-redundant wording against the annotations.
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 supplies the return shape ({epoch, edgeCount, result}), the error contract for invalid proposals, and the safety profile is already covered by annotations. For a two-parameter dry-run tool, an agent has everything needed to call it and interpret both success and failure.
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% and both parameters are fully documented in the schema, so the baseline is 3. The description mentions epoch and edges and echoes the "amount above the debt" constraint, but adds no syntax, format, or default information beyond what the schema already carries.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ("Dry run of a netting proposal", asks the contract view simulate_clearing) and immediately scopes the question it answers: whether edges would be accepted and how much debt they'd cancel. It also explicitly distinguishes itself from the sibling x207_epoch_report, so an agent can route without opening either schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives an explicit when-to-use ("check a proposal before a solver submits it") and an explicit alternative for the adjacent need ("to see what a finished epoch actually netted use x207_epoch_report"). The pre-submission timing constraint is exactly the decision an agent needs.
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.0.5x207_circle_overview2 fields changedInput schema / properties / members_limit / descriptionPrevious value: -"How many items, 1 to 200 (default 20)."New value: +"Size of the members page, 1 to 200 (default 20); the circle may have more members than this."Input schema / properties / members_status / descriptionPrevious value: -"Only members with this status, e.g. active (read API only)."New value: +"Keep only members with this status, e.g. active, suspended or exiting. Read API only; ignored on the contract fallback."x207_epoch_report2 fields changedInput schema / properties / epoch / descriptionPrevious value: -"Epoch number; the current epoch when left out."New value: +"Epoch number, 0 or more. Leave out for the current epoch, which is still open and has no settlements yet."Input schema / properties / settlements_limit / descriptionPrevious value: -"How many items, 1 to 200 (default 20)."New value: +"How many settlement rows to return, 1 to 200 (default 20). A busy epoch has more; raise it to see them all."x207_member_inspect1 field changedInput schema / properties / account / descriptionAdded value: +"The member to look up: its NEAR account id, or for an EVM agent its lower-case 0x address."x207_order_status3 fields changedInput schema / properties / cursor / descriptionAdded value: +"The nextCursor of the previous page; listing only."Input schema / properties / limit / descriptionPrevious value: -"How many items, 1 to 200 (default 20)."New value: +"Page size, 1 to 200 (default 20); listing only."Input schema / properties / status / descriptionPrevious value: -"Only orders with this status (listing only)."New value: +"Only orders in this state, e.g. open, delivered or disputed (listing only)."x207_search_listings7 fields changedInput schema / properties / cursor / descriptionAdded value: +"The nextCursor of the previous page; leave out for the first page."Input schema / properties / limit / descriptionPrevious value: -"How many items, 1 to 200 (default 20)."New value: +"Page size, 1 to 200 (default 20)."Input schema / properties / offerClass / descriptionAdded value: +"Settlement class of the offered asset (A to D, X for other); keep only listings of this class."Input schema / properties / offerType / descriptionPrevious value: -"Asset type offered, e.g. service:summary."New value: +"Asset type the lister offers, e.g. service:summary; exact match."Input schema / properties / status / descriptionPrevious value: -"Default open."New value: +"Listing state to match; open when left out, all for every state."Input schema / properties / wantClass / descriptionAdded value: +"Same, for the wanted asset."Input schema / properties / wantType / descriptionAdded value: +"Asset type the lister wants in return, same form as offerType."x207_simulate_clearing5 fields changedInput schema / properties / edges / descriptionAdded value: +"1 to 300 debt edges; a cycle of edges nets to zero cash."Input schema / properties / edges / items / properties / cleared / descriptionAdded value: +"Debt to cancel on this edge, a decimal string in the smallest unit (6 decimals), at most what the debtor owes."Input schema / properties / edges / items / properties / creditor / descriptionAdded value: +"Member that is owed."Input schema / properties / edges / items / properties / debtor / descriptionAdded value: +"Member that owes."Input schema / properties / epoch / descriptionAdded value: +"The epoch the proposal is for; it must be one that can still accept a clearing."v0.0.4x207_circle_overviewx207_epoch_reportx207_member_inspectx207_order_statusx207_search_listingsx207_simulate_clearingScored across 6 tools
Each tool targets a clearly distinct scope: circle overview vs single-member inspection, actual epoch report vs dry-run clearing simulation, and marketplace discovery vs order lookup. The descriptions explicitly cross-reference neighboring tools, so an agent can reliably choose the right one.
All tools share the x207_ prefix and use snake_case, which makes the set predictable overall. However, the resource/action ordering varies (member_inspect, circle_overview, simulate_clearing, search_listings, order_status), so it is mostly rather than fully consistent.
Six tools map cleanly onto the server's apparent subdomains: circle, member, epoch, clearing simulation, listings, and orders. There are no redundant tools, and the count is well scoped for an inspection-oriented MCP.
The surface covers core read operations and a clearing dry run, but omits lifecycle actions such as submitting a netting proposal, creating orders or listings, paying members, or updating circle state. Agents can inspect the domain thoroughly but will hit dead ends for write workflows.
MCP server for Boson Protocol — on-chain agentic commerce for physical & digital goods.
Agent-native MCP for governed commerce, x402 payments, paid capabilities, and verifiable receipts.
Host any HTTP API as MCP tools with a tamper-evident cross-agent settlement ledger.
Free, non-custodial MCP: validate bounded USDC/USDT payout plans, look up public transfers (read-only), reconcile payouts. Never holds funds or keys.
