Add o1.exchange trading plugin

[JerryPan2718]

Summary

• Adds a new Base MCP plugin for the o1.exchange trading API
• Supports token swaps on Base and BSC via http-api integration → send_calls
• Includes Bearer token auth, MEV protection, optional Permit2 gasless approvals, and slippage controls

Test plan

• Verify frontmatter conforms to plugin-spec.md (chains, integration type, risk tags, auth)
• Confirm api.o1.exchange is reachable and /order endpoint returns expected unsigned tx shape
• Validate send_calls mapping: { to, data, value } from unsigned object, gasLimit/chainId stripped
• Test example prompts end-to-end on Base with a real API token: we will use a pre-generated token

🤖 Generated with Claude Code

[cb-heimdall]

🟡 Heimdall Review Status

Requirement	Status	More Info
Reviews	🟡 0/1	Denominator calculation Show calculation 1 if user is bot 0 1 if user is external 0 2 if repo is sensitive 0 From .codeflow.yml 1 Additional review requirements Show calculation Max 0 0 From CODEOWNERS 0 Global minimum 0 Max 1 1 1 if commit is unverified 1 Sum 2

[stephancill]

Thanks for the submission. The documented endpoints resolve and the response shapes match, but the Permit2 signing flow has a blocking issue:

Required

• The Permit2 flow string-replaces a fixed 65-byte SIGNATURE_PLACEHOLDER in unsigned.data with the signature. This only holds for EOA signatures. Base smart-account signatures (ERC-1271/6492) are variable-length (unbounded; >200 bytes in practice) and the signature is ABI-encoded as a dynamic bytes field with a length prefix and offset. Splicing such a signature into a fixed 65-byte slot produces malformed calldata, so the flow fails for smart-contract wallets — the common Base account type. Encode the signature as dynamic bytes (and support ERC-1271 verification), or have the build endpoint accept the signature and re-encode server-side.

Minor

• Submitting the order through send_calls bypasses o1's /order/complete private-mempool relay, so mevProtection does not apply to these submissions. State this so it isn't presented as MEV-protected.
• The API-token URL is inconsistent across sections; use the one that resolves.
• ## Auth should document token lifetime/refresh, and ## Submission should state the value hex-wei contract.
• Consider adding low-liquidity to risk for arbitrary-token / pool-targeted trades.

[youssefea]

Note: this is an AI-generated review. An automated, read-only API/endpoint health check — not a human review.

Thanks for putting this together — the o1.exchange integration is shaping up well. As part of reviewing the Wave 2 submissions I ran an automated, read-only health check against the APIs this plugin documents. The endpoints themselves look healthy; there's one signing-flow item worth addressing before merge, plus a couple of notes:

Findings

• Blocking — Permit2 flow uses a fixed 65-byte EOA signature placeholder. Orchestration step 3 of the Permit2 swap says to replace 0x42f6…62ff1b in unsigned.data with the signature from sign. That placeholder is exactly 130 hex chars (65 bytes, trailing v=0x1b) — an EOA r||s||v signature. The default Base MCP wallet is a smart contract, so sign (eth_signTypedData_v4) returns a variable-length ERC-1271/6492 signature much longer than 65 bytes. A fixed-width string-replace into the calldata will either fail or produce malformed calldata, and no length/offset update is documented. The Permit2 path is broken for the default wallet.
• POST /api/v2/order and POST /api/v2/order/complete (host api.o1.exchange): both return 401 {"success":false,"code":401,"message":"Unauthorized: Missing or invalid token"} unauthenticated, and a fake Bearer token also returns 401 Unauthorized. This positively confirms the auth: api-key claim — the endpoints are real and gated. The authenticated 200 response shape (transactions[].unsigned, permit2.eip712) could not be verified read-only without a token; only the {success, code, message} error shape was observed.
• OPTIONS /api/v2/order returns 404 ("No matching routes found") — no CORS preflight route. Fine for harness/server-side web_request, but the chat-only web_request path in "Surface Routing" may hit a CORS preflight against this host; worth confirming.
• Allowlist is correct: requires.allowlist: [api.o1.exchange] matches the only programmatically-contacted host; o1.exchange is a human-facing token-generation URL only.
• value is documented as hex (0x…) and gasLimit/chainId are stripped before send_calls, so there is no decimal-to-hex gap. The partner unsigned.to (router) is passed straight into send_calls without validation against a documented router constant — acceptable given the authenticated build API, but noted as untrusted-calldata surface.

What was checked

Read-only probes only: dig/curl -sI for DNS+TLS on api.o1.exchange and o1.exchange; unauthenticated and fake-Bearer POSTs to /api/v2/order and /api/v2/order/complete with empty and deliberately-invalid bodies (HTTP status + JSON error shape vs the doc, and auth-claim verification); OPTIONS/GET method probes; and byte-length analysis of the documented Permit2 placeholder signature. No SDK/CLI package or on-chain contract addresses are documented, so none required npm view or cast code checks. This was strictly read-only: no transactions were submitted, no funds were moved, and no API keys were used.

Really appreciate the contribution — happy to clarify any of the above. Since this is an automated check, please double-check anything that looks unexpected on your end before changing it.

---

Generated by an AI assistant (Claude) after an automated, read-only deep analysis of the API/endpoint health documented in this plugin. It checks endpoint reachability, HTTP status codes, response shapes, auth behavior, SDK/package existence, and on-chain contract presence — it does not submit transactions or move funds. Please independently verify any finding before acting on it.

[youssefea]

Is it possible to do this without a bearer token? This is too painful to the users. Ideally, you can make the users auth with sign_message tool from the Base MCP and give the agent an access token if you need an API key. Or you can include an API key in the plugin md file (see uniswap.md)