alphapipeline

prediction.polymarket_mispricing

Read-only

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; passing unrelated markets produces a meaningless or false arbitrage signal. Accepts token_ids or market_slugs (+ optional outcomes, default all 'yes'), same length/order as strikes. Not investment advice. Paid in USDC on Base.

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": {
      "strikes": "<strikes>"
    },
    "name": "prediction.polymarket_mispricing"
  }
}

Input Schema

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

Output Schema

Name	Required	Description	Default
`notice`	Yes
`violations`	Yes
`data_source`	Yes
`generated_at`	Yes
`rungs_checked`	Yes
`violation_count`	Yes
`rungs_skipped_empty_book`	Yes
`oldest_book_snapshot_time`	No

Schema Changelog

Changes observed during successful MCP inspections.

AddedOct 18, 2026

TDQS

A4.4/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the description is not needed for safety. It adds real context beyond the annotations: the hard precondition the caller must supply, the false-arbitrage consequence of violating it, and the payment model (USDC on Base). It stops short of describing rate limits or latency, but the added behavioral detail is substantive.

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?

Three sentences, front-loaded with the core operation and the equivalence precondition before the parameter recap. Dense but every clause carries a constraint or caveat; the final 'Not investment advice. Paid in USDC on Base.' lines are short and earn their place as disclosures.

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?

With an output schema present the description need not explain returns, and annotations plus 100% schema coverage handle safety and parameter detail. The description supplies the remaining critical context: the user-confirmed precondition, the false-positive failure mode, and the acceptable input forms for a 4-parameter tool.

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 description coverage is 100%, so the schema already documents strikes ordering, outcomes default, and the token_ids/market_slugs alternative. The description restates length/order alignment and mutual exclusivity but adds no syntax or format detail beyond the schema. Baseline 3 is correct when the schema does the heavy lifting.

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: a monotonicity check across a set of Polymarket markets, with the pricing rule (higher strike must not be priced above a lower strike) spelled out inline. This is distinguishable from siblings like prediction.neg_risk_arbitrage or prediction.hip4_mispricing without opening any schema.

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?

Explicitly scopes when the tool applies (markets YOU have already confirmed share the same underlying asset and expiry/resolution date) and states the negative case: it does NOT verify settlement-condition equivalence and unrelated inputs yield a meaningless or false signal. That is a clear when/when-not with a named failure mode.

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

All alphapipeline 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.