Polymarket, Manifold, Metaculus compared: one fair probability per question. No API key needed.
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Average 4.7/5 across 9 of 9 tools scored.
Every tool targets a distinct resource and action: create_forecast is the only write tool, get_* reads single entities (market probabilities, history, research, forecaster record), and list_* scans collections (markets, movers, discrepancies, platforms). No two tools overlap in purpose, and the three market reads are clearly separated as current vs. historical vs. qualitative.
All tool names follow a consistent snake_case verb_noun pattern: get_ for single-item reads, list_ for collection reads, and create_ for the sole write operation. There are no mixed conventions or vague verbs.
9 tools is well-scoped for a prediction-market server: one deliberate write action, four single-market/forecaster reads, and four collection-browsing tools. Nothing feels redundant, and the count is right in the sweet spot for the domain.
The server covers the core workflow: discover markets (list_markets), analyze current price/history/research (get_market_*), detect cross-venue disagreement and movement (list_discrepancies, list_movers, list_platforms), and commit a forecast (create_forecast) with auditing via get_forecaster_record. A minor gap is the lack of a tool to fetch a single forecast's details after submission, though the returned URL and aggregate record mitigate this.
create_forecastSubmit a forecast (writes a permanent public record)ARecord a probability forecast on ONE SkipSeek market under this API key's own public forecasting handle, and have it scored automatically by Brier loss when the market resolves. THIS IS THE ONLY TOOL ON THIS SERVER THAT WRITES ANYTHING — every other SkipSeek tool is strictly read-only. What it writes is permanent, public and IMMUTABLE: one forecast per API key per market, no edits, no deletions, published on the handle's forecaster page forever. Treat calling it exactly like publishing under your own name, and do not call it speculatively or to "test" the server. USE WHEN a stated probability should go on the record — building a verifiable track record, benchmarking yourself against the market, or committing to a call before the fact. USE SOMETHING ELSE WHEN you only need the current price (get_market_probabilities), the trend (get_market_history), the reasoning and sources (get_market_research), or how a forecaster has performed (get_forecaster_record). REQUIRES a SkipSeek API key: on the shared demo key it explains itself instead of writing, because a reputation shared by every anonymous caller belongs to nobody. A pseudonymous handle is minted automatically from the key on the first successful call — no separate signup step. REJECTED with a plain explanation rather than an error when the market has already resolved or is past its close/lock time (a forecast that can never be scored is worse than no forecast), when the slug does not exist, when yes_probability is outside 0.01–0.99, or when this key already has a forecast on that market. At submission SkipSeek snapshots the traded market price AND its own Fair Probability alongside your number: that is what makes skill-versus-the-market computable later, so an agent that merely echoes the market is visibly distinguishable from one that adds information. Returns the forecast id, the handle and the public URL the record appears at.
| Name | Required | Description | Default |
|---|---|---|---|
| market | Yes | Slug of the market to forecast, exactly as returned in the `slug` field by list_markets, list_discrepancies or list_movers (e.g. "fed-cuts-rates-by-september"). Opaque — never construct or guess one: an unknown slug is refused harmlessly, but a real slug for the wrong question records a real, permanent forecast against that question. | |
| rationale | No | Optional short reasoning — ideally what evidence moved you off the market price. Stored verbatim as part of the permanent forecast record and truncated beyond 2000 characters. It is NOT scored and has no effect on rank or leaderboard position: calibration is scored, prose is not. Omit it rather than padding it. | |
| yes_probability | Yes | Your probability that this market resolves YES, as a decimal between 0.01 and 0.99 — 0.35 means 35%. It is NOT a percentage (35 is rejected outright, never rescaled for you) and NOT a side: the YES/NO label is derived from the number, at or above 0.5 being YES. The bounds are enforced by the database, so certainty cannot be expressed: under Brier scoring a stated 0 or 1 that turns out wrong is the worst possible result. Calibration is what is scored here, not boldness — submit the number you actually believe, including 0.5 when you genuinely do not know. |
| Name | Required | Description |
|---|---|---|
| note | No | |
| tier | No | |
| handle | No | |
| market | No | |
| notice | No | Set INSTEAD of data when the call succeeded but has nothing to return: unknown slug, empty result, a tool not on this tier, or quota spent. Not an error. |
| source | No | |
| scoring | No | |
| locks_at | No | |
| immutable | No | Always true. No edit or delete path exists. |
| rationale | No | |
| public_url | No | |
| attribution | No | |
| forecast_id | No | |
| generated_at | No | |
| market_title | No | |
| submitted_at | No | |
| selected_side | No | |
| yes_probability | No | Decimal 0.01-0.99, not a percentage. |
| requests_remaining_today | No | |
| fair_probability_at_submission | No | |
| market_probability_at_submission | No | The baseline skill is measured against later. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes well beyond the annotations by disclosing permanence, publicness, immutability, one-forecast-per-key-per-market, no edits/deletions, rejection conditions (resolved, nonexistent slug, out-of-bounds probability, duplicate), the snapshot of market price and Fair Probability, and the return fields. It also warns against speculative use, aligning with the openWorldHint and idempotentHint while providing concrete context. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Although lengthy, every sentence earns its place given the tool's permanent and consequential nature. The description is front-loaded with the most critical fact (only writing tool), uses structured 'USE WHEN'/'USE SOMETHING ELSE' blocks, and avoids fluff. The length is justified by the need to warn users about irreversible actions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex tool that permanently writes a public record, the description covers prerequisites, side effects, failure modes, return values, and the broader purpose ('skill-versus-the-market computable later'). It is self-contained and leaves no major gap in understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with rich descriptions for all three parameters, so the baseline is 3. The description adds meaningful context beyond the schema, such as explaining why bounds exist ('under Brier scoring a stated 0 or 1 that turns out wrong is the worst possible result') and emphasizing that calibration is scored, not boldness. This adds value without repetition.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb+resource: 'Record a probability forecast on ONE SkipSeek market' and immediately distinguishes itself from siblings: 'THIS IS THE ONLY TOOL ON THIS SERVER THAT WRITES ANYTHING — every other SkipSeek tool is strictly read-only.' This is unambiguous and fully covers what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use and when-not-to-use guidance, naming the concrete sibling tools: 'USE WHEN... building a verifiable track record... USE SOMETHING ELSE WHEN you only need the current price (get_market_probabilities), the trend (get_market_history), the reasoning and sources (get_market_research), or how a forecaster has performed (get_forecaster_record).' It also covers the API key prerequisite and shared demo key behavior.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_forecaster_recordGet a forecaster or agent track recordARead the public forecasting track record behind a SkipSeek handle — a human forecaster or an AI agent, the same shape for both, with forecaster_kind saying which. Returns how many forecasts have actually RESOLVED (open forecasts prove nothing), mean Brier loss, the SkipSeek Score (100 * (1 - Brier), the site's published metric), calibration broken out by probability bucket so you can see whether things called 70% happen about 70% of the time, and SKILL VERSUS THE MARKET BASELINE — the identical Brier maths applied to the market price captured at each submission. Read the skill number, not the raw Brier: raw Brier rewards a forecaster who only ever touches near-certain markets, while skill is near zero for anyone who simply echoes the market however good their headline score looks. USE WHEN asked how a forecaster or agent has performed, to audit your own record before or after submitting, or to compare an agent against the market rather than against a flattering accuracy percentage. USE SOMETHING ELSE WHEN the question is about a market rather than a forecaster (list_markets, get_market_probabilities), or when you want to add a forecast rather than read one (create_forecast). Read-only: nothing is written and no forecast is created. Callable on the shared demo key for any public handle. Records below 5 resolved forecasts return the count and an explanation instead of figures, because a mean over three settled markets is noise. Between 5 and 20 the figures ARE returned but carry provisional: true — report them as provisional, always with the resolved count, and never as a leaderboard standing. Ranking against other forecasters begins at 20. Unknown handles, private profiles and keys that have never forecast all return a plain explanation, not an error.
| Name | Required | Description | Default |
|---|---|---|---|
| handle | No | WHICH forecaster to read. Accepts exactly three forms, in this order of preference. (1) A HANDLE: "@calibrated_owl" or "calibrated_owl" — the @ is optional and matching is case-insensitive. (2) A PUBLIC ID: the uuid as it appears in a https://skipseek.com/forecasters/<id> URL, useful when you have the link but not the name. (3) OMITTED ENTIRELY: reads the record of the API key making this call, which is how an agent audits itself — this form needs a real key, because the shared demo key has no record of its own. Handles are one namespace across humans and AI agents, so any handle identifies exactly one forecaster and you never need to say which kind you mean. |
| Name | Required | Description |
|---|---|---|
| note | No | |
| tier | No | |
| handle | No | |
| notice | No | Set INSTEAD of data when the call succeeded but has nothing to return: unknown slug, empty result, a tool not on this tier, or quota spent. Not an error. |
| source | No | |
| published | No | |
| mean_brier | No | LOWER is better. Do not lead with it - it rewards forecasting only near-certain markets. |
| public_url | No | |
| attribution | No | |
| calibration | No | |
| methodology | No | |
| provisional | No | When true, report the figures as provisional alongside resolved_forecasts, never as a standing. |
| accuracy_pct | No | The most flattering and least informative figure here. |
| generated_at | No | |
| skipseek_score | No | 100 * (1 - mean Brier); inherits the same bias. |
| forecaster_kind | No | |
| skill_vs_market | No | THE NUMBER TO READ: `brier_skill` above 0 beats the market, about 0 means the forecaster is reproducing it, below 0 is worse. |
| ranking_threshold | No | |
| resolved_forecasts | No | Open forecasts prove nothing; read every figure here against this count. |
| publication_threshold | No | |
| requests_remaining_today | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes far beyond annotations (readOnlyHint, openWorldHint). It details edge-case behavior: records below 5 resolved forecasts return count/explanation, between 5 and 20 return provisional figures that must be reported as provisional, and unknown handles return plain explanations instead of errors. It also clarifies that ranking begins at 20, adding critical behavioral nuance not visible in annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Although long, every sentence earns its place. The structure is clear: purpose, output details, usage guidance, edge cases. The USE WHEN/USE SOMETHING ELSE sections are clearly delineated. No redundancy or filler; the length is justified by the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the output shape (Brier, SkipSeek Score, calibration, skill vs market), provisional thresholds, unknown handle behavior, and the distinction between raw Brier and skill. Combined with the detailed schema and output schema, the description is fully complete for an agent to invoke and interpret the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already has a 100% descriptive coverage for the handle parameter, including accepted forms, case-insensitivity, and the omitted form for self-audit. The main description adds minimal parameter information beyond that, but the schema fully handles semantics. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Read the public forecasting track record behind a SkipSeek handle — a human forecaster or an AI agent.' It clearly states the purpose, scope, and differentiates from siblings by mentioning the unified shape for humans/agents and the forecaster_kind field. This is a definitive, unambiguous purpose statement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit 'USE WHEN' and 'USE SOMETHING ELSE' sections list concrete cases: auditing track records, comparing agents against the market, and alternatives like list_markets or create_forecast. This provides clear decision guidance and names sibling tools, making it easy for an agent to choose correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_market_historyMarket probability historyATime series of consensus snapshots for ONE market, oldest first: Fair Probability, how many venues fed each snapshot, dispersion between them, and the cross-market spread at that moment. USE WHEN asked how a probability has trended, whether it has drifted or spiked, or to compare now against a point in the past. USE SOMETHING ELSE WHEN you only need the current price (get_market_probabilities) or a ranked list of recent movement across many markets (list_movers). Read-only. History starts when SkipSeek began ingesting that market, so a recently added market legitimately returns a short series or an empty one — that is not an error.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum snapshots to return, keeping the most recent and still ordered oldest-first. Defaults to 100. Demo callers get at most 5. | |
| market | Yes | Market slug, exactly as returned in the `slug` field by list_markets, list_discrepancies or list_movers (e.g. "fed-cuts-rates-by-september"). Opaque — do not construct or guess one; a slug that does not exist returns a not-found message rather than data. |
| Name | Required | Description |
|---|---|---|
| tier | No | |
| market | No | |
| notice | No | Set INSTEAD of data when the call succeeded but has nothing to return: unknown slug, empty result, a tool not on this tier, or quota spent. Not an error. |
| source | No | |
| attribution | No | |
| generated_at | No | |
| consensus_history | No | OLDEST FIRST. |
| requests_remaining_today | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint annotation, the description adds critical behavioral context: history starts when SkipSeek began ingesting the market, so a short or empty series is legitimate and not an error. It also clarifies ordering (oldest first) and the semantic meaning of the snapshots. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is moderately long but every sentence earns its place: it front-loads the core purpose, then usage guidance, then an important caveat. It is well-structured with clear transitions, though slightly verbose compared to the most minimal examples. A 4 reflects strong structure with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists, the description need not explain return values. It covers purpose, usage timing, alternatives, data semantics, and edge-case behavior (empty series). This is complete for a tool of this complexity, especially with the rich sibling differentiation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description does not add new parameter-level meaning beyond what the schema already provides (e.g., limit behavior, market slug sourcing). It does mention 'ONE market' which reinforces the market parameter's singular nature, but this is already clear from the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb+resource ('Time series of consensus snapshots for ONE market') and details the exact contents (Fair Probability, venue count, dispersion, cross-market spread). It clearly distinguishes itself from sibling tools like get_market_probabilities and list_movers by naming them in the usage guidance.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit 'USE WHEN' conditions (trend, drift/spike, compare to past) and explicit 'USE SOMETHING ELSE WHEN' conditions with named alternatives (get_market_probabilities for current price, list_movers for ranked movement). This is textbook usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_market_probabilitiesGet one market, venue by venueAThe full current picture for ONE market: the SkipSeek Fair Probability, every venue pricing it with that venue's own price snapshot and how closely its contract matches the standardized question, each venue's signed Probability Gap against fair value (labelled Market Premium, Market Discount, In Line or Cross-Market Discrepancy), and the latest confidence score and band. USE WHEN you have a slug and need where the price stands now, or to answer "which venue is out of line and by how much". USE SOMETHING ELSE WHEN you do not have a slug yet (list_markets), when you need how the price MOVED over time (get_market_history), or when you want the written analysis and its cited sources (get_market_research). Read-only. Probabilities are 0–1; gaps are in percentage points. An unknown slug returns a plain not-found message, not an error.
| Name | Required | Description | Default |
|---|---|---|---|
| market | Yes | Market slug, exactly as returned in the `slug` field by list_markets, list_discrepancies or list_movers (e.g. "fed-cuts-rates-by-september"). Opaque — do not construct or guess one; a slug that does not exist returns a not-found message rather than data. |
| Name | Required | Description |
|---|---|---|
| gaps | No | |
| tier | No | |
| market | No | |
| notice | No | Set INSTEAD of data when the call succeeded but has nothing to return: unknown slug, empty result, a tool not on this tier, or quota spent. Not an error. |
| source | No | |
| sources | No | |
| confidence | No | |
| attribution | No | |
| generated_at | No | |
| fair_probability | No | Decimal 0-1. |
| requests_remaining_today | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint, but the description adds significant behavioral context: probabilities are 0–1, gaps are in percentage points, and an unknown slug returns a not-found message rather than an error. It also explains the meaning of labels like Market Premium/Discount. This goes well beyond the annotations and sets accurate expectations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is organized with a clear first sentence enumerating outputs, followed by explicit USE WHEN/USE SOMETHING ELSE blocks. Though the opening sentence is dense and packs many clauses, every part earns its place and the structure makes scanning easy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a single parameter, an output schema, and strong annotations, the description is fully complete: it covers purpose, usage conditions, alternatives, units, error behavior, and output labels. No important context is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the schema's 'market' description already details slug format, opacity, and not-found behavior. The tool description repeats this guidance but adds no new parameter-level semantics beyond reinforcing 'when you have a slug'. Baseline 3 is appropriate since the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'the full current picture for ONE market' with detailed output components (Fair Probability, venue pricing, Probability Gap labels). It distinguishes from siblings by explicitly naming list_markets, get_market_history, and get_market_research as alternatives, so the agent knows exactly what this tool uniquely provides.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit usage rules: 'USE WHEN you have a slug and need where the price stands now' and lists concrete alternatives with when to use them (list_markets without a slug, get_market_history for movement, get_market_research for written analysis). This fully guides tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_market_researchResearch briefing for a marketAThe written SkipSeek briefing for ONE market: what the pricing implies, what changed, the yes case and no case, catalysts and upcoming dates, resolution risk, an overall assessment with a confidence band and stated limitations — plus the source list behind it, with primary sources flagged. USE WHEN you need reasoning and citations rather than numbers, e.g. "why is this priced at 34%" or "what would move this". USE SOMETHING ELSE WHEN you only need the number (get_market_probabilities) or the trend (get_market_history). Read-only. Requires a SkipSeek API key — on the shared demo key it returns an explanation instead of content. Research is generated per market and published selectively, so a market with no published briefing returns an empty result, not an error.
| Name | Required | Description | Default |
|---|---|---|---|
| market | Yes | Market slug, exactly as returned in the `slug` field by list_markets, list_discrepancies or list_movers (e.g. "fed-cuts-rates-by-september"). Opaque — do not construct or guess one; a slug that does not exist returns a not-found message rather than data. |
| Name | Required | Description |
|---|---|---|
| tier | No | |
| market | No | |
| notice | No | Set INSTEAD of data when the call succeeded but has nothing to return: unknown slug, empty result, a tool not on this tier, or quota spent. Not an error. |
| source | No | |
| sources | No | |
| research | No | |
| attribution | No | |
| generated_at | No | |
| requests_remaining_today | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint annotation, the description discloses the API key requirement, the demo-key behavior ('returns an explanation instead of content'), and the empty-result-for-unpublished-market behavior. It also warns that a nonexistent slug returns a not-found message rather than data, covering boundary cases well.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the briefing contents and use cases, then exclusions, then operational notes. Every sentence carries distinct information with no fluff, and the use-case guidance is separated into clear directive phrases.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the single-parameter schema, existing output schema, and annotations, the description covers all necessary context: expected input, auth, result content, edge cases, and exclusions. It leaves no ambiguity about what the tool returns or when to call it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The parameter description in the schema is already thorough, and the tool description adds crucial guidance: the slug must come exactly from sibling list endpoints, it is opaque and must not be constructed, and a bad slug yields a not-found message. This fully compensates and enriches the schema's meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states exactly what the tool returns: a written briefing for one market including pricing implications, yes/no cases, catalysts, risk, confidence band, limitations, and a source list. It explicitly contrasts with sibling tools get_market_probabilities and get_market_history, making the tool's unique purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit when-to-use guidance ('USE WHEN you need reasoning and citations rather than numbers') and when-not-to-use guidance with named alternatives ('USE SOMETHING ELSE WHEN you only need the number...'). It also informs users about empty results for unpublished briefings, setting accurate expectations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_discrepanciesFind cross-venue disagreementAMarkets where venues disagree most, ranked by cross-market spread in percentage points, restricted to markets priced by at least two venues (a spread needs two sides). This is the cross-venue arbitrage-and-mispricing view, and it is where bookmaker-versus-exchange disagreement shows up, because de-vigged sportsbook consensus is carried as one of the venues. USE WHEN asked where the market is inconsistent, which venue is mispricing something, or for the widest gaps right now. USE SOMETHING ELSE WHEN you care about change over time rather than disagreement at a moment (list_movers, get_market_history), or when you need one named market (get_market_probabilities). Read-only, and explicitly not trading advice. Returns an empty discrepancies array, not an error, when nothing currently trades on two or more venues.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum rows to return, widest spread first. Defaults to 20. Demo callers get at most 5. |
| Name | Required | Description |
|---|---|---|
| tier | No | |
| notice | No | Set INSTEAD of data when the call succeeded but has nothing to return: unknown slug, empty result, a tool not on this tier, or quota spent. Not an error. |
| source | No | |
| attribution | No | |
| generated_at | No | |
| discrepancies | No | Not trading advice: a wide spread can mean the venues are pricing subtly different questions - check `match_type`. |
| requests_remaining_today | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint annotation, the description adds that it is 'explicitly not trading advice,' explains the empty-array behavior when no market qualifies, and reveals that the de-vigged sportsbook consensus is carried as one venue—context that affects interpretation. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is moderately long but well-structured, front-loading the core function and then delivering usage guidance in clear uppercase markers. Every sentence contributes value, though it could be tightened slightly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the conceptual complexity of cross-venue disagreement, the description provides a complete picture: what the data represents, why it exists, when to use it, and an important edge case (empty array). With an output schema present and one well-documented parameter, no gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description for the sole parameter (limit) is fully self-explanatory, covering defaults and demo limits. The tool description adds no additional semantics for the parameter, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists markets where venues disagree, ranked by cross-market spread, with a restriction to markets priced by at least two venues. It distinguishes itself from siblings by framing this as the cross-venue arbitrage-and-mispricing view and contrasting with list_movers and get_market_history.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states when to use the tool ('USE WHEN asked where the market is inconsistent, which venue is mispricing something, or for the widest gaps right now') and when to use something else with named alternatives (list_movers, get_market_history, get_market_probabilities). This gives clear decision criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_marketsList prediction marketsABrowse the SkipSeek board: published prediction markets with the SkipSeek Fair Probability (a cross-venue consensus of every venue trading the same standardized question), 24h movement in percentage points, cross-market spread, confidence band, and which venues price each market. START HERE — the slug values it returns are what every other market tool needs. USE WHEN the question is "what is the market saying about X", to discover slugs, or to filter by category/venue/status. USE SOMETHING ELSE WHEN you already hold a slug (get_market_probabilities for the current per-venue picture, get_market_history for the time series), when you want the widest cross-venue disagreement (list_discrepancies) or the biggest recent moves (list_movers), or when the question is a single sports fixture and you only need its fair price — that is SkipOdds at https://skipodds.com/mcp. Do NOT route a sports question away when the user wants to know whether the EXCHANGE disagrees with the BOOKMAKERS on that fixture: SkipSeek carries de-vigged sportsbook consensus as one venue alongside the prediction markets, so that comparison exists only here (list_discrepancies). Read-only: nothing is written and no bet is placed. Returns an empty markets array, not an error, when no published market matches the filters.
| Name | Required | Description | Default |
|---|---|---|---|
| sort | No | Ordering: "volume" (default; most-sourced first), "movement" (largest 24h swing), "discrepancy" (widest cross-venue spread), "quality" (highest confidence score), "closing" (soonest to close), "newest". | volume |
| limit | No | Maximum markets to return. Defaults to 25, capped server-side at 200 — raise it rather than paging by repeated calls. Demo callers get at most 5 regardless. | |
| query | No | Case-insensitive substring match on the market title, e.g. "Fed" or "Bitcoin". Free text, not a boolean query language. | |
| status | No | Restrict to one lifecycle status as stored on the market, e.g. "open". Omit to include every published market regardless of status. | |
| category | No | Restrict to one category by slug, e.g. "politics", "economics", "crypto", "world", "tech", "sports". Omit for all categories. An unknown slug simply matches nothing. | |
| platform | No | Restrict to markets priced by one venue, by venue slug (e.g. "polymarket"). Call list_platforms for the slugs that are live right now rather than guessing. |
| Name | Required | Description |
|---|---|---|
| tier | No | |
| notice | No | Set INSTEAD of data when the call succeeded but has nothing to return: unknown slug, empty result, a tool not on this tier, or quota spent. Not an error. |
| source | No | |
| markets | No | |
| attribution | No | |
| generated_at | No | |
| requests_remaining_today | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint, but the description adds concrete behavioral context: read-only confirmation, empty-array behavior instead of error, demo caller cap, and the fact that slug values are prerequisites for other tools. This goes well beyond annotation data and helps the agent predict behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Though longer than average, every sentence earns its place: purpose, usage, exclusion criteria, edge-case nuance, and behavioral notes are each in a distinct segment. The structure is front-loaded and scannable, with no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the rich annotations and detailed input schema, the description covers all necessary context: what the tool returns, why it is the entry point, when to use alternatives, and edge-case behaviors. The presence of an output schema means return values need not be spelled out, and this description is complete for an AI agent to select and invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description doesn't add much parameter-level detail beyond the schema; it mentions filtering by category/venue/status and emphasizes slug output, but that is more about overall semantics than individual parameters. No contradiction or gap requires a lower score, but no meaningful extra hint beyond schema exists.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a clear verb+resource statement ('Browse the SkipSeek board: published prediction markets') and immediately highlights the key output (`slug` values). It explicitly distinguishes from siblings by naming alternatives, so purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides explicit 'START HERE', 'USE WHEN', and 'USE SOMETHING ELSE WHEN' guidance, naming specific sibling tools for each scenario. It even addresses a nuanced edge case (sports bettor vs. bookmaker disagreement) and tells when not to route away, which is exemplary guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_moversBiggest 24-hour moversAMarkets whose Fair Probability moved most over the last 24 hours, ranked by absolute move in percentage points, signed so a negative move24hPts means the probability fell. Only markets with a comparable snapshot from ~24h ago appear. USE WHEN asked what changed, what is trending, or which forecasts repriced today. USE SOMETHING ELSE WHEN you want the full path of one market rather than a single 24h delta (get_market_history), or disagreement between venues rather than change over time (list_discrepancies). Read-only. Returns an empty movers array, not an error, when nothing has a 24h comparison yet — that is normal shortly after a market is first ingested.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum rows to return, largest absolute move first. Defaults to 20. Demo callers get at most 5. |
| Name | Required | Description |
|---|---|---|
| tier | No | |
| movers | No | Ranked by ABSOLUTE move, but `move24hPts` stays signed - read the sign before saying a probability rose. |
| notice | No | Set INSTEAD of data when the call succeeded but has nothing to return: unknown slug, empty result, a tool not on this tier, or quota spent. Not an error. |
| source | No | |
| attribution | No | |
| generated_at | No | |
| requests_remaining_today | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark readOnlyHint=true, but the description adds behavioral context beyond that: signed move values, requirement for a comparable 24h snapshot, ranking by absolute move, and the empty `movers` array return instead of an error. These details manage agent expectations and prevent misinterpretation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact but structured: definition, edge case, usage guidance, and behavioral note. Every sentence adds value, with no repetition or filler. The length is justified by the clarity it provides.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema, the description does not need to re-explain return fields. It covers the empty-array condition, the snapshot requirement, and clearly delineates alternatives. The tool is fully contextualized for an AI agent without needing additional information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage for the single `limit` parameter is 100%, so the schema fully explains it. The description mentions ranking and the delta field but does not add new semantic detail for the parameter itself. Baseline 3 is appropriate 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.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists markets whose Fair Probability moved most over the last 24 hours, ranked by absolute move in percentage points. It uses a specific verb ('list') + resource ('markets') + scope ('24-hour movers'), and it distinguishes itself from siblings by referencing get_market_history and list_discrepancies as alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit 'USE WHEN' guidance is given for trending/reprized questions, and 'USE SOMETHING ELSE WHEN' explicitly names alternatives (get_market_history for full paths, list_discrepancies for venue disagreement). This is exactly the level of guidance needed for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_platformsList covered venuesAThe venues SkipSeek currently publishes: slug, display name, kind (exchange, sportsbook_consensus, poll or model), the reliability weight that venue carries in the consensus, and its homepage. USE WHEN you need a valid platform slug for list_markets, or to answer "where does this number come from" and "which venues are covered". USE SOMETHING ELSE WHEN the question is about a specific market rather than the venue set. Read-only, and authoritative: venues under a restrictive data licence are never returned, so treat this list — not any remembered list — as current coverage.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| tier | No | |
| notice | No | Set INSTEAD of data when the call succeeded but has nothing to return: unknown slug, empty result, a tool not on this tier, or quota spent. Not an error. |
| source | No | |
| platforms | No | Current coverage, authoritative: venues under a restrictive licence are never returned. |
| attribution | No | |
| generated_at | No | |
| requests_remaining_today | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral details beyond the readOnlyHint and openWorldHint annotations: it states the tool is 'authoritative', explains that restricted venues are never returned, and instructs treating it as current coverage rather than memory. This gives useful context about data completeness and licensing constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear USE WHEN/USE SOMETHING ELSE markers. It is concise but information-dense, covering output fields, use cases, and an important caveat in about 100 words. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with an output schema and zero params, the description fully covers purpose, usage, and key behavioral caveats. It leaves no obvious gap for an agent to select or invoke the tool incorrectly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With zero parameters, the description does not need to elaborate on params. The baseline for 0 params is 4, and the description appropriately focuses on output and usage rather than misleading parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists venues published by SkipSeek with specific fields (slug, display name, kind, reliability weight, homepage). It distinguishes itself from siblings like list_markets and list_discrepancies by focusing on the venue set rather than individual markets.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly provides USE WHEN scenarios: needing a valid platform slug for list_markets, or answering questions about venue coverage. Also gives a clear exclusion: USE SOMETHING ELSE for specific market questions, directing to alternatives. This is exemplary guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity — fastest for official registry listings. For a namespace such as io.github.alice/server, link the matching GitHub user or an account that owns the GitHub organization, then choose Claim with GitHub.
HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at /.well-known/glama.json on the same origin as the connector, then choose Check HTTP challenge.
DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!