AFOS — Agentic Financial OS

escrow_open

Protects a payment to a counterparty you do not trust yet, WITHOUT us ever holding your money. You sign a USDC authorization that pays the counterparty directly; we hold the signature and do not broadcast it. When they deliver and you confirm the artifact hash matches, we broadcast and they are paid in one on-chain transfer. If they never deliver, we discard the signature and your funds never moved: they were in your own wallet the whole time. Sign a second authorization for the fee (see escrow_get_quote), which is settled immediately. Returns buyer_token and seller_token, ONCE: hand seller_token to the counterparty when you commission the work, and keep buyer_token, which is what releases payment. Needs no account.

Input Schema

TableJSON Schema

Name	Required	Description
`amount_usd`	Yes	The amount being protected, in USD. Must match the value in your signed authorization.
`term_hours`	No	How long the counterparty has to deliver. Default 24, maximum 168 (7 days). Shorter is safer: your signature is held for the whole term.
`seller_wallet`	Yes	The counterparty's 0x address on Base. Must match the payee in your signed authorization.
`fee_authorization`	No	Base64 x402 payment payload for the escrow fee, paying Focxle. Settled immediately when the escrow opens.
`payment_authorization`	Yes	Base64 x402 payment payload: an ERC-3009 authorization paying the SELLER, with validBefore at least 15 minutes past the deadline. Held, never broadcast until delivery is verified.

TDQS

A4.6/5.0

Behavior5/5

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

With no annotations, the description fully discloses key behavioral traits: 'WITHOUT us ever holding your money', 'we hold the signature and do not broadcast it', 'If they never deliver, we discard the signature and your funds never moved', and the token return behavior. This is exceptional transparency for a financial tool.

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?

The description is long but every sentence earns its place, covering purpose, mechanism, fee, token handling, and account requirement in a logical flow. It could be slightly more structured, but the density is appropriate for the tool's complexity.

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

Completeness5/5

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

The description covers the entire lifecycle relevant to opening an escrow: trust setup, signature holding, fee handling, token distribution ('buyer_token' and 'seller_token'), and confirms no account is needed. It adequately explains return values despite no output schema, making it complete for a tool of this complexity.

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

Parameters4/5

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

Schema coverage is 100%, so baseline is 3. The description adds actionable guidance beyond the schema: term_hours is described as 'Shorter is safer', fee_authorization is 'settled immediately', and payment_authorization's holding semantics are reinforced. This enhances parameter understanding.

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 function: 'Protects a payment to a counterparty you do not trust yet' and explains the unique mechanism of holding a signature without broadcasting. It distinguishes itself from sibling escrow tools by describing the specific flow (broadcast on delivery, discard if not delivered) and references escrow_get_quote for the fee, making its 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 provides clear context for when to use the tool: when you need to pay an untrusted counterparty, and it notes 'Needs no account' as a prerequisite. It doesn't explicitly mention when not to use it or list alternative tools for non-escrow scenarios, but the context is sufficiently clear for selection.

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

All AFOS — Agentic Financial OS tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4/5.0

Disambiguation5/5

Each tool is scoped to a distinct resource and action within its domain (budget, contract, deal, escrow, hiring, wallet, workroom, trust). There is no overlap between tools; even similar operations like contract_confirm_delivery and escrow_confirm_delivery are clearly differentiated by context. A model can reliably select the correct tool for a given task.

Naming Consistency5/5

Tools follow a consistent pattern of domain prefix followed by verb_noun (e.g., budget_status, contract_submit_delivery, escrow_get_quote, wallet_set_autopay_threshold). The naming is uniform across all 42 tools, with no mixing of conventions like camelCase or inconsistent verb placement.

Tool Count2/5

With 42 tools, the server is heavily overloaded. While the scope of an 'Agentic Financial OS' is broad, the high count makes it difficult for an agent to quickly navigate and select the right tool. Many tools could be consolidated (e.g., multiple get/list tools per domain, documentation tools like *how_it_works that could be merged). The count exceeds the recommended range and feels excessive.

Completeness5/5

The tool set covers the full lifecycle of financial operations: budget management, negotiation (deal_open/propose/accept/cancel), contract creation and delivery with verification, escrow with payment protection, hiring workflows, wallet operations, trust checks, and a marketplace for data/services. There are no obvious gaps; even edge cases like disputes and audit trails are addressed.

Resources

Need Help?