AlphaPipeline Agent MCP

prediction.exit_capacity_audit

Read-only

Walk a single Polymarket outcome's live order book to determine how much of a given position size can actually be filled right now, at what average price, and with how much price impact versus the best quote - a live snapshot, not historical liquidity. Also returns book_snapshot_time (the book's own reported timestamp) and Polymarket's own tick_size/min_order_size for this market (null if the book response didn't include them). Accepts either a raw token_id or a market_slug (+ outcome) to resolve it automatically - exact slug only, no fuzzy keyword search. Do not use for multi-outcome basket arbitrage detection (use prediction.neg_risk_arbitrage instead). Paid in USDC on Base.

Input Schema

TableJSON Schema

Name	Required	Description
`side`	No	"sell" (default) or "buy".
`outcome`	No	"yes" (default) or "no" - which side to resolve when using market_slug.
`token_id`	No	The outcome's CLOB token_id / asset_id, if already known.
`market_slug`	No	Exact Polymarket market slug, used to resolve token_id automatically.
`position_size_shares`	Yes	Number of outcome shares to sell (or buy). Must be positive.

Output Schema

TableJSON Schema

Name	Required	Description
`side`	Yes
`notice`	No
`token_id`	Yes
`tick_size`	No	Polymarket's own reported minimum price increment for this market. Null if the book response didn't include it.
`best_quote`	No
`executable`	Yes
`data_source`	Yes
`market_slug`	No
`generated_at`	Yes
`avg_exit_price`	No
`min_order_size`	No	Polymarket's own reported minimum order size for this market. Null if the book response didn't include it.
`price_impact_pct`	No
`book_snapshot_time`	No	The order book's own reported snapshot timestamp, so you can judge how fresh this read is.
`position_size_shares`	Yes
`max_executable_shares`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedSep 18, 2026

addedOutput schema / properties / book_snapshot_time

Added value: +{
+  "anyOf": [
+    {
+      "properties": {
+        "kst": {
+          "type": "string"
+        },
+        "utc": {
+          "type": "string"
+        }
+      },
+      "required": [
+        "utc",
+        "kst"
+      ],
+      "type": "object"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "description": "The order book's own reported snapshot timestamp, so you can judge how fresh this read is."
+}

addedOutput schema / properties / min_order_size

Added value: +{
+  "description": "Polymarket's own reported minimum order size for this market. Null if the book response didn't include it.",
+  "type": [
+    "number",
+    "null"
+  ]
+}

addedOutput schema / properties / tick_size

Added value: +{
+  "description": "Polymarket's own reported minimum price increment for this market. Null if the book response didn't include it.",
+  "type": [
+    "number",
+    "null"
+  ]
+}

AddedSep 8, 2026

TDQS

A4.9/5.0

Behavior5/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is known. The description adds valuable behavioral context: it is a live snapshot (not historical), it returns book_snapshot_time and tick_size/min_order_size, and it notes payment in USDC on Base. There is no contradiction with annotations.

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?

The description is moderately long but every sentence earns its place: purpose, scope, return fields, input modes, and an explicit exclusion. It is front-loaded with the main purpose and structured logically, with no filler or redundancy.

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 tool's complexity (5 parameters, resolution logic, live snapshot behavior) and the presence of an output schema, the description is remarkably complete. It covers input alternatives, output fields, edge cases (null tick_size), and the key limitation (no fuzzy slug matching). Nothing an agent needs to invoke it correctly is missing.

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 description coverage is 100%, so the baseline is 3. The description adds meaning beyond the schema by explaining the relationship between market_slug and token_id (automatic resolution) and clarifying that outcome is only used with market_slug. This goes beyond simple parameter definitions and helps an agent understand how to pass inputs correctly.

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?

The description states a specific verb (walk/audit) and resource (single Polymarket outcome's live order book) and precisely defines what it returns (fillable size, average price, price impact vs best quote). It explicitly contrasts with a sibling tool (prediction.neg_risk_arbitrage) for multi-outcome basket arbitrage, making its scope unambiguous.

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?

It clearly explains when to use: for a live liquidity snapshot of a single outcome, and explicitly says 'Do not use for multi-outcome basket arbitrage detection (use prediction.neg_risk_arbitrage instead)'. It also specifies input modes (raw token_id or exact market_slug) and the exact-slug requirement, giving an agent full decision context.

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

All AlphaPipeline Agent MCP tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?