Skip to main content
Glama

Prepare an order (typed data or transaction to sign)

prepare_order
Read-only

No version argument: every order runs on the v4 backend. One prepare for every product - a token swap, position swap, repay-with-supply or leverage quoteId all come here. Which optional arguments apply is decided by the quote that minted the quoteId, so decide before emitting any: a token-swap quote that offered a 'bySignature' permit takes permitSignature + permitDeadline once that permit is signed; a position-swap, repay-with-supply or leverage quote listing approvals takes one signature per approval under its matching argument (adapterContractSignature, positionManagerSignature, setCollateralSignature, and on a leverage quote permitSignature + permitDeadline for an ERC-20 approval's 'byPermit'); route:'transaction' applies only to a SwapByTransaction... quote (a native-token sell) and takes no signatures at all. Never send a signature argument unsolicited - each exists to carry back a signature its quote explicitly asked for. Non-custodial: this returns what the user signs, and commits nothing.

Input Schema

NameRequiredDescriptionDefault
routeNoWhich execution route the quote needs, taken from its __typename: 'intent' (default) for everything except SwapByTransaction..., which takes 'transaction' and returns the on-chain transaction plus an orderReceipt, the route a native-token sell takes.
quoteIdYesquoteId from get_swap_quote, get_position_swap_quote, get_repay_with_supply_quote or get_leverage_quote.
permitDeadlineNoUnix seconds, the 'deadline' from the permit message that was signed. Required with permitSignature.
permitSignatureNoThe user's signature (0x...) over the PermitTypedData a quote's approvals offered: under 'bySignature' on a token-swap quote, under 'byPermit' on a leverage quote's ERC-20 approval. Sending it skips the approval transaction. Never send it on a first call - you only have one once a quote has handed you a permit to sign. Requires permitDeadline.
setCollateralSignatureNoSignature (0x...) over the 'bySignature' of a set-collateral approval the quote listed. Only when the quote asked for it.
adapterContractSignatureNoSignature (0x...) over the 'bySignature' of an adapter approval the quote listed. Only when the quote asked for it.
positionManagerSignatureNoSignature (0x...) over the 'bySignature' of a position-manager approval the quote listed. Only when the quote asked for it; omit it entirely if that approval's 'byTransaction' was sent instead.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed5 schema fields changed
    • addedInput schema / properties / adapterContractSignature
      Added value: +{
      +  "description": "Signature (0x...) over the 'bySignature' of an adapter approval the quote listed. Only when the quote asked for it.",
      +  "type": "string"
      +}
    • changedInput schema / properties / permitSignature / description
      Previous value: -"The user's signature (0x...) over the PermitTypedData a quote's approvals offered under 'bySignature'. Sending it skips the approval transaction. Never send it on a first call - you only have one once a quote has handed you a permit to sign. Requires permitDeadline."New value: +"The user's signature (0x...) over the PermitTypedData a quote's approvals offered: under 'bySignature' on a token-swap quote, under 'byPermit' on a leverage quote's ERC-20 approval. Sending it skips the approval transaction. Never send it on a first call - you only have one once a quote has handed you a permit to sign. Requires permitDeadline."
    • addedInput schema / properties / positionManagerSignature
      Added value: +{
      +  "description": "Signature (0x...) over the 'bySignature' of a position-manager approval the quote listed. Only when the quote asked for it; omit it entirely if that approval's 'byTransaction' was sent instead.",
      +  "type": "string"
      +}
    • changedInput schema / properties / quoteId / description
      Previous value: -"quoteId from get_swap_quote."New value: +"quoteId from get_swap_quote, get_position_swap_quote, get_repay_with_supply_quote or get_leverage_quote."
    • addedInput schema / properties / setCollateralSignature
      Added value: +{
      +  "description": "Signature (0x...) over the 'bySignature' of a set-collateral approval the quote listed. Only when the quote asked for it.",
      +  "type": "string"
      +}
  2. First observed

TDQS

A4.2/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description is consistent with them ('Non-custodial: this returns what the user signs, and commits nothing'), reinforcing the non-mutating nature. It adds genuinely useful behavior beyond the annotations — no version argument, per-quote signature requirements, and that no signature should ever be sent unsolicited.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

It is a single dense paragraph front-loaded with a negative edge case ('No version argument') rather than the core purpose, and the conditional signature rules would be far clearer as a list. Content is mostly substantive, but the structure makes it hard to scan.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 7-parameter tool with no output schema, it covers routing, signature preconditions, and the fact that the return value is unsigned user-facing data. It omits what to do with the result (submitting via submit_signed_order) and the distinction between the intent route's return shape and the transaction route's orderReceipt, so a small gap remains.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3; the description goes beyond it by explaining which quote type maps to each signature parameter (permitSignature under 'bySignature' vs a leverage 'byPermit', adapterContractSignature/positionManagerSignature/setCollateralSignature per listed approval) and when route applies.

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?

States a specific verb+resource whose scope is defined by a quoteId ('One prepare for every product - a token swap, position swap, repay-with-supply or leverage quoteId all come here'), which cleanly separates it from prepare_action, prepare_set_collateral and the other prepare_* siblings that handle non-quote flows.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives explicit conditional rules: signatures only when the originating quote asked for them, route:'transaction' only for SwapByTransaction quotes from a native-token sell. It does not state the surrounding workflow (get quote first, submit_signed_order after), so it falls short of full when/when-not coverage, but the per-quote routing guidance is unusually concrete.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources