disputes.online

Server Details

Read prediction disputes and the crowd's odds on real-world events from disputes.online.

If you are the author of this connector, you can claim ownership by verifying the domain or GitHub account it belongs to. Claimed connector authors can inspect health checks, view analytics, and manage their listing.

Status: Healthy
Uptime: 99.9% over 23 days
Last Tested: 2026-10-28 16:08
Transport: Streamable HTTP · MCP 2025-11-25
URL
Repository: peccancy/mcp
GitHub Stars: 0

TDQS

A4.2/5.0

Scored 2026-10-17 05:20 across 4 tools

Disambiguation4/5

get_dispute and list_categories target clearly distinct operations. The two search tools overlap in returning open disputes, but the descriptions sharply delineate them (free-text query vs. exact tags) and even redirect users between them, leaving little real ambiguity.

Naming Consistency5/5

All four tools use a consistent snake_case verb_noun pattern: get_dispute, list_categories, search_disputes, search_disputes_by_tags. The naming is predictable and readable throughout.

Tool Count4/5

Four tools is slightly lean for the domain but each earns its place (fetch, enumerate categories, two search modes). It is well-scoped rather than padded or anemic.

Completeness4/5

For a read-only prediction-data surface, the lifecycle is largely covered: fetch a dispute, discover categories, and search open or settled disputes. No write operations (placing bets, creating disputes) exist, but the descriptions frame this as a consumption API, so the gap is minor.

Available Tools

4 tools

get_disputeA

Read-onlyIdempotent

Inspect

Get one dispute from disputes.online by its id or page URL: the question, how it will be decided, the outcomes, how the stakes are split between them, and the deadlines. Also finds a dispute that has already been settled and returns which outcome won next to how the crowd had bet — use it to check a past prediction.

Name	Required	Description	Default
`dispute`	Yes	the dispute's id (UUID) or the URL of its page on disputes.online

Output Schema

Name	Required	Description
`id`	Yes	dispute id (UUID)
`url`	Yes	the dispute's page on disputes.online; link this when citing
`tags`	Yes	lowercase tags
`title`	Yes	the question, taken from the first line of the description
`status`	Yes	new: no bets yet; in_process, hot, very_hot: accepting bets, by popularity; ready: betting closed, awaiting the result; done or dispute: decided but still being paid out or contested; settled: decided and archived, with the winning outcome marked
`country`	No	ISO 3166-1 alpha-2 country the dispute is about
`created`	No	when the dispute was created, RFC 3339 UTC; absent for a settled dispute
`category`	No	category name
`language`	No	language code, or all; absent for a settled dispute
`outcomes`	Yes	the possible results and how the stakes are split between them — for a settled dispute, how they were split when it was decided
`result_due`	No	when the result is due, RFC 3339 UTC; absent for a settled dispute
`settled_at`	No	when the dispute was decided, RFC 3339 UTC; present only for a settled dispute
`total_bets`	Yes	number of bets placed
`category_id`	No	category id
`description`	Yes	the full text, including how the result will be decided
`betting_closes`	No	when betting closes, RFC 3339 UTC; absent for a settled dispute
`dates_estimated`	Yes	true when the event has no fixed date and the two dates are estimates
`winning_outcome`	No	name of the outcome that won; present only for a settled dispute that had a winner
`total_staked_qot`	Yes	pool size in QOT, the platform's internal currency — not dollars

TDQS

A4.1/5.0

Behavior4/5

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

Annotations already cover the safety profile (readOnly, idempotent, openWorld=false), so the bar is lower. The description adds genuine behavioral context beyond them: that it also resolves already-settled disputes and returns the winning outcome alongside the crowd's bets.

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?

Front-loaded with the core action and lookup key, then the return contents. Two dense sentences with little waste, though the field enumeration is on the verbose side.

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?

An output schema exists, so return values needn't be explained, and the description still covers the key behaviors; nothing critical to correct invocation is missing. The remaining gap is only in explicitly routing away from the search siblings.

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 coverage is 100% and the single parameter is fully documented in the schema, so baseline is 3. The description's mention of 'id or page URL' simply restates what the schema already declares, adding no new syntax or format detail.

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 (get) and resource (one dispute) and pins the lookup key (id or page URL). It enumerates the returned data, so an agent can distinguish this single-item fetch from the search_disputes/search_disputes_by_tags siblings 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 Guidelines4/5

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

Gives clear usage context — including the specific scenario of checking a settled dispute against crowd bets. It does not explicitly state when-not to use it or name the search siblings as alternatives, so it stops short of a 5.

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

list_categoriesA

Read-onlyIdempotent

Inspect

List the categories disputes on disputes.online are filed under, as a flat tree. Use it to find the category_id for a topic before calling search_disputes.

Name	Required	Description	Default
No parameters

Output Schema

Name	Required	Description
`categories`	Yes	every category, as a flat list

TDQS

A4.5/5.0

Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, and openWorldHint=false, so safety is covered. The description adds useful behavioral context beyond that: the result is a flat tree structure, and the tool's role is to supply category_id values. It doesn't discuss ordering or size limits, but an output schema exists, so return detail is less critical.

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?

Two short sentences, zero waste, with the purpose front-loaded and the practical usage instruction second. Every clause earns its place.

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 no parameters, an output schema present, and annotations covering the safety profile, the description supplies exactly what is missing: what the tool lists, its flat-tree shape, and the workflow reason to call it. Nothing an agent needs before invoking it is absent.

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?

The tool takes zero parameters, so the baseline is 4; there is nothing for the description to disambiguate. Full schema coverage (100%) and no required inputs mean no parameter risk remains.

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 (List) and resource (categories) with scope ('disputes on disputes.online are filed under') and even the return shape ('flat tree'). An agent can distinguish this from search_disputes, search_disputes_by_tags, and get_dispute 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 Guidelines4/5

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

Explicitly tells the agent when to use it: to obtain the category_id for a topic before calling search_disputes, naming the downstream sibling. It lacks any when-not or alternative-selection guidance, but the usage context is clear and actionable.

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

search_disputesA

Read-onlyIdempotent

Inspect

Find disputes on disputes.online that are open to bets, with each outcome's share of the stakes. Search by free text with query (a topic, a person, a team, an asset), filter by language, category, country and creation date, and sort by pool size, number of bets, newest or closing time. This is the tool for finding what people are predicting about something, what the crowd thinks the odds are, and what was opened recently — for yesterday's disputes pass yesterday's date as both created_from and created_to.

Name	Required	Description
`lang`	No	two-letter language code of the disputes to return: en, ua (Ukrainian), pl, de and so on. Defaults to en. Disputes marked all are always included.
`sort`	No	amount (largest pool first; the default), bets (most bets first), newest (most recently created first), closing_soon (betting closes soonest first), result_soon (result due soonest first)
`limit`	No	page size, 1 to 20; defaults to 10
`query`	No	free text to look for, for example bitcoin or trump impeachment. A dispute matches when every word occurs in its text or among its tags; fewer words find more. Leave empty to list everything.
`offset`	No	number of disputes to skip, for paging
`country`	No	ISO 3166-1 alpha-2 code of the country the dispute is about, for example US
`created_to`	No	only disputes created at or before this moment, UTC. Either a day, 2026-10-07 (through the end of that day), or a full timestamp. For one day's disputes pass the same day as created_from and created_to.
`category_id`	No	only disputes in this category or any category below it; ids come from list_categories
`created_from`	No	only disputes created at or after this moment, UTC. Either a day, 2026-10-07 (from the start of that day), or a full timestamp, 2026-10-07T12:00:00Z.

Output Schema

Name	Required	Description
`total`	Yes	number of disputes matching the request across all pages
`offset`	Yes	how many disputes were skipped before this page
`disputes`	Yes	this page of disputes

TDQS

A3.9/5.0

Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint and closed-world scope, so the safety profile is covered. The description adds genuinely new behavior: only disputes open to bets are returned, and results carry each outcome's share of the staked pool. Return-shape explanation is limited, but the output schema exists to cover it.

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 sentences, front-loaded with what the tool finds before moving into filters, sorting, and date handling. The second sentence is dense with clause-stacking and could be split, but nothing is filler.

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 an output schema present, the description need not explain return values, and it covers purpose, filters, sort axes, and date semantics adequately for a 9-param zero-required search tool. Its only meaningful omission is how it relates to search_disputes_by_tags and get_dispute when a search returns candidates.

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 coverage is 100%, so every parameter is already documented in the schema, which sets the baseline at 3. The description lists the filter and sort dimensions but adds no semantics beyond the schema; its date example restates what created_to already says. No extra syntax, defaults, or interaction rules are contributed.

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?

The description gives a specific verb and resource ('Find disputes on disputes.online that are open to bets') plus a distinguishing output detail ('each outcome's share of the stakes'). It is unambiguous what the tool returns, but it never names or contrasts with its sibling search_disputes_by_tags or get_dispute, so sibling selection still relies on inference.

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?

It clearly states the contexts that motivate use: finding what people are predicting, what the crowd's odds are, and what was opened recently. It even prescribes a concrete pattern for a common case ('for yesterday's disputes pass yesterday's date as both created_from and created_to'). It stops short of exclusions or naming an alternative tool for tag-based lookup.

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

search_disputes_by_tagsA

Read-onlyIdempotent

Inspect

List open disputes on disputes.online that carry every one of the given tags, spelled exactly. Tags are set by a dispute's author, many disputes have none, and their spelling is arbitrary — to find disputes about a subject, use search_disputes with query instead. Use this only when you already know the exact tag.

Name	Required	Description
`lang`	No	two-letter language code of the disputes to return; defaults to en
`tags`	Yes	one or more tags; a dispute matches only if it carries every one of them, spelled exactly. Tags are single lowercase words, for example politics or usa.
`limit`	No	page size, 1 to 20; defaults to 10
`offset`	No	number of disputes to skip, for paging

Output Schema

Name	Required	Description
`total`	Yes	number of disputes matching the request across all pages
`offset`	Yes	how many disputes were skipped before this page
`disputes`	Yes	this page of disputes

TDQS

A4.5/5.0

Behavior4/5

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

Annotations already cover safety (readOnlyHint, idempotentHint, openWorldHint=false). The description adds genuinely useful behavioral context not in structured data: only open disputes are returned, many disputes carry no tags, and tag spelling is arbitrary and author-controlled, which warns the agent about low/empty results. It does not discuss pagination or result shape, but the output schema covers returns.

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?

Three sentences, front-loaded with the core action and scope, followed by the caveat and the routing decision. No filler and every sentence carries information the 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?

A filtered-list tool with full schema coverage, annotations covering safety, and an output schema for returns. The description supplies the extra context that matters — open-only scope, tag sparsity, and the alternative tool — leaving nothing an agent needs missing.

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 lang, tags, limit and offset, including the exact-spelling and AND semantics. The description reinforces the tag semantics but adds no syntax or format detail beyond the schema; baseline 3 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?

States a specific verb (List) and resource (open disputes) plus the matching rule (carries every given tag, exact spelling). It also implicitly demarcates itself from search_disputes, so an agent can distinguish it without opening either 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 states when to use it ('only when you already know the exact tag') and names the alternative (search_disputes with query) for the subject-based case. Both the when and the when-not are covered.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

3 tool updatesOct 8, 2026

Changedget_dispute1 field changed

addedOutput schema / properties / created

Added value: +{
+  "description": "when the dispute was created, RFC 3339 UTC; absent for a settled dispute",
+  "type": "string"
+}

Changedsearch_disputes4 fields changed

addedInput schema / properties / created_from

Added value: +{
+  "description": "only disputes created at or after this moment, UTC. Either a day, 2026-10-07 (from the start of that day), or a full timestamp, 2026-10-07T12:00:00Z.",
+  "type": "string"
+}

addedInput schema / properties / created_to

Added value: +{
+  "description": "only disputes created at or before this moment, UTC. Either a day, 2026-10-07 (through the end of that day), or a full timestamp. For one day's disputes pass the same day as created_from and created_to.",
+  "type": "string"
+}

changedInput schema / properties / sort / description

Previous value: -"amount (largest pool first; the default), bets (most bets first), closing_soon (betting closes soonest first), result_soon (result due soonest first)"New value: +"amount (largest pool first; the default), bets (most bets first), newest (most recently created first), closing_soon (betting closes soonest first), result_soon (result due soonest first)"

addedOutput schema / properties / disputes / items / properties / created

Added value: +{
+  "description": "when the dispute was created, RFC 3339 UTC; absent for a settled dispute",
+  "type": "string"
+}

Changedsearch_disputes_by_tags1 field changed

addedOutput schema / properties / disputes / items / properties / created

Added value: +{
+  "description": "when the dispute was created, RFC 3339 UTC; absent for a settled dispute",
+  "type": "string"
+}

2 tool updatesOct 8, 2026

Changedsearch_disputes2 fields changed

changedInput schema / properties / lang / description

Previous value: -"language code of the disputes to return: en, ua, pl, de and so on. Defaults to en. Disputes marked all are always included."New value: +"two-letter language code of the disputes to return: en, ua (Ukrainian), pl, de and so on. Defaults to en. Disputes marked all are always included."

addedInput schema / properties / query

Added value: +{
+  "description": "free text to look for, for example bitcoin or trump impeachment. A dispute matches when every word occurs in its text or among its tags; fewer words find more. Leave empty to list everything.",
+  "type": "string"
+}

Changedsearch_disputes_by_tags2 fields changed

changedInput schema / properties / lang / description

Previous value: -"language code of the disputes to return; defaults to en"New value: +"two-letter language code of the disputes to return; defaults to en"

changedInput schema / properties / tags / description

Previous value: -"one or more tags; a dispute carrying any of them matches. Tags are single lowercase words, for example election or bitcoin."New value: +"one or more tags; a dispute matches only if it carries every one of them, spelled exactly. Tags are single lowercase words, for example politics or usa."

4 tool updatesOct 5, 2026
- First observedget_dispute
- First observedlist_categories
- First observedsearch_disputes
- First observedsearch_disputes_by_tags

Related MCP Connectors

Prediction Markets A
org.memoryapi
Prediction market data and crowd-sourced probability forecasts
Finance Research & Data
32
https://predict.memoryapi.org/mcp
spoiler
io.github.zerozaky
Sealed prediction-market verdicts, graded in public across Polymarket and Kalshi. No auth required.
Blockchain Cryptocurrency
2
https://spoiler.bet/mcp
predictDEX A
mk.dex
Live Polymarket odds, order books, fee-inclusive quotes and non-custodial prediction trading.
Finance Cryptocurrency Blockchain
111
https://predict.dex.mk/mcp
pdata Prediction Markets A
world.pdata
Polymarket, Kalshi + 6 more prediction markets: live odds, volume, movers. Read-only, no auth.
Finance Open Data
141
https://api.pdata.world/mcp

Related MCP Servers

mcp-foresea
Finance AI & Machine Learning Research & Data
pareelamre
A
license
Not graded
quality
A
maintenance
Calibrated probability forecasts for any resolvable question — with evidence, prediction-market edge (Polymarket/Kalshi), and a live resolved track record.
Updated 19 hours ago (2026-10-27 21:36 UTC)
MIT
event-resolver
Cryptocurrency Finance Web3 & Decentralized Tech
Br0ski777
A
license
Not graded
quality
C
maintenance
Resolves prediction market events with confidence scores by aggregating news, price feeds, and web data, using pay-per-call x402 micropayments.
Updated 2 months ago (2026-09-02 21:18 UTC)
MIT
polymarket-news-mcp
Finance Blockchain
mobymedia
A
license
A
quality
A
maintenance
Connects real-world news to Polymarket prediction markets by matching headlines to relevant markets with live odds. Read-only by default with optional trading capabilities.
Updated 23 days ago (2026-10-05 06:17 UTC)
5
MIT
MCP Predictive Market
Search Finance
EricGrill
A
license
A
quality
D
maintenance
Aggregates prediction market data from 5 major platforms (Manifold, Polymarket, Metaculus, PredictIt, Kalshi), enabling users to search markets, compare odds across platforms, detect arbitrage opportunities, and track predictions through natural language.
Updated 5 months ago (2026-05-20 01:23 UTC)
8
3
MIT