Skip to main content
Glama

Nansen

by io.github.nansen-ai
OverviewDiscussionsAdmin

Looking up prediction market

prediction_market_lookup
Read-only

Search Polymarket for events and markets by name, topic, URL, or slug.

PM building blocks:

  • An event is a grouped prediction topic containing many child markets.

  • A market is one tradable outcome with its own marketId.

  • Example: 2026 NCAA Tournament Winner is an event; Will Duke win the 2026 NCAA Tournament? is a market. Detail tools require marketId, not eventId.

When to use:

  • First tool when the user asks about a specific PM topic, event, slug, or Polymarket URL but does not provide marketId.

  • Optionally provide queryVariant as a cleaner short keyword version.

  • Set includeEventMarkets to true to also return child markets for the best-matching event.

  • Do NOT use general_search for prediction markets.

  • Results include current outcome prices, last trade price, and bid/ask inline — for a quick probability check you may not need prediction_market_ohlcv. For price history or dated moves, still use prediction_market_ohlcv.

Query tips:

  • Uses Polymarket's search API — natural language queries work well.

  • Prefer short 1–3 keyword queries for best results.

  • Avoid broad multi-topic queries like bitcoin ethereum politics.

Output rules:

  • If lookup returns no suitable market or a mismatched timeframe, say so explicitly — do not silently substitute a nearby market.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
requestYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • removedInput schema / $defs
      Removed value: -{
-  "PredictionMarketLookupRequest": {
-    "description": "Request for resolving prediction market names, events, slugs, or URLs.",
-    "properties": {
-      "includeEventMarkets": {
-        "default": true,
-        "description": "When true, also include child markets for the best-matching event. Useful for event-level questions where market detail tools need the full market slate.",
-        "type": "boolean"
-      },
-      "maxCandidates": {
-        "default": 5,
-        "description": "Maximum number of market and event candidates to return.",
-        "maximum": 10,
-        "minimum": 1,
-        "type": "integer"
-      },
-      "maxEventMarkets": {
-        "default": 12,
-        "description": "Maximum number of child markets to show when includeEventMarkets is true. The output always states how many of the event's total markets are shown.",
-        "maximum": 50,
-        "minimum": 1,
-        "type": "integer"
-      },
-      "page": {
-        "default": 1,
-        "description": "Page number for paginated results.",
-        "minimum": 1,
-        "type": "integer"
-      },
-      "query": {
-        "description": "Prediction market name, topic, Polymarket URL, or URL slug to resolve to candidate market IDs.",
-        "minLength": 1,
-        "type": "string"
-      },
-      "queryVariant": {
-        "anyOf": [
-          {
-            "type": "string"
-          },
-          {
-            "type": "null"
-          }
-        ],
-        "default": null,
-        "description": "Optional second short query variant to search alongside query, such as a cleaner keyword version of a slug."
-      },
-      "status": {
-        "anyOf": [
-          {
-            "type": "string"
-          },
-          {
-            "type": "null"
-          }
-        ],
-        "default": "active",
-        "description": "Optional lifecycle filter for markets/events. Defaults to 'active'. Use 'all' to include closed markets."
-      }
-    },
-    "required": [
-      "query"
-    ],
-    "type": "object"
-  }
-}
    • addedInput schema / additionalProperties
      Added value: +false
    • changedInput schema / properties / request / anyOf
      Previous value: -[
-  {
-    "additionalProperties": true,
-    "type": "object"
-  },
-  {
-    "$ref": "#/$defs/PredictionMarketLookupRequest"
-  }
-]New value: +[
+  {
+    "additionalProperties": true,
+    "type": "object"
+  },
+  {
+    "additionalProperties": false,
+    "description": "Request for resolving prediction market names, events, slugs, or URLs.",
+    "properties": {
+      "includeEventMarkets": {
+        "default": true,
+        "description": "When true, also include child markets for the best-matching event. Useful for event-level questions where market detail tools need the full market slate.",
+        "type": "boolean"
+      },
+      "maxCandidates": {
+        "default": 5,
+        "description": "Maximum number of market and event candidates to return.",
+        "maximum": 10,
+        "minimum": 1,
+        "type": "integer"
+      },
+      "maxEventMarkets": {
+        "default": 12,
+        "description": "Maximum number of child markets to show when includeEventMarkets is true. The output always states how many of the event's total markets are shown.",
+        "maximum": 50,
+        "minimum": 1,
+        "type": "integer"
+      },
+      "page": {
+        "default": 1,
+        "description": "Page number for paginated results.",
+        "minimum": 1,
+        "type": "integer"
+      },
+      "query": {
+        "description": "Prediction market name, topic, Polymarket URL, or URL slug to resolve to candidate market IDs.",
+        "minLength": 1,
+        "type": "string"
+      },
+      "queryVariant": {
+        "anyOf": [
+          {
+            "type": "string"
+          },
+          {
+            "type": "null"
+          }
+        ],
+        "default": null,
+        "description": "Optional second short query variant to search alongside query, such as a cleaner keyword version of a slug."
+      },
+      "status": {
+        "anyOf": [
+          {
+            "type": "string"
+          },
+          {
+            "type": "null"
+          }
+        ],
+        "default": "active",
+        "description": "Optional lifecycle filter for markets/events. Defaults to 'active'. Use 'all' to include closed markets."
+      }
+    },
+    "required": [
+      "query"
+    ],
+    "type": "object"
+  }
+]
  2. Added

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already declare readOnlyHint=true, openWorldHint=true, and destructiveHint=false, so the safety profile is known. The description adds valuable behavioral context beyond this: it uses Polymarket's search API, natural language queries work well, recommends short 1–3 keyword queries, and mandates explicit statement when no suitable market is found rather than silently substituting. These behaviors are not inferable from annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is lengthy but well-structured with clear section headers (PM building blocks, When to use, Query tips, Output rules) and a helpful example event vs. market. Each sentence serves a purpose, though it could be tightened without losing value. It is front-loaded with the core purpose and uses formatting to improve scannability.

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

Completeness5/5

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

Given the tool's complexity (nested request object, multiple configuration flags, integration with detail tools), the description is remarkably complete. It explains the event/market relationship, when to use this versus prediction_market_ohlcv, the importance of marketId for detail tools, query strategy, and output honesty rules. The presence of an output schema covers return values, so the description fills every other gap.

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

Parameters4/5

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

Schema description coverage is 0% for the top-level 'request' parameter, though nested properties have descriptions. The tool description compensates by explaining the purpose of queryVariant ('cleaner short keyword version') and includeEventMarkets ('also return child markets... for detail tools'), which adds meaning beyond the schema. It does not explicitly describe all parameters (e.g., maxCandidates, maxEventMarkets), but the schema covers those and the description's additions are genuine and useful.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource ('Search Polymarket for events and markets') and lists the search dimensions (name, topic, URL, slug). It also clarifies the event vs. market distinction, which differentiates it from siblings like general_search and prediction_market_ohlcv. The purpose is unambiguous and the tool is clearly distinguished.

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

Usage Guidelines5/5

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

A dedicated 'When to use:' section explicitly states this is the first tool when the user provides a topic/event/slug/URL but no marketId. It explicitly says 'Do NOT use general_search for prediction markets' and routes price history queries to prediction_market_ohlcv. It also explains when to set includeEventMarkets and queryVariant, providing clear context and exclusions.

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

All Nansen toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources