Skip to main content
Glama
261,129 tools. Last updated 2026-07-05 11:20

"namespace:com.onrender.synmerco-escrow" matching MCP tools:

  • Buyer-side: accept a seller's bid and open escrow. Bridge opens escrow, builds and signs the COSE_Sign1 Acceptance document, and routes to native chain. LOCK: the chain locks EXACTLY the agreed price into escrow at accept — no gas bond and no fee is added at accept (the 1% settlement fee comes out of escrow at settle; the response itemizes price_locked/gas_bond_locked/total_locked). An under-funded buyer gets a structured insufficient_balance error with need/have/shortfall in µCOSR. Returns {accepted, acceptance_id_hex, escrow_pda_hex, agreed_price_micro, price_locked_micro_cosr, gas_bond_locked_micro_cosr, total_locked_micro_cosr, delivery_deadline_height, estimated_unlock_in_seconds, estimated_unlock_note, settlement_window_note, agent_id_hex, chain_result}. delivery_deadline_height is the CHAIN-HEIGHT deadline that gates thread.expire_escrow (not the acceptance deadline_slot); estimated_unlock_in_seconds is the EXPECTED WALL-CLOCK time until your escrowed capital can be recovered IF THE SELLER NEVER DELIVERS (the no-show clock, derived from the block rate) — read this, not the deadline_slot, to know when funds actually free. settlement_window_note names the SECOND clock: once the seller DOES deliver, settle or file_dispute before the settlement window lapses or the escrow auto-releases to the seller (poll_delivery.auto_release surfaces that exact deadline).
    Connector
  • Expire an open escrow whose delivery deadline has passed (§13.7 A5c). DEADLINE GATE (read carefully): the chain enforces delivery_deadline_height — the CHAIN-HEIGHT deadline stamped at accept_bid (returned by thread.accept_bid as delivery_deadline_height) — NOT the acceptance document's deadline_slot (bridge slot clock). Calling after deadline_slot but before the chain height passes returns a structured escrow_not_expired error carrying both heights so you know exactly when to retry. No settlement fee deducted — full agreed_price_micro returned to buyer. Any registered agent may call; chain validates deadline independently. The buyer can alternatively use thread.refund_escrow (buyer-signed, ungated by the deadline). Returns {accepted, status, bid_id_hex, chain_escrow_id_hex, expired_micro, deadline_slot, chain_tx_result}.
    Connector
  • Get the wallet address and hiring details for a skill listing — skipping the job board entirely. Use this when you've found a skill provider via list_marketplace_skills() and want to hire them directly without going through the bid/award process. Returns the worker's XRPL wallet address and ready-to-use escrow instructions. No funds move — you still create the escrow yourself via create_escrow_vault(). Typical flow: 1. list_marketplace_skills() — browse and find a provider 2. direct_hire(skill_id) — get their wallet address + escrow instructions 3. create_escrow_vault(worker_address=..., amount_xrp=...) — lock payment on XRPL Returns: worker_address, rate, title, direct_hire_hint (escrow creation instructions).
    Connector
  • ESCROW FLOW ONLY. Direct-settlement tasks never get funded — the client pays the operator directly on-site. Calling this on a direct-settlement task returns 400. Fund a quoted task using wallet balance or PSP payment — second step of the escrow funding flow. Precondition: task must be in Quoted status AND settlementMode='escrow'. If not, call request_task_quote first. Two funding methods: 'wallet' (instant, requires sufficient available balance) or 'psp' (returns a hosted checkout URL — payment must be completed by your principal, then the task auto-funds). IMPORTANT — money flow: the wallet is always the single source of truth for your balance. PSP payments follow a two-step path: (1) Stripe/PSP credits your wallet with the paid amount, (2) the amount is locked from your wallet onto the task. This means if the task is cancelled BEFORE an operator accepts, the money stays in your wallet for future tasks — it does not auto-refund to your card. For wallet funding the flow is simpler: the amount is debited from wallet balance and locked on the task in a single step. The check_task_funding response exposes this via a fundingTrace array (e.g. ["psp_payment_received","wallet_credited","task_locked"]). Mechanism: the funded amount (totalAgentCost from the quote) is reserved and locked from your wallet. Locked funds remain in escrow until you approve the task, when they move to the operator. Fallback for wallet fundingMethod with insufficient balance: switch to 'psp', or call checkout_wallet_deposit / get_bank_transfer_details to top up first. The response's nextActions array always shows the appropriate next step. Idempotent: calling again on an already-funded task is safe — it detects the existing funding and returns the same checkout URL for psp. Next: publish_task after wallet funding. After psp funding, the task is auto-funded when the payment webhook arrives — call check_task_funding to poll if no webhook is configured. Response field 'chargedAmount' is what the PSP charges (payout + agent platform fee). The legacy 'grossAmount' field carries the same value and will be removed in v2 — use 'chargedAmount'. This is distinct from the quote response where 'grossAmount' means the operator payout before fees (that is also exposed there as 'operatorPayoutAmount'). Requires authentication.
    Connector
  • Bidirectional: poll trade state for either party. Returns {acceptance_id_hex, state, delivery_id_hex, output_hash_hex, settled, auto_release?}. Provide either acceptance_id_hex or bid_id_hex. Seller: call with bid_id_hex to discover acceptance_id_hex after buyer accepts. Buyer: call with acceptance_id_hex to check if delivery arrived. State transitions: pending → accepted → delivered → settled. WHEN A DELIVERY HAS ARRIVED (state=delivered, not yet settled, no live dispute) the response carries auto_release:{settle_or_dispute_by_slot, auto_release_slot, current_slot, slots_remaining, estimated_auto_release_in_seconds, note} — the SETTLEMENT clock: thread.settle or thread.file_dispute BEFORE auto_release_slot, else the escrow auto-releases the full price to the seller and your silence is reputation-marked. For ONGOING monitoring, poll from deterministic (non-LLM) code on a fixed low-frequency interval; invoke your LLM only when state actually advances (e.g. a delivery to check). Do NOT poll inside an LLM loop.
    Connector
  • Browse available escrow arbitrators. Returns their wallet address, fee (in basis points, e.g. 500 = 5%), specialties, SLA, health status, and dispute track record. Use this before create_job_offer with payment_mode=ESCROW to pick an arbitrator. No authentication required.
    Connector

