Skip to main content
Glama

PredictAsiaX MCP Server

pax.probability_movers

Return markets whose YES probability moved the most in a window. Ranked by |delta|.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
to_msYesWindow end (ms since epoch)
top_nNo
from_msYesWindow start (ms since epoch)
categoryNo
directionNoboth

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

C2.9/5.0
Behavior2/5

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

No annotations are provided, so the description carries the full behavioral burden. "Ranked by |delta|" is genuinely useful ordering information, but the description never states that this is a read-only query, whether resolved/illiquid markets are excluded, how ties are broken, whether results are truncated at top_n, or any rate/auth constraints.

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?

Two short sentences, front-loaded with the resource and immediately followed by the ranking rule — no filler or redundancy. It is efficient, though the extreme terseness leaves valuable detail on the table for a 5-parameter tool.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With five parameters, 40% schema coverage, no annotations, and no output schema, the description is too thin. An agent must guess at the direction semantics, category values, top_n behavior, and the shape of returned mover records.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is only 40% (from_ms and to_ms documented; top_n, category, and direction have no descriptions). The description mentions the window but adds no format detail, and it is silent on the direction enum (up/down/both), the top_n cap of 100, and what category filtering means. It does not compensate for the coverage gap.

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?

States a specific verb and resource ("Return markets") plus the defining scope ("whose YES probability moved the most in a window"), which clearly separates it from sibling reads like market_price_history or markets_top_volume. It does not, however, name any sibling or explicitly contrast its output with them, so it stops short of a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is only implied: the phrase "in a window" tells the agent it needs a time range, and "moved the most" implies a comparative-ranking use case. There is no explicit when-to-use guidance, no exclusions, and no pointer to market_price_history for raw series or markets_top_volume for volume ranking.

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.

Resources