Skip to main content
Glama
ophis-fi

Ophis

Official
by ophis-fi
OverviewSchemaRelated ServersScoreDiscussions
Rust
Remote

build_order

Construct a signed CoW order with slippage enforcement and partner fee on Ophis. The order limits are validated against a live quote and include EIP-712 signing data.

Instructions

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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
chainIdYesEVM chain id (use a chainId from list_chains `tradeable`).
ownerYesThe signer/owner address (receiver defaults to this).
sellTokenYesSell token address (0x...).
buyTokenYesBuy token address (0x...).
sellAmountYesIn atoms. kind 'sell': the EXACT amount you sell. kind 'buy': the MAXIMUM you'll spend (slippage-adjusted UP from the quote).
buyAmountYesIn atoms. kind 'sell': the MINIMUM you accept (slippage-adjusted DOWN from the quote). kind 'buy': the EXACT amount you want to receive.
kindYes'sell' = sellAmount is exact and buyAmount is your minimum out; 'buy' = buyAmount is exact and sellAmount is your maximum in.
validForSecondsNoOrder 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.
feeAmountNoSigned feeAmount in atoms. Must be omitted or "0" on this tool (the fee is taken from surplus + the appData partner fee).
partiallyFillableNoAllow partial fills (default false = fill-or-kill).
slippageBipsNoMax 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.
referenceBuyAmountNo
referenceSellAmountNo
referrerCodeNoAffiliate 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.

Tool Definition Quality

A5/5.0
Behavior5/5

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.

Conciseness5/5

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.

Completeness5/5

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.

Parameters5/5

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.

Purpose5/5

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.

Usage Guidelines5/5

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.

Install Server

Other Tools

Latest Blog Posts

MCP directory API

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