Matching MCP Servers

Matching MCP Connectors

  • Trust-minimized USDC escrow for autonomous agent transactions

  • Agent-to-agent escrow on Base. Post quests with ETH/USDC bounties and settle on-chain.

  • Sign a release OR refund authorization for an open escrow once the outcome is reported/verified. SaSame ed25519-signs a portable authorization {escrow_id, outcome, amount, ts} that an external settlement venue (smart contract / processor) consumes to move the funds — SaSame itself holds and moves nothing. Terminal: once an escrow is released or refunded it is settled and cannot be re-attested (double-release is refused). NOTE: SaSame signs what is reported/verified — for objective conditions pair it with audit_mcp; for subjective deliverables it attests the reported outcome, not independent proof of quality.
    Connector
  • Choose-package + pay stage — start the paid listing (needs prop_id + token). Step after `beycome_create_property`. Calls GET /mls/initial-load (loads the listing's MLS data) then POST /payments/stripe-checkout (creates a Stripe checkout for the chosen package/premium). Requires ``prop_id`` and ``access_token``; set ``pay_amount`` / ``pay_premium_opt`` for the selected package. The property must be eligible — a bare draft returns "not eligible". After payment, fill the questionnaire via `beycome_mls_questionnaire`. Package catalog — the chosen references feed ``pay_premium_opt``. Base packages (choose exactly one): - 146 — Basic — listed on your local MLS + syndicated (Zillow, Redfin, Realtor.com) — $99 - 145 — Basic + Title — $199 - 263 — Enhanced — Basic plus professional photos + drone — $399 - 291 — Concierge — full-service, everything included — $999 Add-ons (optional, any number): - 233 — 25 Professional HD Photos — $189 - 30 — Beycome Spotlight (Featured) Listing — $29 - 236 — 3D Tour — $99 - 235 — Drone — $99 - 234 — Premium Title / Escrow ($99 settlement) — $99 - 286 — Home Warranty (Armadillo) — $19.99 - 262 — Full CMA report — $65 - 261 — Broker support (contract / legal) — $199 - 284 — Reset days-on-market to 0 — $79 - 35 — 1x Pro Yard Sign — $34.99 - 43 — 1x Keylock Box — $30 - 42 — Open House Signage Kit — $44.99 How to use: present these to the user, let them choose one base package plus any add-ons, then join the chosen references with ``|`` into ``pay_premium_opt`` (e.g. ``146`` alone, or ``146|233|30`` for Basic + photos + featured). Don't double up: Enhanced (263) and Concierge (291) already include professional photos and drone — do not also add 233 / 235 / 236 to those tiers. Note: these are standard prices; the final amount is confirmed on the checkout page the tool returns, and a few states (e.g. TX, NC) can differ.
    Connector
  • Make an HTTP API call with manual escrow protection. Full control over verification and timelock parameters. For most payments, use safe_pay instead — it auto-configures protection based on seller trust. Use x402_protected_call when you need: - Custom JSON Schema verification (not just "valid JSON + 2xx") - Hash-lock verification (exact response match) - Specific timelock durations - To override safe_pay's trust-based amount limits
    Connector
  • Get your wallet balance for a specific currency. Default currency resolution when omitted: (1) if you pass currency explicitly it's honored, (2) if you have exactly one wallet that one is used, (3) otherwise the currency of your most recently created task. No stale USD default. Returns four numbers — understand them before funding a task: totalFunded = lifetime credit ever added to this wallet (gross deposit history). pendingBalance = funds the platform expects from in-flight PSP payments / bank transfers but has not yet confirmed (e.g. checkout in progress, IBAN deposit unreconciled). reservedBalance = funds earmarked for tasks that are quoted but not yet fully funded (soft hold). lockedBalance = funds in escrow for active tasks (Funded → ProofUploaded → UnderReview); released to the operator on approve, refunded on reject/cancel. availableBalance = totalFunded − reservedBalance − lockedBalance − pendingBalance — this is what you can spend on new tasks RIGHT NOW. The response also includes a 'locks' array breaking down lockedBalance into per-task entries (taskId, taskTitle, taskStatus, lockedAmount, lockedAt) so you know exactly which tasks are holding your funds. Use this before fund_task to verify you have sufficient available funds. For all currencies at once, use list_wallets. Requires authentication.
    Connector
  • ESCROW FLOW ONLY. Direct-settlement tasks (settlementMode='direct') skip quote/fund entirely — they go Draft → publish_task directly because there is no escrow. If you accidentally call this on a direct-settlement task the platform returns 400 with a pointer to publish_task. Request a fee calculation for a task — first step of the escrow funding flow. Precondition: task must be in Draft or Quoted status with a payoutAmount set, AND settlementMode='escrow'. Calling this on an already-funded task returns an error. Mechanism: the platform calculates split fees — a platform fee charged to you (agent) on top of the payout amount, plus a platform fee deducted from the operator's payout. The total you pay is totalAgentCost (= payoutAmount + platformFeeByAgent). Returns the fee breakdown plus a wallet status object showing whether your balance is sufficient. Fallback: if your wallet balance is insufficient, the response's nextActions array offers FundViaPsp (per-task hosted checkout), checkout_wallet_deposit (top up wallet first), and get_bank_transfer_details (IBAN top up). Pick whichever matches your funding pattern. Next: fund_task with the chosen fundingMethod, then publish_task. Requires authentication.
    Connector
  • Create a task for human executors. Cost = reward × max_executors × 1.2 (20% platform fee), charged from your balance into escrow. Write title and description IN RUSSIAN, clearly, with acceptance criteria — executors are real people in Russia. Returns task_id.
    Connector
  • Dev-mode-only: request COSR for testing. Mints up to 100 COSR (100_000_000 µCOSR) per call into the caller agent's chain balance via the bridge's reserve-verifier role (CapitalEntry path). Pass micro_cosr (number or numeric string) for an exact amount, or omit it for the full per-call amount — enough to fund a multi-demand round in one call. Use this if you need COSR to participate (e.g., for accept_bid escrow lockup; a multi-demand buyer can fund all its escrows in one call). FEE: the chain deducts the 0.1% mint fee (I193) from every capital entry — you are CREDITED NET (1 COSR minted → 999,000 µCOSR credited); the response itemizes it. Budget for the fee when topping up to a target balance. FLOOR: capital entries below 0.1 COSR (100,000 µCOSR) are rejected (capital_entry_below_floor). Token-bucket rate-limited per agent_id (10 calls/h; bucket of 10 immediate calls). DISABLED in production (THREAD_DEV_FAUCET unset). Returns {accepted, agent_id_hex, micro_cosr_minted, mint_fee_micro_cosr, micro_cosr_credited, balance_after_micro_cosr, chain_tx_result}.
    Connector
  • Co-sign a PENDING delivery-deadline extension (§13.7b). The counterparty (the party who did NOT propose) calls this with extension_id_hex; the bridge adds the second signature, assembles the two-signature DeliveryExtension document, and moves the escrow's effective deadline outward — deferring the §13.7a auto-refund/expiry until the agreed new deadline. Only after BOTH signatures does the deadline actually change (I357). Up to DELIVERY_EXTENSION_MAX (10) extensions per escrow. Returns {accepted, extension_id_hex, status:'agreed', effective_deadline_slot, late_penalty_bps, agreeing_role}.
    Connector
  • Join an open **work cell** by locking its required stake. Transfers `stake_required` of the stake mint from the configured signer into the cell's escrow and registers the signer as a participant (also creating its on-chain `TrustScore` account on first join). When the last seat fills, the cell flips Open → Active and submissions can begin. Fails if the cell is full or already active.
    Connector
  • Create a **parametric insurance policy** on the FoundryNet devnet program. The configured signer is the insurer and funds `coverage_amount` into a program escrow. A payout to `beneficiary` fires only when an oracle attests the canonical `trigger_field` crossed `trigger_threshold` in `trigger_direction` and persisted for `trigger_duration_secs`; otherwise the escrow returns to the insurer at expiry.
    Connector
  • Post a job to the AgentTrust job board. No fee, no funds held. Worker agents discover the job via list_open_jobs(), submit bids via submit_bid(), and you negotiate. When happy, call award_job() to accept a bid and get the worker's wallet address. Then create the bilateral XRPL escrow via create_escrow_vault(). Returns: status: "posted", job_id, expires_at, next_step.
    Connector
  • What M-Kliniki is, the services it offers in Kenya, and how its escrow payments work. Call this to describe M-Kliniki accurately to a user.
    Connector
  • Prepare a transaction to cancel an open (unassigned) job. Only the employer can cancel. Escrow is returned.
    Connector