Skip to main content
Glama
parkyucheol-del

AlphaPipeline

by parkyucheol-del
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

prediction.order_split_guide

Calculate how many clips to split a large Polymarket position into using the live order book, keeping each clip’s price impact at or below a set cap.

Instructions

Walks a Polymarket outcome's live order book to recommend how many clips
to split a large position into, so each clip's own price impact stays at
or under max_price_impact_pct_per_slice (default 1.0%). Also returns
full_size_price_impact_pct - the baseline impact if filled in one shot
right now, for comparison. Single-snapshot calculation - it has no idea
whether the book refills between clips in real trading, so treat the
recommended slice count as "if this exact snapshot repeated", not a
guarantee about live execution. Not investment advice - no confidence or
go/no-go field is returned, only the raw numbers.

Reuses the same order-book walking helpers as
prediction.exit_capacity_audit - no new upstream call. market_slug only
resolves an EXACT Polymarket market slug - no fuzzy keyword search.

Args:
    position_size_shares: Total number of outcome shares to sell (or
        buy). Must be positive.
    token_id: The outcome's CLOB token_id / asset_id, if already known.
        Provide either this OR market_slug.
    market_slug: Exact Polymarket market slug, used to resolve token_id
        automatically when not already known.
    outcome: "yes" (default) or "no" - which side to resolve when using
        market_slug. Ignored if token_id is given directly.
    side: "sell" (default) or "buy".
    max_price_impact_pct_per_slice: Target ceiling on each clip's own
        price impact, in percent. Defaults to 1.0.

Returns:
    On success: {"success": true, "executable_now",
        "full_size_price_impact_pct", "max_single_clip_shares",
        "recommended_slice_count", "recommended_slice_size_shares", ...}
    On failure: {"success": false, "error": {"type", "message"}}

Input Schema

NameRequiredDescriptionDefault
sideNosell
outcomeNoyes
token_idNo
market_slugNo
position_size_sharesYes
max_price_impact_pct_per_sliceNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.6.0

TDQS

A4.7/5.0
Behavior5/5

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

With no annotations, the description carries the full burden and does so well: it discloses the single-snapshot limitation (no knowledge of book refills), that the slice count is not a live-execution guarantee, that no confidence/go-no-go field is returned, and that no new upstream call is made. This is unusually rich behavioral disclosure for a mutation-free analytical tool.

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

Conciseness4/5

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

Purpose, caveats, Args, and Returns are front-loaded and logically ordered, with no filler sentences. The Args/Returns block is slightly verbose, which keeps it from a 5, but every line carries information an agent needs.

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 6-param tool with no output schema and no annotations, the description is complete: it covers inputs, defaults, conditional resolution, the snapshot caveat, and the success/failure return shapes. Nothing an agent needs to call it correctly appears to be missing.

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 description coverage is 0% and there are 6 params, so the description must compensate — and it does, documenting every parameter with defaults, constraints (position_size_shares must be positive), and conditional logic (token_id OR market_slug, outcome ignored if token_id given, side default sell). This adds meaning well beyond the bare schema.

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 and resource: walks a Polymarket outcome's live order book to recommend how many clips to split a position into, with a named target constraint (max_price_impact_pct_per_slice). It explicitly distinguishes itself from the sibling prediction.exit_capacity_audit by noting it reuses the same helpers with no new upstream call.

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 clear context for use: sizing a large position into clips with a per-clip impact ceiling, and notes the exact-slug-only resolution (no fuzzy keyword search) and that either token_id OR market_slug is needed. It does not, however, explicitly state when to prefer this over exit_capacity_audit beyond the shared-helper note.

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

Deploy Server

Other Tools