Skip to main content
Glama
parkyucheol-del

AlphaPipeline

by parkyucheol-del
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

prediction.polymarket_mispricing

Detect mispricing by checking strike monotonicity across Polymarket markets you confirm share the same underlying and expiry; return violations where higher strikes exceed lower strikes.

Instructions

Monotonicity check (higher strike must not be priced above a lower
strike) across a set of Polymarket markets that YOU have already
confirmed share the same underlying asset and expiry/resolution date.
Does NOT verify or infer that settlement-condition equivalence itself -
Polymarket's API has no reliable field for it (see
architecture-roadmap.md Engineering Precision Backlog item 4); passing
unrelated markets produces a meaningless or false arbitrage signal.
Provide either token_ids or market_slugs (+ optional outcomes, default
all "yes"), same length and order as strikes. Not investment advice.

Args:
    strikes: Strike for each rung, same order as token_ids/market_slugs.
        At least 2 required.
    token_ids: CLOB token_id per rung, if already known. Mutually
        exclusive with market_slugs.
    market_slugs: Polymarket market slug per rung, used to resolve
        token_ids automatically.
    outcomes: "yes"/"no" per rung when using market_slugs (default: all
        "yes").

Returns:
    On success: {"success": true, "violation_count", "violations", ...}
    On failure: {"success": false, "error": {"type", "message"}}

Input Schema

NameRequiredDescriptionDefault
strikesYes
outcomesNo
token_idsNo
market_slugsNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.6.0

TDQS

A4.2/5.0
Behavior4/5

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

No annotations are provided, so the description carries the full burden. It discloses key behavioral traits: it does not verify settlement-condition equivalence, the API lacks a reliable field for that, passing unrelated markets yields meaningless results, and it details the success/failure return shapes. It does not mention authentication, rate limits, or compute cost, but for a read-only analytic tool this is a solid disclosure.

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?

The description is front-loaded with the core purpose and caveats, then structured into Args and Returns. Most sentences earn their place, but the parenthetical reference to architecture-roadmap.md and the boilerplate 'Not investment advice' are slightly extraneous. Overall efficient and well-organized.

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?

With no output schema and no annotations, the description must carry the full load. It explains the input contract thoroughly and sketches the return shape (success, violation_count, violations) and error format. However, the ellipsis in the return example leaves the structure of 'violations' unspecified, which is a minor gap for an analytic tool.

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 0%, so the description must compensate fully. It defines each parameter: strikes (required, at least 2, same order as token_ids/market_slugs), token_ids (mutually exclusive with market_slugs), market_slugs (resolved automatically), and outcomes (default all "yes" when resolving via slugs). This adds substantial meaning beyond the bare schema types.

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?

Description states a specific verb (monotonicity check) and resource (Polymarket mispricing across markets), and clearly scopes what it does not do (verify settlement-condition equivalence). It distinguishes itself from generic market tools by requiring user-confirmed equivalence, though it does not explicitly name sibling tools like prediction.hip4_mispricing.

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?

Provides clear when-to-use context: only for markets you have already confirmed share the same underlying asset and expiry, with explicit warning that unrelated markets produce a false signal. It also specifies mutual exclusivity between token_ids and market_slugs and default outcomes. Missing explicit alternatives to this tool (e.g., for HIP4 markets).

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