Focxle: AI governance for B2B deals between agents
REMOTE · FOCXLE.COM
AI governance for B2B agent deals: negotiate, lock agreements, check payments. Plus x402 USDC.
Available components
Last scanned (11 minutes ago)
Scores higher than 94% of remote servers
Reachable. Last reached 5 Nov 2026.
Category Finance and Payments
How this component scores in each security and reliability category. Every signal is checked automatically against the live server, and we only credit what we can confirm. How we score → Why this is hard to score →
Endpoint Security94
- The endpoint's TLS certificate is valid, in date, and uses a strong key. View diagnostics → Pass
- Authorisation is enforced on tool calls, advertised via RFC 9728 protected-resource metadata. Discovery is public, which costs nothing: no tool can be invoked without a token. View diagnostics → Pass
- HTTPS is enforced; there's no plaintext access path. View diagnostics → Pass
- The HSTS (Strict-Transport-Security) header is present. View diagnostics → Pass
- DNSSEC check failed: this domain isn't protected by DNSSEC. See how to fix → View diagnostics → Fail
- The authorisation server offers only Dynamic Client Registration (RFC 7591), which MCP 2026-07-28 deprecated in favour of Client ID Metadata Documents. View diagnostics → Partial
Transport & Reachability100
- Verified streamable-http transport via a live MCP handshake. View diagnostics → Pass
Schema Quality & AI Usability71
- AI-judged instruction clarity (excellent).Pass
- Context-footprint check failed: tool/resource definitions use about 7852 tokens (~135/item across 58 items; 58 tools + 0 resources), over budget; trim descriptions and params. See how to fix → Fail
- Usage-examples check failed: none of the tools include examples. See how to fix → Fail
Stability & Change Management100
- No destabilizing schema changes in the last 30 days.Pass
Tool Coverage92
- 100% of tools have a non-trivial description (not blank, and not just the tool's name).Pass
- 75% of tool parameters carry a description.Partial
Tool Safety75
- No prompt-injection markers were found in the server instructions, tool names or descriptions we captured.Pass
- 0 of 7 tool(s) whose name or description implies an irreversible operation declare an MCP destructiveHint annotation; "negotiation_send" implies "send" and declares no destructiveHint at all, which the MCP spec reads as destructive by default. See how to fix → Fail
- An AI judge read all 59 captured unit(s) of tool text and found none that tries to manipulate the model reading it.Pass
Capabilities20
- Spec-recency check failed: implements MCP spec 2024-11-05; the latest is 2026-07-28. See how to fix → Fail
Every change we have recorded for this component, newest first. Security-relevant changes are always shown. ▲ marks a change for the better, ▼ a change for the worse; unmarked changes are neutral.
- 5 Nov 26 0
- Stability: 0.97 → pass security
- 4 Nov 26 0
- Stability: pass → 0.97 functional
- 26 Oct 26 +1
- Stability: fail → pass ▲ security
- 21 Oct 26 −1
- Stability: pass → fail ▼ security
- 29 Sept 26 0
- “agent_register” reworded the description of “purpose” cosmetic
1 cosmetic change on this day. Switch on “Show cosmetic changes” to see it.
- 28 Sept 26 0
- We updated how we score, so this day's move reflects our rubric, not a change to the server See what changed → functional
- 26 Sept 26 0
- A breaking change shipped without a version bump: still 1.0.0 ▼ security
- Tool “card_get_virtual” was removed ▼ security
- Tool “spend_check_limit” was removed ▼ security
- Tool “spend_request_approval” was removed ▼ security
- The server rewrote its instructions, which are the text every model session reads security
- Tool “agent_register” rewrote its description, which is the text the model reads security
- Tool “payment_history_mine” rewrote its description, which is the text the model reads security
- Tool “payment_record” rewrote its description, which is the text the model reads security
- Tool “trust_check_agent” rewrote its description, which is the text the model reads security
- Schema quality: 6679 → 7837 ▼ functional
- New tool “agreement_confirm_paid” functional
- New tool “agreement_get” functional
- New tool “agreement_verify” functional
- New tool “negotiation_approve” functional
- New tool “negotiation_close” functional
- New tool “negotiation_get” functional
- New tool “negotiation_join” functional
- New tool “negotiation_list” functional
- New tool “negotiation_open” functional
- New tool “negotiation_send” functional
- New tool “owner_invite” functional
- New tool “payment_heads_up” functional
- “agent_register” added an optional parameter “business” cosmetic
- “agent_register” reworded the description of “name” cosmetic
- “agent_register” reworded the description of “purpose” cosmetic
- “agent_register” reworded the description of “services” cosmetic
- “payment_record” reworded the description of “at” cosmetic
- “payment_record” reworded the description of “external_ref” cosmetic
- “payment_record” reworded the description of “idempotency_key” cosmetic
- “payment_record” reworded the description of “platform” cosmetic
- 25 Sept 26 0
- We updated how we score, so this day's move reflects our rubric, not a change to the server See what changed → functional
Diagnostic detail from the automated scan of this channel: what the scanner observed at each step, so you can see exactly where a check passed or failed. It is informational only and never changes the trust score.
Captured 5 Nov 2026 · Probed https://focxle.com/api/v1/mcp
TLS valid
Negotiated TLS 1.3 with TLS_AES_128_GCM_SHA256 .
| Subject | Issuer | Valid from | Valid until | Key | Signature | Serial |
|---|---|---|---|---|---|---|
| CN=focxle.com | CN=YR2,O=Let's Encrypt,C=US | 5 Sept 2026 | 4 Dec 2026 | RSA 2048 | SHA256-RSA | 672cf291d90874d75dcc87933158c9b0f06 |
| SANs: focxle.com | ||||||
| CN=YR2,O=Let's Encrypt,C=US (CA) | CN=Root YR,O=ISRG,C=US | 3 Sept 2025 | 2 Sept 2028 | RSA 2048 | SHA256-RSA | 4ebd24947e24d394802d84a52fd5b319 |
| CN=Root YR,O=ISRG,C=US (CA) | CN=ISRG Root X1,O=Internet Security Research Group,C=US | 13 May 2026 | 2 Sept 2032 | RSA 4096 | SHA256-RSA | f24b6d17f9d9ad7cb1c9fea78782699f |
Background: What to check on a remote MCP endpoint →
DNSSEC insecure
Validation of focxle.com. — Not signed
| Zone | DS | Keys | Algorithms | Outcome |
|---|---|---|---|---|
| . | trust_anchor | 20326, 38696 | 8, 8 | Verified |
| com. | present | 19718 | 13 | Verified |
| focxle.com. | absent | Unsigned (proven) parent-signed NSEC/NSEC3 proves an unsigned delegation |
Authentication Enforced and verified
The endpoint asked for a token and published valid RFC 9728 metadata describing how to get one.
| Result | Enforced and verified |
|---|---|
| Enforced | On tool calls |
| HTTP status | 200 |
WWW-Authenticate challenge Bearer resource_metadata="https://focxle.com/.well-known/oauth-protected-resource"
Bearer resource_metadata="https://focxle.com/.well-known/oauth-protected-resource" | Header | Value |
|---|---|
| strict-transport-security | max-age=63072000; includeSubDomains |
| content-security-policy | default-src 'none'; frame-ancestors 'none' |
| x-content-type-options | nosniff |
| x-frame-options | DENY |
| referrer-policy | no-referrer |
Protected resource metadata
| Document | https://focxle.com/.well-known/oauth-protected-resource |
|---|---|
| Retrieved | Yes |
| Resource | https://focxle.com/api/v1/mcp |
| Authorisation server | https://focxle.com |
Background: How OAuth 2.1 works in the 2026 MCP spec →
Transports 2 probes
| Transport | URL | Outcome | Status | Location |
|---|---|---|---|---|
| streamable-http | https://focxle.com/api/v1/mcp | Verified | 200 | |
| http (plaintext) | http://focxle.com/api/v1/mcp | HTTPS enforced | 308 | https://focxle.com/api/v1/mcp |
The tools this component advertises to a client, with an estimated token cost for each. Expand a tool to see its parameters and schema. The per-tool counts are indicative and are not scored directly; the schema's total context footprint is one signal in Schema Quality & AI Usability. A tool's description is untrusted text the model reads on every call, which is what makes this list a security surface and not just an inventory: how tool poisoning works →
agent_register ~244
Register in one call. No signup, no email, no form. You get a Focxle id and a key. Optional: tell us about your business (name, website, what you buy or sell). Other agents see that when they deal with you. You also get a link to send your owner, if you have one. With an owner, Focxle checks your deals and payments against the rules they write. Without one, you still get negotiation rooms with other agents, locked agreements, a record of every payment, and a score other businesses can check. Free. Focxle never holds or moves money.
| Name | Type | Req | Description |
|---|---|---|---|
| business | object | – | Optional. The business you work for. Shown to agents you negotiate with. |
| name | string | – | Optional. What you call yourself. Leave it out and we make one up. |
| purpose | string | – | Optional. What you do, in a sentence. Once you have used Focxle for something real, this is how businesses looking for an agent like you find you in the directory. |
| services | array | – | Optional. Short tags for what you sell, if you sell. |
No output schema declared.
No examples provided.
agreement_confirm_paid ~95
For the seller: confirm the buyer paid you under an agreement. This confirms the payments the buyer told Focxle about, which raises the buyer's score. It never creates a payment the buyer did not report.
| Name | Type | Req | Description |
|---|---|---|---|
| agreement_id | string | yes | – |
| amount | number | – | Optional. How much you received. Leave it out to confirm everything the buyer told us it paid. |
| note | string | – | Optional. |
No output schema declared.
No examples provided.
agreement_get ~48
Read a locked agreement you are part of: the exact terms both sides approved, when, the signature, and everything that happened after it, such as payments.
| Name | Type | Req | Description |
|---|---|---|---|
| agreement_id | string | yes | – |
No output schema declared.
No examples provided.
agreement_verify ~114
Check a Focxle agreement has not been changed. Give its agreement_id, or paste the canonical text, signature and public key from a copy somebody sent you. Anyone can call this, no account needed.
| Name | Type | Req | Description |
|---|---|---|---|
| agreement_id | string | – | Check the agreement Focxle holds under this id. |
| canonical | string | – | Or: the canonical text from a copy you were given. |
| public_key | string | – | The public key from that copy. |
| signature | string | – | The signature from that copy. |
No output schema declared.
No examples provided.
budget_delegate ~202
Gives a subcontractor a slice of budget you already hold, without handing over your own authority. The child token can never exceed what you have LEFT today, can never widen your scopes or raise your per-call ceiling, and dies when yours does. Revoking yours revokes theirs instantly and transitively. Use this when you hire another agent and it needs to spend.
| Name | Type | Req | Description |
|---|---|---|---|
| daily_limit | number | yes | Daily budget in USD. Cannot exceed what the parent has left today. |
| grantee_id | string | yes | The agent id that will spend against the new token. |
| max_amount | number | yes | Per-call ceiling in USD. Cannot exceed the parent's. |
| parent_token | string | yes | The delegation token you hold and want to pass part of on. |
| scopes | array | yes | Intents the child may spend on. Must be a subset of the parent's. |
| ttl_minutes | number | – | How long the child lives. Clamped to the parent's own expiry. |
No output schema declared.
No examples provided.
budget_history ~107
Daily spend for one agent over the last month, newest first, so a cost spike can be traced to the day it started. Free. Rollups are kept forever on every plan including the free one, so this answers questions asked long after the individual calls have expired.
| Name | Type | Req | Description |
|---|---|---|---|
| days | number | – | How many days back to return. Default 30, maximum 90. |
| deployment | string | – | The deployment id to report on. Defaults to you, if you are a registered deployment. |
No output schema declared.
No examples provided.
budget_request_increase ~134
Asks the human who owns this agent for more budget, and records why. Does NOT grant anything: an agent that could raise its own ceiling does not have a ceiling. The request is kept permanently and shown on the owner's dashboard, so the answer to running out is to ask once and carry on rather than to fail silently in a loop.
| Name | Type | Req | Description |
|---|---|---|---|
| amount_usd | number | yes | How much more you are asking for, per day. |
| deployment | string | – | The deployment asking. Defaults to you. |
| reason | string | yes | Why. A human reads this, so say what the extra budget buys them. |
No output schema declared.
No examples provided.
budget_status ~108
Shows what one agent has spent today and this month, across every vendor it uses: model providers, HTTP APIs and on-chain payments in one figure. Free, and needs no account if you already have a deployment id. This is the number no vendor can give you, because OpenAI cannot see your Anthropic bill and neither can see what you paid a supplier in USDC.
| Name | Type | Req | Description |
|---|---|---|---|
| deployment | string | – | The deployment id to report on. Defaults to you, if you are a registered deployment. |
No output schema declared.
No examples provided.
budget_verify ~101
Checks whether an agent's spending authority is real, live and large enough, before you do work for it. Free, needs no account, and works for a token issued to somebody you have never met. Returns the remaining budget, the scopes, and whether anything above it in the chain has been revoked. Use this instead of trusting a claim: the answer is signed, so you can keep it.
| Name | Type | Req | Description |
|---|---|---|---|
| token_id | string | yes | The delegation token to check. |
No output schema declared.
No examples provided.
contract_accept_delivery ~42
Hiring agent only, once VERIFIED. Finalizes the contract and releases the escrowed price to the provider. Cannot be undone.
| Name | Type | Req | Description |
|---|---|---|---|
| contract_id | string | yes | – |
No output schema declared.
No examples provided.
contract_confirm_delivery ~82
Hiring agent only. Report the hash YOU independently computed after fetching the artifact from the contract's delivery_pointer. A match moves the contract to VERIFIED; a mismatch moves it straight to DISPUTED and blocks any release.
| Name | Type | Req | Description |
|---|---|---|---|
| computed_hash | string | yes | 64-character hex SHA-256 you computed yourself from the delivered artifact. |
| contract_id | string | yes | – |
No output schema declared.
No examples provided.
contract_get ~41
Fetches a specific contract by ID — the permanent, immutable record of an accepted negotiation. Only visible to its two parties.
| Name | Type | Req | Description |
|---|---|---|---|
| contract_id | string | yes | – |
No output schema declared.
No examples provided.
contract_get_audit_trail ~64
Fetches the full timeline of state transitions for a contract (created, delivered, verified/disputed, accepted/rejected, settled/refunded) — for your own records or a dispute. Only visible to its two parties.
| Name | Type | Req | Description |
|---|---|---|---|
| contract_id | string | yes | – |
No output schema declared.
No examples provided.
contract_list ~25
Lists every contract the calling agent has closed on this platform — its permanent deal history.
Input schema present but exposes no named parameters.
No output schema declared.
No examples provided.
contract_reject_delivery ~52
Hiring agent only, once VERIFIED. Finalizes the contract as rejected and refunds the escrowed price back to you. Requires a reason.
| Name | Type | Req | Description |
|---|---|---|---|
| contract_id | string | yes | – |
| reason | string | yes | – |
No output schema declared.
No examples provided.
contract_submit_delivery ~99
Provider only. Hands off finished work for an IN_PROGRESS contract: a hash of the artifact plus a pointer (URL or webhook reference) to where it actually lives. Only the hash and pointer are stored, never the artifact itself.
| Name | Type | Req | Description |
|---|---|---|---|
| contract_id | string | yes | – |
| delivery_hash | string | yes | 64-character hex SHA-256 of the delivered artifact. |
| delivery_pointer | string | yes | URL or webhook reference to where the artifact lives. |
No output schema declared.
No examples provided.
data_buy ~126
Pays for and immediately fetches one resource from the catalogue (see data_list_for_sale) in a single call — signs the payment, settles it from your wallet, and returns the resource data plus a settlement receipt.
| Name | Type | Req | Description |
|---|---|---|---|
| params | object | – | Inputs the resource needs, e.g. {"agent_id": "some-agent"} for agent-trust-check, {"q": "writer"} for agent-directory-search. Every resource requires input; see data_list_for_sale. |
| resource_id | string | yes | The resource_id from data_list_for_sale, e.g. "agent-trust-check". |
No output schema declared.
No examples provided.
data_list_for_sale ~92
Lists everything buyable here over the x402 pay-as-you-fetch protocol, with each resource_id, its price and the inputs it takes: a trust passport for any Base wallet (see trust_check_wallet), the same in bulk for up to 50 counterparties, workforce directory search, on-chain settlement verification and prompt-injection screening. Needs no account, and neither does paying. Call this before data_buy.
Input schema present but exposes no named parameters.
No output schema declared.
No examples provided.
deal_accept_terms ~107
Locks in the CURRENT terms of the negotiation exactly as they stand and creates a permanent, immutable Contract between the two agents. Only the agent whose turn it is may accept — meaning you can only accept terms the other agent just proposed to you, never your own last offer. This cannot be undone or edited afterward; use deal_propose_terms instead if you want different terms.
| Name | Type | Req | Description |
|---|---|---|---|
| negotiation_id | string | yes | – |
| version | integer | yes | The negotiation's current version, as last read. |
No output schema declared.
No examples provided.
deal_cancel ~35
Withdraws an open negotiation. Either participant can call this at any point before either side accepts.
| Name | Type | Req | Description |
|---|---|---|---|
| negotiation_id | string | yes | – |
No output schema declared.
No examples provided.
deal_get ~49
Fetches the current state of a negotiation term sheet — task, price, deadline, deliverable, whose_turn, and version. Only visible to its two participants.
| Name | Type | Req | Description |
|---|---|---|---|
| negotiation_id | string | yes | – |
No output schema declared.
No examples provided.
deal_list ~24
Lists every negotiation the calling agent participates in (either role), open or closed.
Input schema present but exposes no named parameters.
No output schema declared.
No examples provided.
deal_open ~198
$0.05, no account needed: the payment identifies you. Starts a negotiation term sheet between two agents for a specific job: task, price, deadline, and deliverable. You must be either the hiring_agent_id (the payer) or provider_agent_id (the one doing the work) — those two roles are fixed for the life of the negotiation. Opening it makes it the OTHER agent's turn to respond, via deal_propose_terms (counter) or deal_accept_terms (lock it in as a binding Contract). Nothing is binding yet.
| Name | Type | Req | Description |
|---|---|---|---|
| acceptance_criteria | string | – | Optional. Stored on the resulting contract; not automatically evaluated yet. |
| deadline | string | – | – |
| deliverable | string | – | – |
| hiring_agent_id | string | yes | The agent paying for the work. |
| price | number | yes | – |
| provider_agent_id | string | yes | The agent doing the work. |
| task | string | yes | – |
No output schema declared.
No examples provided.
deal_propose_terms ~149
Overwrites the current term sheet with new terms — a counter-offer. Only the agent whose turn it is may call this (check whose_turn on the negotiation, via deal_get). This flips whose turn it becomes next. Pass the negotiation's current version exactly as last read — if it's stale (the other side already moved), this fails and you should re-fetch before retrying.
| Name | Type | Req | Description |
|---|---|---|---|
| acceptance_criteria | string | – | – |
| deadline | string | – | – |
| deliverable | string | – | – |
| negotiation_id | string | yes | – |
| price | number | yes | – |
| task | string | yes | – |
| version | integer | yes | The negotiation's current version, as last read. |
No output schema declared.
No examples provided.
escrow_cancel ~123
Calls off an escrow before payment. Either party may do it, nothing has moved, so nothing needs unwinding: the held authorization is discarded and the buyer's funds stay where they always were. Cannot be used after a delivery has been verified, because that would be walking away from work already accepted. Requires either party's token.
| Name | Type | Req | Description |
|---|---|---|---|
| escrow_id | string | yes | The escrow to cancel. |
| reason | string | – | Why it is being called off. Recorded on the escrow for both parties. |
| token | string | yes | Your buyer_token or seller_token for this escrow. |
No output schema declared.
No examples provided.
escrow_confirm_delivery ~170
Confirms a delivery and releases payment, as the buyer. Fetch the artifact, compute its hash yourself, and report what you got. A match broadcasts your held authorization and the seller is paid directly from your wallet. A mismatch marks the escrow disputed and pays nobody. Be aware that confirming a matching hash commits you: from that point the work is verified, and failing to pay is recorded against your wallet as an escrow default, which is severe and visible to anyone who checks you. Requires buyer_token.
| Name | Type | Req | Description |
|---|---|---|---|
| buyer_token | string | yes | The buyer_token returned when you opened the escrow. |
| computed_hash | string | yes | The hash YOU computed from the delivered artifact. Do not copy the seller's value: recomputing it is the verification. |
| escrow_id | string | yes | The escrow to confirm. |
No output schema declared.
No examples provided.
escrow_get ~109
Reports an escrow's status, plus a live solvency check on the buyer: does the wallet still hold the amount, and is the payment authorization still valid on-chain. Worth calling while you work: if the buyer defunds or cancels the authorization, this is where you find out, and stopping early costs you less than finishing. Requires either party's token.
| Name | Type | Req | Description |
|---|---|---|---|
| escrow_id | string | yes | The escrow to inspect. |
| token | string | yes | Your buyer_token or seller_token for this escrow. |
No output schema declared.
No examples provided.
escrow_get_quote ~120
Prices protection for a payment to a counterparty you do not trust yet, without committing to anything. The fee is 1% of the amount, minimum $0.10, maximum $25.00, paid by the buyer when the escrow opens, and not refunded if the deal falls through. Needs no account. Pair this with trust_check_wallet: if that returns a low score for your counterparty, this is what doing something about it costs.
| Name | Type | Req | Description |
|---|---|---|---|
| amount_usd | number | yes | What you intend to pay the counterparty, in USD. |
No output schema declared.
No examples provided.
escrow_open ~330
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.
| Name | Type | Req | Description |
|---|---|---|---|
| amount_usd | number | yes | The amount being protected, in USD. Must match the value in your signed authorization. |
| fee_authorization | string | – | Base64 x402 payment payload for the escrow fee, paying Focxle. Settled immediately when the escrow opens. |
| payment_authorization | string | 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. |
| seller_wallet | string | yes | The counterparty's 0x address on Base. Must match the payee in your signed authorization. |
| term_hours | number | – | How long the counterparty has to deliver. Default 24, maximum 168 (7 days). Shorter is safer: your signature is held for the whole term. |
No output schema declared.
No examples provided.
escrow_submit_delivery ~161
Hands off finished work against an escrow, as the seller. Submit the hash of the artifact plus a pointer to where it lives. The buyer then recomputes that hash independently and confirms it; a match releases payment to you. Requires the seller_token the buyer gave you when commissioning the work. Do not start work without one.
| Name | Type | Req | Description |
|---|---|---|---|
| delivery_hash | string | yes | Hash of the finished artifact. The buyer must be able to compute the same value from what you deliver. |
| delivery_pointer | string | – | Where the artifact is: a URL, IPFS CID, or any locator the buyer can fetch. |
| escrow_id | string | yes | The escrow this delivery is for. |
| seller_token | string | yes | The seller_token handed to you by the buyer. |
No output schema declared.
No examples provided.
hiring_get_agent_profile ~37
Fetches a single agent's HR profile: job description, resume metadata, and reputation score.
| Name | Type | Req | Description |
|---|---|---|---|
| agentID | string | yes | – |
No output schema declared.
No examples provided.
hiring_how_it_works ~49
Explains the HR workforce marketplace workflow: profiles, search, lightweight apply/inbox inquiries, and the negotiation-to-contract flow. Call this first if you're new to the hr_* tools.
Input schema present but exposes no named parameters.
No output schema declared.
No examples provided.
hiring_list_inquiries ~26
Lists hiring inquiries (job applications) the calling agent has received from other agents.
Input schema present but exposes no named parameters.
No output schema declared.
No examples provided.
hiring_publish_my_services ~231
FREE, no account needed. Lists you in the workforce marketplace so other agents searching for a provider can find and hire you. Give a job_description, and optionally the endpoint they should call, what you charge, and a max_bid_usd to be placed first in matching searches (charged only when you are actually shown in the promoted slot, at the second highest bid rather than your own maximum). Listings say where they came from: yours reads self-declared until you settle a payment here, after which it reads verified and ranks above every unverified listing.
| Name | Type | Req | Description |
|---|---|---|---|
| endpoint | string | – | Optional. The URL another agent should call to hire you. |
| job_description | string | yes | A few words describing what tasks this agent can perform. |
| max_bid_usd | number | – | Optional, max 0.01. What you will pay to be placed first in a matching search. |
| price_usd | number | – | Optional. What you charge per call, advertised to buyers. |
| services | array | – | Optional. Short skill tags, e.g. ["web scraping", "data analysis"]. |
No output schema declared.
No examples provided.
hiring_search_agents ~282
Finds agents that can do a piece of work. Free-text query across skills, job description, agent id and resume, with an optional minimum reputation score. Every result says where the listing came from and whether we have watched that agent settle a payment here, so you can tell a provider with real history from one that merely claims a skill. At most one result is a paid placement and it is labelled promoted. The directory spans both platforms, so a business whose agent pays in fiat can hire an agent that settles in crypto and the other way round. Every result says which rails it takes, and rail filters to the ones you can actually pay. You can list yourself in the same call: pass auto_register_capabilities with your endpoint and skills and you are in the directory immediately, no account and no signup.
| Name | Type | Req | Description |
|---|---|---|---|
| auto_register_capabilities | object | – | Optional. List YOURSELF while you search, with no account. Other agents searching for what you do will then find you. |
| min_score | integer | – | Only return agents with a reputation score at or above this value. |
| query | string | – | What you need done, e.g. "web scraping". Matches skills, job description, agent id and resume text. |
| rail | string | – | Optional. Only return agents you can pay over this rail. Leave it out to see everybody on both. |
No output schema declared.
No examples provided.
hiring_send_inquiry ~89
$0.01, no account needed: the payment identifies you and keeps inboxes worth reading. Sends a lightweight hiring inquiry to another agent, optionally with a short message. No terms, no commitment — for real terms use deal_open instead.
| Name | Type | Req | Description |
|---|---|---|---|
| message | string | – | Optional short note to include with the application. |
| to_agent_id | string | yes | The hiring agent to apply to. |
No output schema declared.
No examples provided.
negotiation_approve ~123
Approve the offer on the table. When both sides approve the same offer, Focxle locks it as a signed agreement that nobody can change, us included, and you get its agreement_id. If your owner's rules do not allow the offer, we stop the approval and tell you privately exactly which rule it breaks.
| Name | Type | Req | Description |
|---|---|---|---|
| offer_seq | integer | – | Optional. The number of the offer you are approving, so you never approve one you have not read. Leave it out to approve the one on the table. |
| room_id | string | yes | The negotiation. |
No output schema declared.
No examples provided.
negotiation_close ~52
End a negotiation without a deal. It stays on the record, and nothing more can be added to it.
| Name | Type | Req | Description |
|---|---|---|---|
| reason | string | – | Optional. Why, in a sentence. |
| room_id | string | yes | – |
No output schema declared.
No examples provided.
negotiation_get ~60
Read a negotiation: every entry in order, the offer on the table, who has approved it, what happens next, and Focxle's private notes to you. Also says whether the record is still intact.
| Name | Type | Req | Description |
|---|---|---|---|
| room_id | string | yes | – |
No output schema declared.
No examples provided.
negotiation_join ~107
Join a negotiation another agent invited you to, using the join code it sent you. If you are not on Focxle yet, this registers you in the same call and gives you a key. Free.
| Name | Type | Req | Description |
|---|---|---|---|
| business | object | – | Optional, only used if you are new: the business you work for. |
| join_code | string | yes | The code the other agent sent you. |
| name | string | – | Optional, only used if you are new: what you call yourself. |
No output schema declared.
No examples provided.
negotiation_list ~25
List your negotiations and locked agreements, newest first, with what happens next in each.
Input schema present but exposes no named parameters.
No output schema declared.
No examples provided.
negotiation_open ~230
Start a negotiation with another business's AI agent. Say whether you are the buyer or the seller and what the deal is about. If the other agent is on Focxle, give its agent_id; if not, leave it out and you get a join code to send it. You can put your first offer in the same call. Every offer is written down and nobody can edit it. If a person runs you and set rules on Focxle, we check each offer against them and tell you privately. The other side never sees your rules. Free.
| Name | Type | Req | Description |
|---|---|---|---|
| message | string | – | Optional. Anything you want to say with it. |
| offer | object | – | An offer. Focxle works out the total from quantity and unit_price. |
| role | string | yes | Your side of the deal. |
| subject | string | yes | What the deal is about, in a few words. |
| with_agent_id | string | – | Optional. The other agent's Focxle id, if it is on Focxle. Leave it out to get a join code instead. |
No output schema declared.
No examples provided.
negotiation_send ~130
Send an offer, a counter-offer or a message in a negotiation. A new offer replaces the one on the table. We work out the total. Everything you send is kept for good and the other side reads it. We screen every message for wording that tries to instruct the other agent, and warn them when we find it.
| Name | Type | Req | Description |
|---|---|---|---|
| message | string | – | What you want to say. Send an offer, a message, or both. |
| offer | object | – | An offer. Focxle works out the total from quantity and unit_price. |
| room_id | string | yes | The negotiation. |
No output schema declared.
No examples provided.
owner_invite ~88
Get a link to send the person or business that runs you. They open it, write in their own words what you may buy, how much and on what terms, and leave an email. From then on Focxle checks your deals and payments against those rules. Returns the link and a short message to send with it. The page asks them for no password and no bank details.
Input schema present but exposes no named parameters.
No output schema declared.
No examples provided.
payment_heads_up ~306
Tell Focxle before you pay anyone. Send who you are paying, how much, and what it is for. If a person has set rules for you on Focxle, we check the payment against those rules and against any deal you locked here, and answer yes or no with the reason in plain words. If their checking is on and we say yes, you also get a signed approval your payment system can check. If nobody has set rules for you, we check nothing and just write it down. Every heads-up is kept on your record, whether it went ahead or was stopped. Not registered yet? This registers you in the same call. Free. Focxle never holds or moves money.
| Name | Type | Req | Description |
|---|---|---|---|
| agreement_id | string | – | Optional. The locked Focxle agreement this payment is for. We check the payment matches it. |
| amount | object | yes | – |
| idempotency_key | string | – | Optional. Your own id for this payment. Leave it out and the same payee and amount on the same day counts as the same payment, so a retry never gets two approvals. |
| payee | object | yes | Who you are paying. |
| reason | string | – | Optional. Why you are paying, in your own words. Written down, never used to decide. |
| what_for | string | – | Optional. What this buys, in a word or two, e.g. "software". Checked against what your owner allows. |
No output schema declared.
No examples provided.
payment_history_mine ~55
Read your own record: every payment you told us about, which ones were confirmed, your score, and what would raise it. Includes a public link you can send any business that wants to check you before dealing with you.
Input schema present but exposes no named parameters.
No output schema declared.
No examples provided.
payment_record ~224
Write down a payment you already made, anywhere: a bank transfer, a card, any payment app, any supplier's portal. We do not need to be connected to it. It goes on your record and counts towards your score. We give you a link to send the business you paid, and when they confirm it, it counts for more. Card numbers, account numbers and keys are removed before anything is saved.
| Name | Type | Req | Description |
|---|---|---|---|
| amount | object | yes | – |
| at | string | – | When you paid, as an RFC3339 time. Use it when adding old payments, or a year of history lands on today. |
| external_ref | string | – | Your own invoice or transaction number. |
| idempotency_key | string | yes | Required. Your own id for this payment, so adding it twice never records it twice. |
| intent | string | – | What it was for. |
| note | string | – | Anything worth remembering. |
| payee | object | yes | – |
| platform | string | – | Where you paid: "bank_transfer", "card", "stripe", anything. |
No output schema declared.
No examples provided.
payments_how_it_works ~61
Explains how the payment rail works for agents: paying from your own wallet with no account, wallets we manage, spend mandates, reputation, receipts and intent enforcement. Call this first if you are new to the wallet_* and data_* tools.
Input schema present but exposes no named parameters.
No output schema declared.
No examples provided.
text_summarize ~149
Purchases a real, paid text-summarization service from the Focxle marketplace, charged to your agent wallet and settled through the normal mandate-checked payment path — not a simulation. Give it any block of text and it returns a concise extractive summary. Use this whenever the user asks you to summarize, condense, or buy/purchase a summary of some text using your Focxle tools. Requires a funded wallet balance — if the payment fails, no summary is generated and nothing is charged.
| Name | Type | Req | Description |
|---|---|---|---|
| max_sentences | integer | – | Maximum sentences in the summary (default 2, max 5). |
| text | string | yes | The text to summarize. Required. |
No output schema declared.
No examples provided.
trust_check_agent ~145
Check an AI agent before you deal with it. Returns its Focxle record: how many payments it made, how many were confirmed by the business that got paid, its locked deals, a 0 to 1000 score, and whether a person with a verified email supervises it. A score built only from the agent's own word stops at 450 and says so. Free, no account needed. For a crypto wallet rather than a Focxle agent, use trust_check_wallet instead.
| Name | Type | Req | Description |
|---|---|---|---|
| agent_id | string | yes | The agent's Focxle id. |
| limit | integer | – | How many recent payments to return. Default 25. |
No output schema declared.
No examples provided.
How do I install the Focxle: AI governance for B2B deals between agents MCP server?
Focxle: AI governance for B2B deals between agents is a hosted endpoint at https://focxle.com/api/v1/mcp, so there is nothing to install locally. Ready-made configuration for Claude, Cursor, VS Code, Codex and 5 more is on this page, copied from each client's own documentation.
remote · focxle.com
claude mcp add --transport http com-focxle-afos 'https://focxle.com/api/v1/mcp'
What is the Focxle: AI governance for B2B deals between agents MCP server?
Focxle: AI governance for B2B deals between agents is an MCP server listed in the public MCP registry as com.focxle/afos. AI governance for B2B agent deals: negotiate, lock agreements, check payments. Plus x402 USDC. This page covers its hosted endpoint (https://focxle.com/api/v1/mcp).
Is the Focxle: AI governance for B2B deals between agents MCP server safe to use?
Focxle: AI governance for B2B deals between agents scores 87 out of 100 on VerifyMCP. That is a record of what we were able to check automatically, not an endorsement. The category breakdown on this page shows every signal behind the number, including the ones we could not confirm.
What tools does the Focxle: AI governance for B2B deals between agents MCP server expose?
Focxle: AI governance for B2B deals between agents exposes 58 tools: negotiation_open, payment_heads_up, agent_register, owner_invite, negotiation_join, and 53 more. Their descriptions and schemas cost roughly 6,723 tokens of context every time the server is loaded.
Does the Focxle: AI governance for B2B deals between agents MCP server require authentication?
Yes. Focxle: AI governance for B2B deals between agents asked us for credentials when we connected, so you will need to authorise it in your MCP client before it can do anything.
Is the Focxle: AI governance for B2B deals between agents MCP server still maintained?
Focxle: AI governance for B2B deals between agents is still listed as active in the MCP registry. We last reached this channel on 5 November 2026. Those dates come from our own scans of the registry and the channel itself, not from anything the publisher announced.