Skip to main content
Glama

Vectorial Data Terminal: Hyperliquid, Polymarket & yield for AI agents

submit_operation

DestructiveIdempotent

Execute a prepared Earn / move operation with your signatures, one per step and in order (owner steps: base64 P-256 signature over payload_b64; trading_key steps: 0x… EIP-712 signature). All signatures are checked before the first step runs. Returns each step's result; status 'uncertain' means check get_earn before retrying. If this call times out, the operation may still be finishing: check list_operations ('executing' = still running; don't prepare it again until it ends).

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "operation_id": "<operation_id>",
      "signatures": "<signatures>"
    },
    "name": "submit_operation"
  }
}

Input Schema

NameRequiredDescriptionDefault
signaturesYesOne signature per signatures_needed step, in order: base64 P-256 for owner steps, 0x… EIP-712 for trading_key steps
operation_idYesThe operation_id returned by the prepare tool
owner_public_keyNoYour OWNER P-256 public key (SPKI PEM or base64). Required when the operation has Base transactions; every owner signature is then checked before anything is sent.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.5/5.0
Behavior5/5

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

Goes well beyond the annotations (destructive, idempotent, openWorld) by disclosing that all signatures are validated before the first step runs, that the call returns per-step results, and what the 'uncertain' status and a timeout imply about the operation possibly still executing. That is exactly the kind of failure-mode context annotations cannot carry.

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?

Three sentences, front-loaded with the action and signature contract, followed by return/status semantics and then the timeout escape hatch. Every clause carries operational information; nothing is padding.

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?

No output schema exists, yet the description covers returns ('each step's result'), ambiguous statuses, and timeout behavior, plus the signature precondition. For a destructive, open-world execution tool this leaves no critical gap for correct invocation.

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

Parameters3/5

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

Schema coverage is 100%, and the description largely restates the schema's own per-step signature mapping (base64 P-256 for owner, 0x EIP-712 for trading_key). The added value is the ordering/validation guarantee rather than new meaning about individual parameters, so baseline 3 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 ('Execute') and resource ('a prepared Earn / move operation') and ties it back to the prepare step that produces operation_id, so an agent can distinguish it from preparation siblings like move_funds or prepare_withdrawal.

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?

Makes the precondition explicit (a prepared operation plus one signature per step, in order) and gives concrete recovery routing: check get_earn on 'uncertain', check list_operations on timeout, and don't re-prepare while status is 'executing'. It stops short of naming the prepare tool directly, leaving that link to inference from the schema description.

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.