The Ophis server provides an intent-based DEX aggregation platform, enabling agents to parse natural language swap intents, fetch quotes, build and submit signed orders, manage referral tiers, and discover supported chains—all in a non-custodial, keyless manner. Trades are executed gaslessly with MEV protection via solver auctions across multiple EVM chains.
parse_intent: Converts a plain-English swap request (e.g., "swap 100 USDC for ETH on Optimism") into a structured intent with recognized entities (tokens, amount, chain).
get_quote: Fetches a best-execution quote for a given chain, token pair, and amount (in atoms), returning sell/buy amounts, fee, and validity.
build_order: Constructs a bounded, ready-to-sign EIP-712 CoW order with slippage enforcement, correct per-chain settlement contract, pinned receiver (owner), and embedded partner fee. Returns order object plus signing domain and types.
submit_order: Relays a pre-signed EIP-712 order to the Ophis orderbook, returning the order UID. The server never holds keys or signs.
lookup_tier: Looks up a wallet's fee-rebate tier (Bronze/Silver/Gold/Platinum) based on 30‑day volume.
list_chains: Lists supported EVM chains, distinguishing tradeable (live) from paused, with orderbook hosts, settlement contract addresses, and partner-fee configs.
The server directly supports Optimism, Unichain, and Robinhood Chain with its own solver, and routes trades through CoW Protocol's network on Ethereum, Base, Arbitrum, Polygon, BNB, Gnosis, Avalanche, and Linea. Tools and an SDK allow autonomous agents to integrate programmatically.
Enables trading on the Ethereum network via Ophis, supporting gasless, MEV-protected swaps with natural language intents.
Enables cross-chain trading destinations via NEAR Intents, allowing swaps to Bitcoin and Solana through Ophis.
Enables trading on the Optimism network via Ophis's self-hosted settlement and solver, providing gasless, MEV-protected swaps.
Enables trading on the Polygon network via Ophis, supporting gasless, MEV-protected swaps with natural language intents.
Enables cross-chain trading destinations via NEAR Intents, allowing swaps to Solana through Ophis.
Say swap 100 USDC for ETH on Base and Ophis resolves the tokens, chain, and
amount, then fills the order through a competitive solver auction that settles
on-chain. It is a fork of CoW Protocol (orderbook, autopilot,
driver, and baseline solver) with a natural-language intent layer over a
rebranded CoW Swap UI. On Optimism, Ophis runs the whole stack under its own
settlement contracts and keeps the full fee; on the other supported chains
(Ethereum, Base, Arbitrum, and more) it routes through CoW Protocol's hosted
network.
What that buys you on every trade:
Gasless, MEV-protected. Orders settle in a batch auction where every trade clears at one uniform price, so sandwiches and front-running are structurally absent, not best-effort.
Solver-aligned pricing. On every supported chain the base fee is 1 bp and Ophis earns primarily when execution beats its reference quote: 80% of improvement on volatile pairs (99 bps cap), or 50% on stable pairs (20 bps cap). Hosted chains encode that policy in CIP-75 appData and separately pay CoW Protocol's upstream fees.
Non-custodial, no account, no auth. Every order is signed in your own wallet (EIP-712 or ERC-1271). Ophis never holds keys or funds and cannot move, freeze, or recover them. The signature is the only trust boundary.
Transparent, capped fees. A 0.01% (1 bp) base plus the capped improvement policy above, with a share returned monthly as WETH rebates plus an 8% referral on trades you bring.
Live across 13 EVM chains, with Ophis-operated settlement on Optimism (chain 10), Unichain (130), and Robinhood Chain (4663), plus CoW-hosted settlement on the other supported chains.
Ophis's one bespoke API turns natural language into a structured order. No key, no account, just POST your request:
curl -sS https://ophis.fi/api/intent \
-H 'content-type: application/json' \
-d '{"text":"swap 100 USDC for ETH on Base"}'{
"ok": true,
"data": {
"intent": "swap",
"entities": [
{ "type": "amount", "value": "100", "raw": "100", "start": 5, "end": 8 },
{ "type": "sellToken", "value": "USDC", "raw": "USDC", "start": 9, "end": 13 },
{ "type": "buyToken", "value": "ETH", "raw": "ETH", "start": 18, "end": 21 },
{ "type": "chain", "value": "base", "raw": "Base", "start": 25, "end": 29 }
]
}
}Map the chain slug to a chain ID and hand the user a swap deep link to review and
sign. The endpoint only normalizes text, it never places, signs, or executes a
trade. It is rate-limited to 30 requests per minute per IP; non-browser callers
(no Origin header) are allowed, which is the path agents use. Full reference:
docs.ophis.fi/intent-api.
Related MCP server: Theagora MCP Server
Ophis is built to be traded by autonomous agents, not just people. Pick your integration depth, all of it non-custodial and keyless:
Point any MCP client (Claude, Cursor, a custom agent) at the hosted Model Context Protocol server:
https://mcp.ophis.fi/mcpIt speaks Streamable-HTTP MCP and exposes 14 tools: intent parsing, canonical
token resolution, chain discovery, quoting, bounded order build/validation and
submission, rebate and integrator lookups, balances, portfolios, gas, charts,
and expected-surplus comparison. The server holds no keys and never signs.
build_order returns a bounded, ready-to-sign EIP-712 order with the receiver
pinned to the owner; the agent signs locally with its own key and submits. See
the complete tool reference. (A bare request
without an Accept: text/event-stream header returns HTTP 406, that is the
transport negotiating, not an outage.)
For agents that build and sign CoW orders directly:
npm install @ophis/sdkThe SDK encodes four fork details that fail silently if you guess them:
getOphisOrderbookUrl(chainId) picks the right host. Optimism self-hosts
its orderbook (not api.cow.fi); the wrong host bypasses the Ophis solver and
zeroes the fee.
getOphisOrderDomain(chainId) gives the EIP-712 domain with the correct
verifyingContract. The OP settlement is non-canonical, so the cow-sdk default
is rejected on-chain.
buildOphisAppDataPartnerFee(chainId) builds the exact CIP-75 volume-fee
fragment { volumeBps, recipient }, not the price-improvement shape.
assertReceiverIsOwner(owner, receiver) pins the order receiver. An
unpinned receiver is the number one drain vector for an automated signer.
Ophis publishes machine-readable manifests for agent discovery under
https://ophis.fi/.well-known/: mcp.json, ai-plugin.json, agent-skills/,
and api-catalog (RFC 9727), plus the root-served auth.md, llms.txt, and
openapi.json.
These off-chain helpers make the safe path the easy path, but they are guards, not an authorization boundary: a prompt-injected agent can ignore them. For an agent that signs without a human in the loop, enforce policy where the agent cannot reach it: funds in a Safe smart account, a deterministic policy gate (allowlisted tokens, pinned receiver and appData, an oracle-bounded limit price, spend caps), a guardian key, and the same policy checked again at orderbook ingestion. Full guide: docs.ophis.fi/ai-agents.
Ophis settles across two kinds of chains.
Ophis-operated (self-hosted orderbook, solver, and settlement; Ophis keeps the full fee):
Chain | Chain ID | Status |
Optimism | 10 | Live: settlement, solver, partner fee |
Unichain | 130 | Live: settlement, solver, partner fee |
Robinhood Chain | 4663 | Live: settlement, solver, partner fee |
CoW-hosted (orders route through CoW Protocol's settlement and solver network, with the partner fee disbursed by CoW): Ethereum, Base, Arbitrum, Polygon, BNB, Gnosis, Avalanche, Linea, and the other CoW-supported chains, all live.
On BNB Smart Chain (BSC, chain ID 56) Ophis is live: orders placed through Ophis
(SupportedChainId.BNB in cowSdk.ts,
mapped from the bnb slug in chainMap.ts)
settle on-chain through CoW Protocol's GPv2Settlement at
0x9008D19f58AAbD9eD0D60971565AA8510560ab41 on BSC, giving gasless, MEV-protected
swaps with no Ophis-side custody. Ophis does not deploy its own settlement on BSC;
BNB trades use CoW Protocol's canonical BSC deployment.
The two have different settlement contracts and orderbook hosts, so resolve them
per chain via @ophis/sdk or the MCP list_chains tool rather than assuming.
Full live status: docs.ophis.fi/status.
Cross-chain destinations (Solana, Bitcoin) are surfaced via NEAR Intents.
Canonical contract addresses and the disclosure policy live in
SECURITY.md.
Path | Origin | Purpose |
|
| Vite/Nx monorepo holding several surfaces: |
|
| Rust orderbook, autopilot, driver, baseline solver. Ophis additions live in dedicated crates and |
| New |
|
| New |
|
| New | Docusaurus docs portal (docs.ophis.fi). Self-contained app (own lockfile, excluded from the root, like |
| New |
|
|
|
|
| New | Cloudflare Pages Functions: |
| New | Per-chain runtime stacks ( |
Upstream subtrees are vendored as-is; Ophis changes are catalogued in
apps/frontend/.ophis-divergences.md and apps/backend/.ophis-divergences.md
so git subtree pull stays tractable.
ophis/
├── apps/
│ ├── frontend/ cowswap fork: swap UI + explorer + landing site
│ ├── backend/ cowprotocol/services fork (Rust)
│ ├── rebate-indexer/ tier + WETH rebate API, Safe batch proposer
│ ├── docs-ophis/ Docusaurus docs portal
│ └── mcp-server/ agent-facing MCP Worker (mcp.ophis.fi)
├── contracts/ GPv2 settlement contracts (+ per-network deployments)
├── packages/sdk/ @ophis/sdk
├── functions/ Cloudflare Pages Functions (intent API, bungee, middleware)
├── infra/ per-chain runtime stacks + rpc + cloudflare config
├── scripts/ repo utility scripts
└── docs/ specs, plans, audits, operations runbooksRoot workspace (pnpm 9, Node 20.19+ or 22.12+, turborepo):
pnpm install # all root-workspace deps
pnpm build # builds members with a build step (currently @ophis/sdk)
pnpm typecheck # typechecks every member
pnpm test # runs the unit suitesOnly packages/sdk has a build step today. apps/rebate-indexer,
apps/mcp-server, and infra/rpc run directly (no build script) and are
validated by pnpm typecheck and pnpm test. The Rust backend (apps/backend)
is a Cargo workspace, not a pnpm package, so build and test it with Cargo:
cd apps/backend && cargo build && cargo testapps/frontend and apps/docs-ophis are self-contained pnpm workspaces with
their own lockfiles, deliberately excluded from the root. Build them from inside
their own directory (see each app's README):
cd apps/frontend && pnpm install --frozen-lockfile && pnpm run build:cowswap
cd apps/docs-ophis && pnpm install --frozen-lockfile && pnpm run buildThe contracts use Foundry (forge build); forge-std is a git submodule, so run
git submodule update --init first.
Every surface deploys independently from main:
Swap app and Explorer cloudflare-deploy.yml: two sequential Cloudflare Pages deploys (swap.ophis.fi / ophis.fi, then explorer.ophis.fi).
Landing landing-deploy.yml: path-filtered build with a Playwright and Lighthouse budget gate, to Cloudflare Pages.
Docs docs-deploy.yml: the Docusaurus site to its own Cloudflare Pages project.
MCP server mcp-deploy.yml: to Cloudflare Workers (custom domain mcp.ophis.fi) with a least-privilege Workers token; mcp-registry-release.yml publishes matching versioned metadata to the official MCP Registry from protected mcp-v* tags.
Rebate indexer rebate-indexer-deploy.yml: to self-hosted infrastructure over a private network.
Operated-chain backends: the Optimism, Unichain, and Robinhood Chain
orderbooks, autopilots, drivers, and solver lanes run on Ophis infrastructure
from infra/optimism-mainnet/, infra/unichain-mainnet/, and
infra/robinhood-mainnet/. They are not deployed by a GitHub workflow.
Quality gates: ci.yml (lint, typecheck, tests),
codeql.yml,
security.yml (dependency and supply-chain
scans), and echidna.yml (contract fuzzing).
sdk-release.yml publishes @ophis/sdk to npm.
All package and MCP publishing controls are documented in the
release runbook.
On every supported chain, Ophis charges a 0.01% (1 bp) base plus a capped share of reference-quote improvement: 80% capped at 99 bps for volatile pairs and 50% capped at 20 bps for stable pairs. Operated-chain backends apply the improvement policy; hosted orders encode it in CIP-75 appData and separately pay CoW Protocol's upstream fees.
Part of the fee flows back to traders:
Volume-tier rebates. Each month a share of collected WETH fees is paid back, split across active wallets by 30-day volume and tier (Bronze through Platinum). The rebate indexer computes shares and a Safe batch proposer pays out.
Referrals. Mint a code, share https://swap.ophis.fi/?ref=YOURCODE, and earn
8% of the verified base fee Ophis keeps on trades your referrals route, paid monthly in WETH.
Full numbers and the tier ladder: docs.ophis.fi/fees and docs.ophis.fi/affiliate.
See SECURITY.md for the disclosure policy, canonical contract
addresses, the partner-fee recipient and governance model, in-scope components,
and audit history.
GPL-3.0, inherited from upstream CoW Protocol.
Build a bounded, ready-to-sign CoW order on Ophis. Returns { order, signing:{domain,types,primaryType}, fullAppData, appDataHash, partnerFee, next }. The receiver is ALWAYS PINNED to the owner (proceeds cannot leave the account); this public endpoint exposes no custom-receiver option. Uses the correct per-chain settlement contract (Optimism/MegaETH/HyperEVM are non-canonical) and embeds the CIP-75 partner fee. Apply slippage to the LIMIT side by kind: for kind 'sell' lower buyAmount (your minimum out); for kind 'buy' raise sellAmount (your maximum in). slippageBips is capped at 5000 (50%, default = the cap) and ENFORCED: build_order fetches a live quote and REJECTS the call if the limit is worse than slippageBips vs that quote (or if a quote cannot be fetched — retry). Sign order as EIP-712 with signing, then call submit_order.
| Name | Required | Description | Default |
|---|---|---|---|
| chainId | Yes | EVM chain id (use a chainId from list_chains `tradeable`). | |
| owner | Yes | The signer/owner address (receiver defaults to this). | |
| sellToken | Yes | Sell token address (0x...). | |
| buyToken | Yes | Buy token address (0x...). | |
| sellAmount | Yes | In atoms. kind 'sell': the EXACT amount you sell. kind 'buy': the MAXIMUM you'll spend (slippage-adjusted UP from the quote). | |
| buyAmount | Yes | In atoms. kind 'sell': the MINIMUM you accept (slippage-adjusted DOWN from the quote). kind 'buy': the EXACT amount you want to receive. | |
| kind | Yes | 'sell' = sellAmount is exact and buyAmount is your minimum out; 'buy' = buyAmount is exact and sellAmount is your maximum in. | |
| validForSeconds | No | Order lifetime in seconds (default 1200 = 20 min; minimum 60). The enforced live-quote fetch can consume several seconds, so very short lifetimes would return a near-expired order the orderbook rejects. | |
| feeAmount | No | Signed feeAmount in atoms. Must be omitted or "0" on this tool (the fee is taken from surplus + the appData partner fee). | |
| partiallyFillable | No | Allow partial fills (default false = fill-or-kill). | |
| slippageBips | No | Max accepted slippage in bips; capped at 5000 (50%, the default bound); recorded in appData. ENFORCED: build_order fetches a live quote and rejects a limit worse than this vs the quote. Fund safety: the receiver is always pinned to the owner. | |
| referenceBuyAmount | No | ||
| referenceSellAmount | No | ||
| referrerCode | No | Affiliate referral code to embed in appData (credits that code's owner for this trade). Defaults to the server's OPHIS_DEFAULT_REFERRER_CODE if set. Grammar: 3-64 chars [a-z0-9_-]; an invalid code errors. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses key behaviors: receiver always pinned, slippage enforced via live quote, rejection if limit worse or quote unavailable, correct per-chain contract, partner fee embedding. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Every sentence adds necessary information. Structure is logical: purpose first, then key constraint, then usage guidance, then next steps. No redundant or vague language.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (14 params, no output schema), the description is exceptionally thorough. It covers return value structure, behavioral constraints, parameter usage, and post-build steps. Missing only minor detail on referenceBuyAmount/referenceSellAmount, but overall complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is high (86%), but description adds significant meaning beyond schema, such as explaining slippage enforcement, the relationship between sellAmount/buyAmount and kind, and noting feeAmount must be omitted or '0'. This greatly aids parameter interpretation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool builds a bounded, ready-to-sign CoW order on Ophis, with specific return fields. It distinguishes itself from sibling tools like get_quote and submit_order by focusing on order construction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance on when to use (e.g., for building an order) and how to use (e.g., slippage application, fee handling, signing steps). Implicitly tells when not to use (e.g., for quotes use get_quote). Also mentions the receiver is always pinned, no custom-receiver option.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch a best-execution quote from the chain's Ophis orderbook (use a chainId from list_chains' tradeable). Amounts are in atoms (smallest unit, uint256 decimal string). For kind='sell' the amount is the sell amount before fee; for kind='buy' it is the desired buy amount. Returns the orderbook quote (sellAmount/buyAmount/feeAmount/validTo). Before build_order, apply slippage to the limit side by kind: kind='sell' -> lower buyAmount (min out); kind='buy' -> raise sellAmount (max in).
| Name | Required | Description | Default |
|---|---|---|---|
| chainId | Yes | EVM chain id (use list_chains for supported chains). | |
| sellToken | Yes | Sell token address (0x...). | |
| buyToken | Yes | Buy token address (0x...). | |
| kind | Yes | 'sell' = you specify the sell amount; 'buy' = you specify the buy amount. | |
| amount | Yes | Amount in atoms (uint256 decimal string). | |
| from | Yes | The trading account address (quotes are account-aware). | |
| validForSeconds | No | Quote validity window in seconds (default 1200 = 20 min). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses key behaviors: amounts are in atoms (uint256 decimal string), kind semantics for sell vs buy, return fields (sellAmount/buyAmount/feeAmount/validTo), and slippage instructions. It could explicitly state it is a read-only operation, but the 'Fetch' verb implies that. Overall, it provides substantial transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single paragraph of 4 sentences, each earning its place. It starts with the primary purpose, then covers units, kind, return values, and follow-up action (slippage). It is well-structured and sufficiently concise, though a minor reorganization could improve scannability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite lacking an output schema, the description explains the return fields (sellAmount/buyAmount/feeAmount/validTo) and provides crucial contextual links: using chainId from list_chains and applying slippage before build_order. For a 7-parameter tool with 6 required, it covers all essential information an agent needs to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, but the description adds significant meaning beyond the schema: it explains that amounts are in atoms (uint256 decimal string), clarifies kind semantics ('kind='sell' the amount is the sell amount before fee; kind='buy' it is the desired buy amount'), and states that validForSeconds defaults to 1200. This enriches the parameter understanding beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description starts with a clear verb-resource pair: 'Fetch a best-execution quote from the chain's Ophis orderbook'. It specifies the resource (quote) and context (Ophis orderbook), and distinguishes from siblings by referencing list_chains for chainId and build_order for subsequent steps.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage context: 'use a chainId from list_chains' and 'Before build_order, apply slippage...'. While it does not list when not to use this tool, it implicitly differentiates from sibling tools like list_chains and build_order, offering sufficient guidance for an agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List Ophis chains, split into tradeable (orderbook host is live — only route get_quote/build_order to these) and paused (settlement deployed but no live orderbook yet, e.g. MegaETH/HyperEVM — these throw). Each tradeable chain includes its orderbook host and GPv2Settlement contract (Optimism/MegaETH/HyperEVM are non-canonical) and partner-fee config. No input.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but description discloses that paused chains throw, includes non-canonical notes, and details contents of each chain. Does not cover idempotency or other behaviors, but sufficient for a read-only list tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Packed with information but well-structured and front-loaded. Could be slightly more concise, but each sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Without output schema, description fully explains output structure (tradeable vs paused, contents) and provides context on non-canonical chains and error behavior. Complete for this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters, so baseline is 4. Description adds value by explaining output structure and behavior beyond what schema (which is empty) provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it lists Ophis chains, splitting into tradeable and paused, with specific details. Distinguishes from siblings by noting which chains should be used with get_quote/build_order.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says only route get_quote/build_order to tradeable chains and that paused chains throw errors. Provides clear guidance on when to use each category.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Look up a wallet's Ophis fee-rebate tier and live status (30-day volume → bronze/silver/gold/platinum, rebate %). Returns the indexer status plus the static tier ladder.
| Name | Required | Description | Default |
|---|---|---|---|
| wallet | Yes | Wallet address (0x...). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It indicates a read-only operation ('Look up') and mentions returning live status and indexer status, implying no side effects. It does not disclose auth requirements or rate limits, but for a simple lookup, the core behavior is well-transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of two concise sentences that front-load the main action ('Look up a wallet's Ophis fee-rebate tier') and summarize return values. Every part is essential with no waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (1 parameter, no output schema), the description covers the purpose, the volume-to-tier mapping, and the return components (indexer status and tier ladder). It does not detail error scenarios, but provides sufficient context for the tool's use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% as the only parameter 'wallet' is described in the schema. The description does not add any new meaning beyond the schema's 'Wallet address (0x...).' Baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool looks up a wallet's Ophis fee-rebate tier based on 30-day volume, specifying the tier progression and rebate percentage. It also mentions returning indexer status and the static tier ladder, which fully defines the tool's purpose and distinguishes it from sibling tools like build_order or get_quote, which have unrelated functions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool should be used when a wallet's fee-rebate tier is needed, but it does not explicitly state when to use it versus alternatives. No exclusions or prerequisites are mentioned, making it adequate but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Parse a plain-English swap request (e.g. "swap 100 USDC for ETH on Optimism") into a structured intent: { intent: "swap"|"unknown", entities: [{type: sellToken|buyToken|amount|chain, value, raw}] }. Backed by the live Ophis parser.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | The natural-language swap request. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavior. It mentions the output structure and the live parser backend, providing transparency about the tool's operation. However, it does not discuss error handling, rate limits, or side effects, which are minor for a parsing tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences, no unnecessary information. It is front-loaded with the purpose and includes an example, making it efficient for an agent to quickly understand the tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description is fairly complete. It explains input, output structure, and backend. It could mention when to use it in a workflow, but overall it provides sufficient context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The parameter schema has 100% coverage with a description, but the tool's description adds value by providing an example of acceptable input text and clarifying the expected format. This goes beyond the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: parsing plain-English swap requests into structured intents. It provides a concrete example and defines the output format, distinguishing it from sibling tools like build_order or get_quote.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for converting natural language to intents, but does not explicitly state when to use it over alternatives or provide exclusions. Sibling tools have different purposes, so some context is present but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Relay a PRE-SIGNED order to the chain's Ophis orderbook. Pass the exact order object and fullAppData from build_order, plus your EIP-712 signature and from (owner). The MCP holds no keys — it only forwards. Returns the order UID on success.
| Name | Required | Description | Default |
|---|---|---|---|
| chainId | Yes | EVM chain id the order was built for. | |
| order | Yes | The order object returned by build_order. | |
| signature | Yes | 0x EIP-712 signature over the order by the owner. | |
| signingScheme | No | Signature scheme over the order (default 'eip712'). | |
| from | Yes | The owner address that signed. | |
| fullAppData | Yes | The fullAppData string returned by build_order. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full burden. It discloses the forwarding nature and keyless operation, but lacks details on failure behavior, error responses, or rate limits. The return value is mentioned succinctly.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, fully front-loaded, no redundant information. Every sentence contributes essential guidance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema and nested objects, the description covers the tool's purpose, input sources, and key constraint (pre-signed). It lacks examples or error scenarios, but is sufficient for an agent familiar with the domain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds workflow context by linking parameters to build_order outputs ('Pass the exact order object and fullAppData from build_order'), which helps the agent understand the data flow beyond schema definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool relays a pre-signed order to the Ophis orderbook, specifying the exact inputs (order, fullAppData from build_order, signature, from). It differentiates from sibling tools like build_order and get_quote by explicitly noting the pre-signed requirement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains that inputs must come from build_order and that the tool only forwards (holds no keys). However, it does not explicitly state when to use this tool vs alternatives or provide exclusions, leaving the agent to infer the workflow order.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.0.1build_orderget_quotelist_chainslookup_tierparse_intentsubmit_orderEach tool has a distinct purpose: build_order constructs orders, get_quote fetches quotes, list_chains provides chain info, lookup_tier checks fee tiers, parse_intent interprets natural language, and submit_order relays signed orders. No overlap or ambiguity.
All tool names follow a consistent snake_case verb_noun pattern (build_order, get_quote, list_chains, lookup_tier, parse_intent, submit_order), making them predictable and easy to navigate.
With 6 tools, the server is well-scoped for its purpose of building and submitting CoW orders. Each tool serves a necessary role without redundancy, and the count is appropriate for the domain.
The tool set covers the full lifecycle: get a quote (get_quote), construct an order (build_order), and submit it (submit_order), plus auxiliary tools for chain info, fee tiers, and natural language parsing. No obvious gaps for the intended use case.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Pay-per-call agent tools on Base: market pulse, USDC stats, crypto prices, JSON repair, DNS, URLs.
63 pay-per-call tools for agents: vision, text, data, web, blockchain. USDC on Base via x402.
x402-paid Base agent tools (USDC). 5 deterministic tools. No API keys. No NFT pass.
Pay-per-call tools for autonomous agents, settled in USDC on Base via x402.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/ophis-fi/ophis'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
