Litigation financing intake is moving from web forms to AI agent workflows: Custom GPT Actions, Claude projects, Cursor background agents, and MCP servers that call screening APIs. This post maps integration patterns for engineering and ops teams — anonymised, no client matter names — so agents can orchestrate pay → upload → merits without exposing privileged zip bytes inside chat context.

Keywords: MCP legal API, Custom GPT litigation, Cursor agent x402, litigation financing CLI

Developers search: litigation API for ChatGPT, MCP server legal screening, Cursor agent x402 payment, OpenAPI litigation funder, agent commerce legal tech. This article is the integration hub linking to payment rails and silo security.

Design principle: orchestrate, do not ingest privileged bytes in chat

Agents should create payment sessions, surface REF ids, and poll status — not receive 500 MB zip files as base64 in conversation history. Privileged material flows browser → silo → counsel gate → merits environment. Chat models see structured JSON (status, merits band, red flags), not raw pleadings.

Integration matrix

Custom GPT Actions setup

1. Import OpenAPI schema with POST /api/checkout, GET /v1/screen/{ref}.
2. Action: create checkout session when user asks to screen a matter.
3. Return checkout URL — user pays outside GPT.
4. After user confirms upload complete, action polls status by REF.
5. System prompt forbids inventing merits; only display API fields.

GPT cannot sign EIP-3009 — do not attempt wallet flows inside Actions.

Claude and MCP

Claude Desktop and compatible hosts can mount an MCP server exposing:

• create_checkout — returns Stripe URL
• get_screen_status — REF → JSON status
• get_merits — REF → score, red flags, burn band

MCP host holds API keys — never embed keys in model prompts. For x402, host delegates to local CLI with treasury access on a secured machine.

Cursor + CLI pattern

Background agents in Cursor commonly run:

# illustrative — use published CLI package when released
lfi screen ./dossier.zip --rail x402 --wallet treasury
lfi status REF-2026-abc123 --watch

x402 path uses @x402/fetch under the hood; Stripe path opens checkout URL for user confirmation. Agent reads terminal output — not zip content.

Recommended system prompt (full excerpt)

You assist with litigation financing screening orchestration only. Never ask users to paste privileged documents into chat. Never request seed phrases or private keys. For screening: (1) offer Stripe checkout via API or x402 via user's CLI, (2) collect REF-YYYY-… after payment and upload, (3) poll GET /v1/screen/{ref}, (4) report merits, red_flags, and status verbatim — do not invent scores or funding offers. Screening payment is not a funding commitment. Direct legal strategy questions to qualified counsel.

OpenAPI surface

• POST /v1/screen — multipart zip (402 or paid session cookie)
• GET /v1/screen/{ref} — status, merits, bids, manifest hashes
• POST /api/checkout — Stripe session URL for non-wallet agents

Distribution strategy

Widest reach: Stripe-first README, OpenAPI on GitHub, Custom GPT template in marketplace. Crypto-native: npm CLI with @x402/fetch, examples for Base mainnet. LLM traffic: indexable blog, llms.txt, FAQ blocks, cross-links between pillar posts. Enterprise: MCP server behind VPN with counsel-controlled export.

Anonymous vignette

A fund ops team wires Claude MCP to screening API. User: "Screen the Q2 dispute bundle." Agent creates Stripe checkout, user pays on phone, uploads via email link, tells agent REF. Agent polls twice, returns merits 0.71 and three red-flag tags. No zip bytes crossed into Claude's context — only JSON. Committee memo links REF to payment intent id. Matter name never entered API.

Error handling agents must surface

• 402 — payment required; do not retry without signature
• invalid_payload — wallet address mismatch; see x402 guide
• 413 — zip too large; split or reduce corpus
• quarantine — manifest lists held files; user needs counsel review

Glossary

• MCP — Model Context Protocol; tool bridge for LLM hosts
• OpenAPI Action — Custom GPT HTTP tool integration
• REF — screening reference id for polling
• Handoff — user completes payment/upload outside chat

FAQ

Will GPT Actions sign USDC? Not today — treasury signing stays in CLI or browser.

Is merits training on my zip? No — rubric informs methodology; dossiers stay in silo with counsel gate.

Can the agent upload for me? x402 CLI yes on secured host; GPT no — user or CLI upload.

API keys in prompts? Never — use host env or secrets manager.

Funding offer from merits? No — committee decision separate.

Privileged strategy in chat? Forbidden — orchestration only.

Where is OpenAPI published? Repository and docs site (check latest release).

Compliance with NDAs? Screening respects confidentiality; agents must not republish bundle text.

Testing agent integrations

1. Stripe test mode: checkout → mock upload → poll until processing clears.
2. x402 Sepolia: full 402 cycle with test wallet — never mainnet keys in CI logs.
3. Prompt injection test: zip with hostile filename — confirm quarantine in status JSON.
4. Hallucination test: ask agent for merits without REF — must refuse to invent.
5. NDA test: agent asked to summarise zip — must redirect to REF poll only.

Roadmap surfaces

Planned: public npm CLI, hosted MCP endpoint docs, Custom GPT template repo, OpenAPI 3.1 export with examples for create_checkout and get_merits. Until CLI is published, integrators should use curl + Stripe test mode and document their own thin wrappers.

Metrics ops teams track

• Time from payment to REF issued
• Time from REF to merits (export approval latency dominates)
• Rail mix (% Stripe vs x402) — signals agent adoption
• Quarantine rate per 100 uploads
• Agent-originated sessions vs human homepage

Related: silo security, payment rails, x402 on Base, llms.txt.