Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@polymarket-mcp search for markets related to crypto"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
The Polymarket MCP Server enables AI agents to interact with Polymarket, a leading prediction market platform on Polygon. This server provides comprehensive access to market data, real-time pricing, order books, and trading capabilities through the Polymarket API.
By implementing the Model Context Protocol (MCP), this server allows Large Language Models (LLMs) to discover prediction markets, analyze odds (probabilities), execute trades, and track portfolio positions directly through their context window, bridging the gap between AI and decentralized prediction markets.
Related MCP server: Polymarket MCP Server
Market Discovery: Search and filter prediction markets by keywords, tags, and status.
Real-time Pricing: Access live price data, implied probabilities, and depth-of-market (order books) for any outcome token.
Trading Capabilities: Place limit orders, market orders, and manage open orders (requires private key).
Portfolio Tracking: Monitor user positions, trade history, and balances for specific wallet addresses.
Order Management: View, cancel, and manage open orders across all markets.
To use this server without installing it globally:
npx @iqai/mcp-polymarketgit clone https://github.com/IQAIcom/mcp-polymarket.git
cd mcp-polymarket
pnpm install
pnpm run buildAdd the following configuration to your MCP client settings (e.g., claude_desktop_config.json).
{
"mcpServers": {
"polymarket": {
"command": "npx",
"args": ["-y", "@iqai/mcp-polymarket"]
}
}
}{
"mcpServers": {
"polymarket": {
"command": "npx",
"args": ["-y", "@iqai/mcp-polymarket"],
"env": {
"POLYMARKET_PRIVATE_KEY": "your_private_key_here",
"POLYGON_RPC_URL": "https://polygon-mainnet.g.alchemy.com/v2/<YOUR_KEY>"
}
}
}
}Variable | Required | Description | Default |
| No | Private key for trading (enables trading tools) | - |
| No | Polygon RPC URL for transactions |
|
| No | Polymarket CLOB API base URL |
|
| No | Blockchain network chain ID |
|
| No | Order signature type ( |
|
| No | Funder address for transactions | - |
| No | Alternative funder address (alias) | - |
"What are the most active prediction markets on Polymarket right now?"
"Search for markets related to 'Bitcoin' or 'BTC'."
"Find markets in the 'Crypto' category."
"What events are trending on Polymarket today?"
"Show me the order book for the 2024 election market."
"What is the current probability implied by the price of the 'Yes' token?"
"Get detailed information about the 'will-trump-win-2024' market."
"What's my current pUSD balance and allowance?"
"Show me all my open orders across all markets."
"Place a buy order for 100 shares at 0.65 price."
"Cancel all my open orders on this market."
approve_allowancesGrant the pUSD and Conditional Token approvals required for Polymarket V2 trading and position management. Automatically approves only contracts that do not already have permission. Approvals are revocable at any time in your wallet.
Parameter | Type | Required | Description |
| integer | false | How many confirmations to wait before returning (0 = return immediately after broadcasting). Default: 0 |
cancel_all_ordersCancel all open orders for the authenticated account.
No parameters
cancel_orderCancel a specific order by its ID.
Parameter | Type | Required | Description |
| string | true | The unique identifier of the order to cancel |
get_all_tagsGet a list of all available tags for categorizing markets.
No parameters
get_balance_allowanceGet balance and allowance information for the authenticated account. Can check COLLATERAL or CONDITIONAL tokens.
Parameter | Type | Required | Description |
| string | true | Asset type to check balance for: COLLATERAL or CONDITIONAL |
| string | false | Optional token ID for conditional token balance |
get_event_by_slugGet detailed information about a specific event by its slug identifier. Events group multiple related markets.
Parameter | Type | Required | Description |
| string | true | The event slug identifier |
get_market_by_slugGet detailed information about a specific market by its slug identifier. The slug can be extracted from the Polymarket URL.
Parameter | Type | Required | Description |
| string | true | The market slug identifier (e.g., 'will-trump-win-2024') |
get_markets_by_tagGet markets filtered by a specific tag ID. Useful for finding markets in specific categories.
Parameter | Type | Required | Default | Description |
| string | true | The tag ID to filter by | |
| number | false | 20 | Number of markets to return (default: 20) |
| boolean | false | false | Include closed markets (default: false) |
get_open_ordersGet all open orders for the authenticated account. Can optionally filter by market.
Parameter | Type | Required | Description |
| string | false | Optional market address to filter orders by |
get_orderGet details of a specific order by its ID.
Parameter | Type | Required | Description |
| string | true | The unique identifier of the order |
get_order_bookGet the current order book for a specific market token. Shows all active buy and sell orders.
Parameter | Type | Required | Description |
| string | true | The token ID for the market outcome |
get_positionsGet all positions for a wallet address with current values. Returns position details including size, current price, current value, and P&L. Uses the Polymarket Data API for accurate position valuation.
Parameter | Type | Required | Default | Description |
| string | false | Wallet address to fetch positions for. If not provided, uses POLYMARKET_FUNDER env var. | |
| number | false | 100 | Maximum number of positions to return (default: 100) |
get_trade_historyGet trade history for the authenticated account. Can optionally filter by market or maker address.
Parameter | Type | Required | Description |
| string | false | Optional market address to filter trades by |
| string | false | Optional maker address to filter trades by |
list_active_marketsList all currently active markets with pagination. Returns markets that are not yet closed.
Parameter | Type | Required | Default | Description |
| number | false | 20 | Number of markets to return (default: 20, max: 100) |
| number | false | 0 | Number of markets to skip for pagination (default: 0) |
place_market_orderPlace a market order that executes immediately at the current market price. For BUY orders, amount is the pUSD amount to spend. For SELL orders, amount is the number of shares to sell. Example: amount=5, side=BUY spends 5 pUSD. Minimum 1 pUSD for BUY orders.
Parameter | Type | Required | Description |
| string | true | The token ID of the market outcome to trade |
| number | true | BUY orders: pUSD amount to spend. SELL orders: Number of shares to sell. Minimum 1 pUSD for BUY orders. |
| string | true | The side of the order: BUY or SELL |
| string | false | Order type: FOK (Fill or Kill) or FAK (Fill and Kill). Default: FOK |
place_orderPlace a limit order on Polymarket at a specific price. Specify the number of shares (size) and price (0-1). For both BUY and SELL, you specify the number of shares you want to trade. Example: size=10, price=0.6 means buy/sell 10 shares at $0.60 per share (total: $6).
Parameter | Type | Required | Description |
| string | true | The token ID of the market outcome to trade |
| number | true | The limit price for the order (between 0 and 1). This is the probability/price per share. |
| number | true | Number of shares to trade. For both BUY and SELL orders, this is always the number of outcome tokens/shares. |
| string | true | The side of the order: BUY or SELL |
| string | false | Order type: GTC (Good Till Cancelled) or GTD (Good Till Date). Default: GTC |
redeem_positionsRedeem all winning outcome tokens from a resolved Polymarket market into pUSD. Provide the conditionId and set negRisk=true for negative-risk markets.
Parameter | Type | Required | Default | Description |
| string | true | The condition ID for the resolved market. This is typically a 32-byte hex string. | |
| boolean | false | false | Whether this is a negative-risk market. Selects the V2 NegRisk collateral adapter when true. Default: false |
search_marketsSearch for markets, events, and profiles using text search.
Parameter | Type | Required | Description |
| string | true | Search query text |
update_balance_allowanceUpdate balance and allowance for the authenticated account. Required before trading.
Parameter | Type | Required | Description |
| string | true | Asset type to update allowance for: COLLATERAL or CONDITIONAL |
| string | false | Optional token ID for conditional token |
pnpm run buildpnpm run watchpnpm run lint
pnpm run formatsrc/tools/: Individual tool definitions
src/services/: API client and business logic
src/index.ts: Server entry point
This project is an unofficial tool and is not directly affiliated with Polymarket. It interacts with financial and prediction market data. Users should exercise caution and verify all data independently. Trading in prediction markets involves risk.
Get a list of all available tags for categorizing markets.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It only states the basic function, lacking disclosure on read-only nature, authentication needs, rate limits, or output format.
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?
Description is a single concise sentence that front-loads the purpose, but could be slightly more informative without losing conciseness.
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 no parameters, no output schema, and no annotations, the description minimally covers the tool's purpose but lacks details on the return structure or behavior, which an agent may need for safe invocation.
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?
Input schema has no parameters, so schema description coverage is 100%. Baseline for zero parameters is 4; no additional context needed.
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 action (get a list), the resource (all available tags), and the purpose (for categorizing markets), distinguishing it from siblings that deal with events or 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?
The description implies usage when a list of tags is needed but does not provide explicit when-to-use or when-not-to-use guidance compared to alternatives like 'get_markets_by_tag'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed information about a specific event by its slug identifier. Events group multiple related markets.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | The event slug identifier |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It correctly implies a read operation but does not disclose any additional behavioral aspects such as authentication requirements or rate limits.
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 minimal (two sentences) and directly addresses the tool's purpose without any fluff. 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?
Given the simplicity of the tool (single parameter, no output schema), the description sufficiently covers the core functionality and relationship to events, though it could briefly mention what 'detailed information' entails.
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 a clear description of the 'slug' parameter. The tool description adds the word 'event' but does not significantly enhance understanding 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 clearly states that the tool retrieves detailed information about a specific event using a slug identifier, and adds context that events group related markets, distinguishing it from sibling tools like get_market_by_slug.
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 implicit context about events grouping markets, hinting at use cases, but lacks explicit guidance on when to use this tool versus alternatives like get_market_by_slug.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed information about a specific market by its slug identifier. The slug can be extracted from the Polymarket URL.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | The market slug identifier (e.g., 'will-trump-win-2024') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits beyond stating it 'gets detailed information'. It does not mention whether the operation is read-only, any authentication requirements, rate limits, or what 'detailed information' entails. This leaves significant ambiguity for an agent.
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 two sentences with no extraneous words. The purpose is stated upfront, and the additional clarification about the slug is concise. Every sentence serves a clear function.
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 tool with one parameter and no output schema, the description is adequate but not complete. It does not specify what fields or structure the 'detailed information' includes, which could be important for an agent to understand the return value without 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 schema covers 100% of parameters with a description of the slug. The tool description adds value by explaining that the slug can be extracted from the Polymarket URL, which supplements the schema and aids agents in constructing the correct input.
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 verb 'Get' and the resource 'detailed information about a specific market by its slug identifier'. It also explains how to obtain the slug from a Polymarket URL, making the purpose unambiguous. This distinguishes it from siblings like list_active_markets or search_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?
No guidance is provided on when to use this tool versus alternatives. It does not mention when not to use it, nor does it reference sibling tools like search_markets or get_event_by_slug. The only hint is that the slug comes from a URL, but no comparative context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get markets filtered by a specific tag ID. Useful for finding markets in specific categories.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Number of markets to return (default: 20) | |
| closed | No | Include closed markets (default: false) | |
| tag_id | Yes | The tag ID to filter by |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It only states filtering by tag ID, but does not explicitly confirm that the operation is read-only, mention any side effects, or describe behavior regarding closed markets (though the parameter default is provided in schema). The description adds minimal behavioral context.
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 extremely concise, consisting of two short sentences. The first sentence immediately states the core function, making it front-loaded and efficient with no superfluous 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?
For a simple filter tool with no output schema, the description covers the main purpose but lacks details on return format, ordering, or pagination beyond the limit parameter. Given sibling tools, more context could help differentiate; however, it is minimally adequate.
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 each parameter already has a description. The tool description does not add any meaning beyond the schema, merely restating the tag_id filtering. Therefore, a 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 states the tool gets markets filtered by a tag ID, which is a clear verb+resource. It also mentions usefulness for specific categories, but does not explicitly differentiate from sibling tools like list_active_markets or search_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?
The description implies usage for finding markets in categories, but provides no explicit guidance on when to use this versus alternatives (e.g., search_markets) or when not to use it. No exclusionary criteria are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the current order book for a specific market token. Shows all active buy and sell orders.
| Name | Required | Description | Default |
|---|---|---|---|
| token_id | Yes | The token ID for the market outcome |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description implies a read-only operation by stating it 'shows' orders, but it does not explicitly declare whether it is read-only, requires authentication, or has any rate limits. With no annotations provided, the description carries the full burden, and it provides minimal behavioral context beyond the basic action.
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 very concise with two sentences that convey the core function. It is well-structured and free of fluff, though it could potentially be expanded with a detail about the response or active order definition.
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 tool has only one parameter, no output schema, and no annotations, the description is minimally viable. It explains what the tool does but lacks details such as the return format or how to interpret the order book, which would be helpful 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?
The input schema covers 100% of parameters with a description for token_id, and the overall description repeats the parameter's purpose ('specific market token'). This adds no significant meaning beyond the schema, so 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 uses a specific verb ('Get') and resource ('order book for a specific market token'), and clearly states what it shows ('all active buy and sell orders'). It distinguishes itself from sibling tools, which are about tags, events, and markets, not order books.
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?
No guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites, context, or scenarios where another tool would be preferred. The description is purely functional.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all currently active markets with pagination. Returns markets that are not yet closed.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Number of markets to return (default: 20, max: 100) | |
| offset | No | Number of markets to skip for pagination (default: 0) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description must disclose behavior. It states the return condition (not yet closed) and pagination, but lacks information on ordering, rate limits, or result completeness. Adequate but not rich.
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?
Two sentences, front-loaded with key information (verb, resource, condition, pagination). No redundant or unnecessary 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?
For a simple paginated list tool with 2 parameters and no output schema, the description covers the purpose and return condition. It could mention sorting order or scope but is mostly complete.
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% with clear descriptions for limit and offset. The description adds no additional meaning beyond the schema for these parameters, so 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 the verb 'List', the resource 'active markets', and the condition 'not yet closed'. It distinguishes from siblings like search_markets by focusing on active status and pagination.
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 implies usage for listing currently active markets but does not provide explicit guidance on when to use this tool vs alternatives (e.g., search_markets, get_markets_by_tag). No when-not-to-use or alternative names given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for markets, events, and profiles using text search.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search query text |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description must cover behavior. It only states the action, omitting details like search algorithm, pagination, or rate limits.
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?
Single sentence with no redundancy. Could be considered too brief for a search tool, but still efficient.
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 tool has one parameter and no output schema, the description is too minimal. It doesn't explain return format or scope of search, lacking completeness for effective agent use.
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 already describes the single parameter sufficiently. The description adds no extra meaning, so baseline 3 applies due to high 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 it searches for markets, events, and profiles using text search. The verb 'Search' and specified resource types make the purpose distinct from sibling tools like get_market_by_slug.
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?
No explicit guidance on when to use versus alternatives like get_event_by_slug. The context implies a general search, but lacks when-not-to-use or performance considerations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.0.18get_all_tagsget_event_by_slugget_market_by_slugget_markets_by_tagget_order_booklist_active_marketssearch_marketsEach tool has a clearly distinct purpose: tags, events, markets, order book, listing, and search. No overlapping functionality.
All tools follow a consistent verb_noun pattern using snake_case (get_, list_, search_).
7 tools is well-scoped for a prediction market querying server, covering essential data access without being too few or too many.
Covers listing, searching, details, tags, and order book. Minor gap: no direct price or historical data, but adequate for common queries.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Calibrated world model for AI agents. 40 tools: world state, markets, trading. Kalshi + Polymarket.
Polymarket + Hyperliquid + macro for AI agents. 38 tools, signal backtest, SSE streaming. Free tier.
Live Polymarket data for agents: markets, insider-scored whale trades, leaderboards, wallet P&L
Financial data for AI agents: crypto data, Polymarket odds, weather/oil calibration, trust scoring.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/BrainDAO/mcp-polymarket'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
