Nansen

by io.github.nansen-ai

Overview Discussions Admin

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

Name	Required	Description	Default
`request`	Yes	Request for resolving prediction market names, events, slugs, or URLs.

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed6 schema fields changedOct 28, 2026

addedInput schema / properties / request / additionalProperties
```
Added value: +false
```

removedInput schema / properties / request / anyOf

Removed 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"
-  }
-]

addedInput schema / properties / request / description

Added value: +"Request for resolving prediction market names, events, slugs, or URLs."

addedInput schema / properties / request / properties

Added value: +{
+  "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."
+  }
+}

addedInput schema / properties / request / required
```
Added value: +[
+  "query"
+]
```
addedInput schema / properties / request / type
```
Added value: +"object"
```

Changed3 schema fields changedMay 19, 2026

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"
+  }
+]

AddedMar 25, 2026

TDQS

A4.6/5.0

Behavior4/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 covered; the description adds real substance on top — it names the underlying Polymarket search API, states that results include outcome prices, last trade price and bid/ask inline, and gives a behavioral rule ('if lookup returns no suitable market... say so explicitly — do not silently substitute'). It does not mention pagination behavior or rate limits despite a `page` parameter existing.

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?

Bold section headers ('PM building blocks', 'When to use', 'Query tips', 'Output rules') front-load the routing decision, and the event/market example earns its place because it prevents a wrong `marketId` call. It runs slightly long and some bullets (e.g. the broad multi-topic query warning) are marginal, but there is no true filler.

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?

An output schema exists, so return shape need not be described, and the description still covers the qualitative output contract (inline prices, no silent substitution). For a single nested-request parameter with 100% schema coverage and full annotations, nothing an agent needs in order to call this correctly is missing.

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 100%, so a 3 would be the floor, but the description goes further: it explains that `queryVariant` is a cleaner short keyword form of a slug, that `includeEventMarkets` returns child markets of the best-matching event, and that queries should be 1–3 keywords, which is usage semantics the schema does not convey. The `page` and `status` parameters get no prose treatment.

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

Purpose5/5

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

States a specific verb (Search) and resource (Polymarket events and markets) plus the input forms accepted (name, topic, URL, slug). The 'PM building blocks' section explicitly defines event vs. market and warns that detail tools need `marketId`, not `eventId`, which lets an agent separate this tool from prediction_market_ohlcv and the other PM siblings without opening a schema.

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

Usage Guidelines5/5

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

Has an explicit 'When to use' block that names the trigger condition (topic/slug/URL but no marketId) and names alternatives directly: 'Do NOT use general_search for prediction markets' and 'for price history... use prediction_market_ohlcv'. It also distinguishes the quick probability check case from the history case, which is exactly the boundary an agent needs.

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

All Nansen tools Inspect

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

Need Help?