Skip to main content
Glama

Parlay

by run.parlay

Scan cross-venue discrepancies

scan_discrepancies
Read-only

Surface cross-venue price discrepancies between Polymarket, Kalshi, and Limitless as a discovery feed for price discovery and divergence detection. Default threshold is 0.5% spread, below typical round-trip fees — most results are informational, not tradable arbitrage. Raise min_spread to 0.03+ for after-fee opportunities. The optional query parameter post-filters results by topic keywords on event titles — it does not perform a topic search; for topic-driven retrieval use discover_markets or search_markets. Pairs with missing volume data on at least one venue are flagged 'volume_unconfirmed'. All results are indicative only — not trade recommendations. Real-money venues only. Orderbook depth is not confirmed in Phase 1.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNo
queryNoOptional post-filter on event titles by topic keywords (e.g. 'crypto', 'election', 'fed'). This filters the discovery feed locally — it is not a topic search and may return zero results when today's biggest discrepancies don't overlap your topic. Omit to receive the full feed.
min_spreadNoMinimum price gap to report (0.005 = 0.5%, 0.03 = 3 percentage points). Default 0.005 surfaces price discovery signals, most of which are below typical 4% round-trip fees and therefore informational rather than tradable. Raise to 0.03+ to filter for after-fee opportunities.
min_volumeNoMinimum 24h USD volume on the thinner side of each pair. Pairs where at least one venue has missing volume data are kept but tagged with risk_flag 'volume_unconfirmed'. Set to 0 to disable.

TDQS

A4.9/5.0
Behavior5/5

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

Despite annotations `readOnlyHint` and `openWorldHint` already indicating a safe read operation, the description adds meaningful behavioral context: results are 'indicative only — not trade recommendations', pairs with missing volume are flagged 'volume_unconfirmed', and 'Orderbook depth is not confirmed in Phase 1'. These details set expectations about data reliability and limitations, going beyond the annotations. No contradiction exists between description and 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 a single, well-structured paragraph that front-loads the core purpose, then provides threshold guidance, clarifies parameter semantics, and ends with caveats. Every sentence earns its place: no fluff, no repetition, and the structure aids comprehension. It is appropriately sized for the tool's complexity.

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 there is no output schema, the description effectively communicates what to expect: pairs, volume_unconfirmed risk flags, and the informational versus tradable distinction. It also covers venue scope, default behavior, parameter effects, and limitations (orderbook depth not confirmed). For a discovery feed with 4 optional parameters, the description is remarkably complete.

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 coverage is 75%, and the description adds value beyond the schema, especially for `query` (clarifies it's a local post-filter, not a topic search, may return zero results) and `min_spread` (explains the economic meaning of the default and the threshold for tradability). However, the `limit` parameter is not described in either schema or description, leaving a small gap. This compensation is strong but not perfect, so a 4 is appropriate.

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 clearly states the tool's purpose: 'Surface cross-venue price discrepancies between Polymarket, Kalshi, and Limitless as a discovery feed.' It names the specific resources (venues) and the verb 'surface', and distinguishes itself from sibling tools by explicitly recommending `discover_markets` or `search_markets` for topic-driven retrieval. This makes the purpose unmistakable and distinct.

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?

The description provides explicit when-to-use guidance: it explains that the default threshold (0.5% spread) is below typical round-trip fees, so most results are informational, and instructs to raise `min_spread` to 0.03+ for after-fee opportunities. It also clarifies that the `query` parameter is a post-filter, not a topic search, and points to alternatives for topic search. This is exactly the kind of actionable usage guidance needed.

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

All Parlay toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.4/5.0
Disambiguation5/5

Each tool has a clearly distinct purpose: searching, browsing, comparing, inspecting a single venue, scanning for discrepancies, and generating a synthesized brief. The descriptions explicitly cross-reference each other to clarify when to use which. No two tools are likely to be confused.

Naming Consistency4/5

Five of six tools follow a consistent verb_noun pattern (compare_markets, discover_markets, inspect_platform, scan_discrepancies, search_markets). 'market_brief' is a noun phrase, breaking the pattern slightly, but it is still clear and readable.

Tool Count5/5

With six tools, the server is well-scoped for a prediction market intelligence domain. Each tool earns its place, covering discovery, search, comparison, discrepancy scanning, single-platform inspection, and synthesis without redundancy or bloat.

Completeness4/5

The tool surface covers the core workflows: searching, browsing, comparing, inspecting, scanning, and briefing. A minor gap is the lack of a tool to fetch a single contract's detailed history or order book, but the current set is sufficient for most analytical queries.

Resources