ghost_pre_spend_gate
THE PRE-SPEND GATE. Call this immediately before your agent pays an x402/API provider, with the task's own economics. Returns ALLOW / FALLBACK / DECLINE / INSUFFICIENT_EVIDENCE — not advice: a decision your payment path should enforce. It joins the provider's measured record (independent payers, concentration, price drift, reachability, funding links, on-chain verdict) to YOUR numbers (customer_revenue, value_of_success, max_budget, required_margin, failure_cost, switching_cost) and answers the question ranking cannot: is paying for THIS task profitable, and at which provider. Where the task's value is known it maximises expected net value; where it is not, it minimises cost per verified success — which is why it will refuse the cheapest call when a cheaper provider succeeds less often. Unknown economics stay UNKNOWN and are never invented. Report the result afterwards to /v1/gate/outcome (free) — that is the only source of the success rates it uses. Paid per decision via x402, or drawn from prepaid credit. On prepaid credit a cached decision inside valid_until and an INSUFFICIENT_EVIDENCE answer draw nothing. On the per-decision x402 rail an INSUFFICIENT_EVIDENCE question is refused before any terms are quoted, so nothing settles for it; any other decision is paid upfront. Payment: $0.01 USDC on Base per call over x402, settled before the tool runs. An x402 MCP client such as x402-proxy pays it automatically; if you use x402-proxy, set its spend limits first (spendLimitPerTx 0.01, spendLimitDaily 0.10; see /llms.txt). A funded payment and delivery through x402-proxy has not been verified yet.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| task_id | Yes | ||
| currency | No | USD | |
| task_type | Yes | What kind of job this is. Success history is pooled under it, so it must be stable. | |
| max_budget | No | ||
| failure_cost | No | ||
| revenue_models | No | Optional. Say what the task is worth in the terms you actually measure, and Ghost derives value_of_success / customer_revenue / max_budget from it — never overriding a value you stated yourself. Each entry needs a `type`: SALES_ROI (spend, qualified_leads?, meetings?, closed_deals?, realized_revenue?), AFFILIATE_ROI (commission_rate?, order_value?, conversion_probability?, tool_cost?, inference_cost?, transaction_cost?), PROCUREMENT_SAVINGS (current_total_cost?, alternative_total_cost?, switching_cost?, migration_cost?), RETURN_ROI (expected_return, data_cost?, model_cost?, execution_cost?, expected_risk_loss?; expected_return is YOURS to state and is never estimated by Ghost), CREDIT_AFFORDABILITY (available_credit, planned_spend?). Ratios are derived only where the denominator exists; conversion rates are never invented. | |
| switching_cost | No | ||
| required_margin | No | ||
| customer_revenue | No | ||
| value_of_success | No | ||
| payment_signature | No | Leave empty when your MCP client pays automatically (e.g. x402-proxy: payment travels in _meta["x402/payment"]). Otherwise the x402 PAYMENT-SIGNATURE header value: omit it to receive the payment terms, call again with it to run the tool. | |
| success_definition | Yes | What counts as success, written down BEFORE paying. verified_success is later judged against this. | |
| fallback_authorized | No | May Ghost route to a different candidate than the first? Off by default: an unrequested reroute is a payment the operator did not choose. | |
| provider_candidates | Yes |