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.8/5 across 9 of 9 tools scored.
Each tool targets a distinct purpose: browsing markets, per-market pricing, history, movers, discrepancies, research, forecaster records, and submitting forecasts. No two tools appear to do the same thing, and the descriptions clearly differentiate similar read-only queries.
All tool names follow a consistent verb_noun pattern: find_, get_, list_, research_, submit_. The verbs are descriptive and uniformly snake_case, making the API predictable.
Nine tools is a well-scoped count for a prediction market aggregation service. Each tool fills a clear role without redundancy, and the count fits comfortably within the ideal 3-15 range.
The tool set covers the full read-only surface for market analysis (list, price, history, movers, discrepancies, research) plus the only write operation (submitting forecasts) and forecaster audit. There are no obvious gaps that would prevent an agent from completing typical user requests.
find_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 (get_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. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnlyHint=true, openWorldHint=true), the description adds valuable context: it explicitly states 'Read-only' and 'not trading advice', explains the empty-array return behavior rather than an error, and clarifies the de-vigged sportsbook consensus mechanism. These details help the agent set expectations beyond what annotations alone provide.
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 informative yet structured with front-loaded purpose and clear use-case blocks. Each sentence adds value: purpose, mechanism, usage, exclusions, safety, and edge-case behavior. No fluff or redundancy; it reads well and earns its length.
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 read-only tool with one parameter and no output schema, the description is remarkably complete. It specifies the output behavior (empty discrepancies array), the restriction logic, the ranking basis, and use cases. The only minor gap is the lack of return field names beyond 'discrepancies', but the description doesn't need to fully document the output shape for an agent to invoke it 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 schema covers the single parameter 'limit' with full description (default, minimum, demo cap, ordering). The description does not add extra meaning about the parameter beyond restating that results are ranked by spread, which is already in the schema. Baseline 3 is appropriate given 100% schema coverage.
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 finds markets where venues disagree most, ranked by cross-market spread, restricted to markets priced by at least two venues. It explicitly names this as the cross-venue arbitrage-and-mispricing view, distinguishing it from related tools like get_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?
The description provides explicit when-to-use guidance ('USE WHEN asked where the market is inconsistent, which venue is mispricing something') and when-not-to-use with named alternatives (get_movers, get_market_history, get_market_probabilities). This gives the agent clear criteria for tool selection.
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 (submit_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. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses extensive behavioral nuance beyond the readOnlyHint and openWorldHint annotations: the 5/20 resolved-forecast thresholds, provisional flag handling, the rule against reporting provisional figures as leaderboard standing, and the plain-explanation behavior for unknown handles. It also clarifies the demo key limitation and that no forecast is created, providing a complete safety profile.
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 long but every sentence carries substantive information, from the Brier/skill explanation to the threshold rules. It is front-loaded with the core purpose and uses clear sections for usage guidance. It is slightly verbose for a tool with a single parameter, but the added detail is necessary for correct invocation and interpretation, so it earns a 4 rather than a 5.
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?
With no output schema, the description fully anticipates the agent's needs: it details what is returned (resolved count, Brier, SkipSeek Score, calibration, skill vs. market), when figures are suppressed or marked provisional, and how to interpret them. It also covers edge cases like unknown handles and private profiles, leaving no critical gaps for an agent to fall into.
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 already covers 100% of the parameter's meaning, including the three accepted forms, case-insensitivity, and optional @ prefix. The tool description adds some context about demo key behavior and own-record reading, but it does not materially enrich parameter syntax beyond what the schema provides, so the baseline of 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 'Read the public forecasting track record behind a SkipSeek handle,' using a specific verb and resource. It explicitly covers both human forecasters and AI agents, and clearly distinguishes from sibling tools like get_market_probabilities and submit_forecast by stating what it does not do.
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 includes an explicit 'USE WHEN' and 'USE SOMETHING ELSE WHEN' section, naming alternative tools for market-related queries and forecast submission. It also gives concrete use cases like auditing your own record and comparing an agent against the market, leaving no ambiguity about when to invoke this tool.
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 (get_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, find_discrepancies or get_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. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark readOnlyHint=true; the description reinforces read-only and adds non-obvious behavior: history starts at ingestion, so short or empty series is not an error. It also specifies ordering and data composition, providing context beyond 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?
Every sentence earns its place: purpose, usage contexts, read-only note, and empty-series caveat. The USE WHEN/SOMETHING ELSE structure makes it easy to scan, and there is no redundant filler.
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?
No output schema exists, so the description compensates by enumerating the returned fields (Fair Probability, venue count, dispersion, cross-market spread) and the empty-series edge case. Combined with the detailed schema, this gives a complete picture for an agent.
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%; both limit and market have detailed descriptions covering defaults, format, and error handling. The tool description does not add parameter-level meaning beyond what the schema already provides, so 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?
States it returns a time series of consensus snapshots for ONE market, oldest first, and lists the included fields. Explicitly distinguishes itself from get_market_probabilities and get_movers by naming them 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?
Provides explicit 'USE WHEN' conditions for trend/drift/spike questions and 'USE SOMETHING ELSE WHEN' for current price or ranked movers, naming the specific sibling tools. This gives clear decision 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 (research_market). 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, find_discrepancies or get_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. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint annotation, the description adds that it is read-only, explains units (probabilities 0-1, gaps in percentage points), and discloses the not-found behavior (returns a plain message, not an error). This meaningfully goes beyond 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 well-structured and front-loaded with the core purpose, followed by explicit usage guidance. Every sentence adds unique information (output components, units, error behavior), with no repetition or filler.
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?
With no output schema, the description thoroughly describes what the response includes (fair probability, venue snapshots, contract match, probability gaps, confidence score), plus units and error handling. It also covers when to use alternatives, making it complete for a single-parameter 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 coverage is 100% and the schema description already fully explains the slug parameter (source, opaque, not-found behavior). The tool description restates the not-found behavior but adds no new parameter semantics beyond the schema, so 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 clearly states the tool 'gives the full current picture for ONE market' with a specific verb+resource+scope, and explicitly distinguishes it from siblings by emphasizing 'ONE' and listing its unique output components (Fair Probability, venue pricing, probability gaps, confidence score).
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 WHEN' sections name alternative tools (list_markets, get_market_history, research_market) and specify exactly when this tool is appropriate (have a slug, need current price or venue discrepancy).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_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 (find_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. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint and openWorldHint annotations, the description discloses that only markets with a comparable ~24h-old snapshot appear, that moves are signed, that ranking uses absolute value, and that an empty array is returned instead of an error. This contextualizes behavior and edge cases effectively.
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 concise but information-dense: core definition, usage rules, and edge-case behavior are each clearly separated. No sentence is wasted, and the structure is coherent.
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?
Even without an output schema, the description explains the return format (movers array, signed move24hPts, empty-array sentinel) and the inclusion criteria. For a single-parameter read-only list tool, this fully covers the necessary context.
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 single 'limit' parameter is already fully described in the schema (default, minimum, meaning, and demo cap), so the description adds no additional parameter semantics. With 100% schema coverage, the baseline score of 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 clearly states it lists markets whose Fair Probability moved most over the last 24 hours, ranked by absolute move in percentage points, with sign convention explicitly defined. It distinguishes itself from sibling tools like get_market_history and find_discrepancies by specifying what it does not do.
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?
Provides explicit 'USE WHEN' conditions (what changed, trending, repriced today) and 'USE SOMETHING ELSE' guidance with named alternatives and the exact distinction (path vs. delta, disagreement vs. change). This is exemplary usage guidance.
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 (find_discrepancies) or the biggest recent moves (get_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 (find_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. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint annotation, the description states 'Read-only: nothing is written and no bet is placed' and discloses that an empty `markets` array is returned (not an error) when no matches exist. This adds behavioral confidence beyond the structured annotation.
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 lengthy, the description is tightly structured: purpose first, then 'START HERE', then USE WHEN/ELSE, then a specific exception, then read-only and error behavior. Every sentence earns its place; the length is justified by the number of siblings and edge cases addressed.
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 tool with 6 parameters, no output schema, and 8 siblings, the description covers return data, filtering, use cases, exclusions, edge-case routing, read-only status, and failure behavior. It is complete enough to select and invoke the tool correctly without needing additional context.
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 covers all 6 parameters at 100% with descriptions, so baseline is 3. The description adds value by advising to raise `limit` rather than paging (mentioning server-side cap at 200) and by telling callers to use list_platforms for venue slugs instead of guessing — practical guidance beyond the schema.
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: 'Browse the SkipSeek board: published prediction markets...' and lists exactly what fields are returned (fair probability, 24h movement, spread, confidence band, venues). It explicitly marks itself as the entry point ('START HERE') and distinguishes from siblings like get_market_probabilities and get_market_history by saying the slug values are needed by every other market tool.
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 USE WHEN conditions ('what is the market saying about X', discover slugs, filter) and USE SOMETHING ELSE alternatives naming specific tools (get_market_probabilities, get_market_history, find_discrepancies, get_movers). It even handles an edge case: not routing sports questions away if the user wants exchange-vs-bookmaker disagreement, which only SkipSeek offers via find_discrepancies.
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 | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint and openWorldHint, but the description adds valuable behavioral context: it asserts the list is 'authoritative' and explains that venues under restrictive data licences are never returned, so the agent should not rely on remembered coverage. This goes beyond the annotations' safety profile to clarify data freshness 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, front-loaded with the resource and fields, followed by clear usage directives. Every sentence earns its place: the first states what is listed, the second gives use cases, the third gives exclusion, and the last explains authority. No waste.
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 zero-parameter listing tool with no output schema, the description is complete: it names the output fields, states the tool is read-only and authoritative, and explains why the list should be treated as current coverage. It fully covers what an agent needs to select and invoke 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 tool has zero parameters, so the baseline is 4. The description does not need to explain input parameters, but it enriches the empty schema by describing the output fields (slug, display name, kind, reliability weight, homepage), which is helpful given there is no output schema.
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 the venues SkipSeek currently publishes, with a specific verb ('list') and resource ('venues'), and enumerates the fields returned (slug, display name, kind, reliability weight, homepage). It also distinguishes itself from siblings by noting it is for venue-level queries, not specific market questions, unlike list_markets or research_market.
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 usage guidance: 'USE WHEN you need a valid platform slug for list_markets, or to answer "where does this number come from"' and 'USE SOMETHING ELSE WHEN the question is about a specific market'. This gives clear when-to-use and when-not-to-use context, although it does not name a specific alternative tool, the exclusion is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
research_marketResearch 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, find_discrepancies or get_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. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Even with readOnlyHint=true, the description adds valuable disclosure: it says 'Read-only', requires a SkipSeek API key, and notes that the shared demo key returns an explanation instead of content. It also explains that markets without a published briefing return an empty result, not an error — all beyond the 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 dense but every sentence adds value: content summary, use-when/use-something-else, auth/key caveat, and empty-result behavior. It is front-loaded with the resource and what it contains, and no sentence is redundant.
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?
With one parameter and no output schema, the description fully covers what the tool returns, how to use the parameter, error behavior, and availability limitations. The tool's complexity is low, but the description leaves no critical gap.
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?
While schema coverage is 100%, the description enhances the 'market' parameter by explaining it is a slug, exactly as returned by other tools, explicitly 'do not construct or guess one', and that a nonexistent slug returns a not-found message. This is crucial operational detail not fully expressed in the schema.
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 names the tool's verb+resource: 'The written SkipSeek briefing for ONE market'. It lists the briefing's contents (pricing implications, changes, yes/no case, catalysts, risk, assessment, source list), making the purpose concrete. It also distinguishes the tool from numeric or trend siblings, so an agent can identify it correctly.
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 explicitly says 'USE WHEN you need reasoning and citations rather than numbers' and 'USE SOMETHING ELSE WHEN you only need the number (get_market_probabilities) or the trend (get_market_history)'. This names alternatives and provides clear exclusions, giving strong guidance on when to choose this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
submit_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 (research_market), 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, find_discrepancies or get_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. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false and idempotentHint=true, and the description adds extensive context: permanence, immutability, one-per-key-per-market restriction, automatic handle minting, Brier scoring, snapshot of market price/Fair Probability, rejection conditions, and demo key behavior. 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 longer than average but structured with clear USE WHEN/USE SOMETHING ELSE sections and front-loaded with purpose and warning. Every sentence adds operational value, though there is minor redundancy in repeatedly emphasizing permanence (e.g., 'permanent, public and IMMUTABLE' followed by 'published... forever').
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 mutating tool with no output schema, the description covers all necessary context: API key requirement, demo key behavior, handle auto-minting, rejection scenarios, return fields (forecast id, handle, URL), and the snapshot mechanism. No significant 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 input schema already provides 100% parameter coverage with rich descriptions (e.g., yes_probability is a decimal 0.01–0.99, not a percentage; rationale is stored verbatim and not scored). The tool description adds only tangential context about market snapshotting, not new parameter-level meaning, so the baseline 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 uses a specific verb+resource: 'Record a probability forecast on ONE SkipSeek market under this API key's own public forecasting handle' and immediately differentiates from siblings by declaring it is the only write tool on the server. This makes its 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?
Explicitly provides USE WHEN scenarios ('building a verifiable track record...') and USE SOMETHING ELSE with named alternatives ('get_market_probabilities', 'get_market_history', etc.). It also warns against speculative or test calls, adding clear boundary conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
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!