Skip to main content
Glama

TradingCalc MCP: Options, Forex, Risk Stats, Prediction Markets, On-Chain & Crypto Futures

Orderbook Impact

workflow.run_orderbook_impact
Read-only

Order-book "walk the book" impact/capacity: given order-book levels (price, size in base-asset units) and EITHER a target notional or an impact budget in bps, computes VWAP and price impact for that size, or (via bisection) the largest notional that stays inside the impact budget. Edge cases: bids and asks each at least 1 level (price, size in base units, any order); side buy or sell; give exactly one of notional_usd or impact_budget_bps, both above zero. A book too thin for the size returns book_sufficient false and no VWAP. Not covered: a book that moves while you trade, hidden liquidity, your own fees, and any depth you did not supply (capacity_is_lower_bound says when the whole supplied book fit). Use when user asks "what's my price impact if I trade $X" or "how much can I trade before impact exceeds Y bps". side="buy" walks the asks, side="sell" walks the bids; impact is measured from the book's own mid ((best_bid+best_ask)/2) and is always a positive "cost in bps" number regardless of side. Returns: mid_price, spread_bps, vwap, impact_bps - both null when EITHER the loaded book doesn't cover the requested notional (book_sufficient=false flags this specific case) OR the notional involved is ~0 (book_sufficient stays true then; happens for a near-zero notional_usd, or in capacity mode when even an infinitesimal trade already exceeds impact_budget_bps, in which case max_notional itself resolves to 0) - and in capacity mode, max_notional plus capacity_is_lower_bound (true if the ENTIRE supplied book was consumed within budget, meaning true market capacity may exceed what was supplied - this tool only sees the levels given to it).

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": {
      "bids": "<bids>",
      "asks": "<asks>",
      "side": "<side>"
    },
    "name": "workflow.run_orderbook_impact"
  }
}

Input Schema

NameRequiredDescriptionDefault
asksYesAsk levels as [price, size_base] pairs, any order
bidsYesBid levels as [price, size_base] pairs, any order
sideYes"buy" walks the asks, "sell" walks the bids
notional_usdNoTarget notional to walk the book for. Provide this OR impact_budget_bps, not both.
impact_budget_bpsNoMax acceptable impact in bps; solves for the largest notional within it. Provide this OR notional_usd, not both.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.4/5.0
Behavior5/5

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

Beyond the readOnly/non-destructive/non-open-world annotations, it discloses the return contract (mid_price, spread_bps, vwap, impact_bps), the precise conditions under which vwap and impact_bps are null (insufficient book vs near-zero notional), and the capacity_is_lower_bound caveat. Those null-vs-flag distinctions are exactly the kind of behavior an agent cannot infer from annotations.

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?

The purpose is front-loaded and nearly every clause carries real information (edge cases, null semantics, capacity caveat), so little is wasted. However, the bulk is delivered as one enormous sentence threaded with em-dashes and nested parentheses, which makes it harder to parse than a few short structured sentences would be.

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?

For a five-parameter computational tool with no output schema, the description supplies the full output contract, the two operating modes, the input validity conditions, and the limits of the model's knowledge. An agent could select and invoke this correctly from the description alone.

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 already 100%, yet the description still adds meaning: sizes are in base-asset units, levels may be in any order, buy walks the asks and sell walks the bids, impact is measured from the book's own mid, and impact is always reported as a positive cost in bps regardless of side. It also clarifies that both the book arrays and the size selector must exceed zero.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The opening clause names a specific verb and resource: 'Order-book "walk the book" impact/capacity,' and immediately scopes the input as user-supplied levels, which separates it conceptually from live-market siblings like run_swap_price_impact. It stops short of naming any sibling tool explicitly, so the differentiation is inferential rather than stated.

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 concrete trigger phrasings ('what's my price impact if I trade $X', 'how much can I trade before impact exceeds Y bps') and states the mode-selection rule that exactly one of notional_usd or impact_budget_bps must be supplied. The 'Not covered' list bounds the model's scope, but there is no explicit statement of when to prefer a different tool over this one.

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.