Code examples for the Polystrike API: live tweet counters for Polymarket's Elon Musk and Ted Cruz tweet-count markets.
The free tier needs no key (100 requests/hour). One call gets you three counters per active market — Polystrike's independent 60-second count, the official XTracker settlement count, and the count shown on Polymarket's UI — plus the deltas between them:
curl https://polystrike.xyz/api/v1/meta/elon{
"timestamp": 1783363631650,
"data": [
{
"event_id": 666466,
"event_title": "Elon Musk # tweets July 6 - July 8, 2026?",
"polymarket_xtracker_counter": 41,
"real_counter": 44,
"polymarket_ui_counter": 41,
"settlement_delta": 3,
"display_delta": 3,
"internal_delta": 0
}
]
}Example | What it does |
Poll both accounts, print counters + deltas (stdlib only) | |
Same in TypeScript / Node 18+ | |
Connect Claude Desktop to the hosted MCP server | |
Local MCP server over the public REST API (Node 20+) |
Related MCP server: x-search-plugin
mcp-server/server.js is a stdio MCP server that wraps the
public REST API — the same tools as the hosted server, runnable locally:
npm install && node mcp-server/server.jsFree-tier tools need no key. Set POLYSTRIKE_API_KEY to unlock the PRO tools
(trading signals, portfolio analysis).
GET /api/v1/meta/elon — Elon Musk markets (free)
GET /api/v1/meta/cruz — Ted Cruz markets (free)
GET /api/v1/meta/{account}/tweets — recent tweet stream (free: last 15)
Full reference: API docs · OpenAPI spec · MCP setup guide
The XTracker oracle is the settlement authority — Polymarket pays out on its number. Polystrike measures it faster (60s vs ~5min) but does not replace it.
Deleted tweets stay in Polystrike's count if captured before deletion; a
settlement_delta driven by a deletion is not a real edge.
These are measurement tools, not a promise of profit.
MIT licensed.
Analyze a Polymarket wallet's open positions across the active Elon tweet-count markets, with a model-based expected-value assessment per position. Elon markets only. Requires a PRO API key (POLYSTRIKE_API_KEY environment variable); fails with HTTP 402 without one. Read-only: it inspects publicly visible positions and returns analysis — it never places or modifies orders.
| Name | Required | Description | Default |
|---|---|---|---|
| wallet | Yes | Ethereum address of the Polymarket wallet to analyze, hex '0x...' format. | |
| bankroll | No | Optional bankroll in USD (1-1,000,000) for Kelly position-sizing suggestions; if omitted, sizing recommendations are not included. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose all behavioral traits. It does so by stating the tool is read-only, requires authentication, and its domain (Elon markets only). It also mentions the expected-value assessment, though it could still elaborate on what the analysis includes (e.g., whether it returns numerical values, comparisons, etc.).
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 with two sentences, no filler. It front-loads the primary purpose in the first sentence, ensuring the agent immediately understands the tool's role.
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 output schema and simple parameters (2), the description covers the essentials: purpose, prerequisites, read-only nature, and scope. It does not describe the output format, but the context of 'expected-value assessment per position' provides a general idea. Slight gap for full completeness.
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 already describes 100% of parameters, so the description's marginal value is modest. However, it adds context: 'bankroll' is explained as optional and used for Kelly sizing suggestions, which is not in the schema description. This adds meaningful semantics beyond the bare 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 verb 'analyze', the specific resource 'Polymarket wallet's open positions across active Elon tweet-count markets', and includes the scope 'Elon markets only'. This distinguishes it from sibling tools like get_predictions or get_trading_signals which have different purposes.
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 conditions for use: requires a PRO API key (POLYSTRIKE_API_KEY) and will fail with HTTP 402 without it. It also clarifies that it is read-only and never modifies orders, helping the agent decide when to use this tool versus others that may place trades.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check that the Polystrike API is up and responding; returns a status payload with a server timestamp. Free tier, no API key required. Use to verify connectivity before assuming other tools are failing for data reasons.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that it's free tier, no API key required, and returns a timestamp. Lacks details on possible rate limits or response structure, but covers key traits given no 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?
Two sentences, no unnecessary words, front-loaded with purpose and outcome.
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 health check tool, the description adequately explains purpose, usage context, and return value without gaps.
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?
No parameters exist in the schema, so the description appropriately needs no parameter details; baseline 4 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool checks API health and returns a status payload with timestamp, distinguishing it from sibling tools like get_predictions or get_market_metadata.
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 advises using this tool to verify connectivity before assuming other tools fail, providing clear when-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get metadata for Polystrike's tracked crypto prediction markets (market IDs and basic market info). Free tier, no API key required. The data array is empty when no crypto markets are currently tracked. For the main tweet-count markets use get_market_metadata.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses free tier, no API key, and that the data array is empty when no crypto markets are tracked. Good transparency, though could mention any limits or exactly what 'basic market info' includes.
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?
Three sentences, each adding value: purpose, free access, empty data behavior and sibling reference. No wasted words, information front-loaded.
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?
Tool is simple (no params, no output schema). Description covers purpose, usage context, and empty result behavior adequately. Could be more detailed about output fields, but adequate for the tool's complexity.
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?
No parameters in input schema, so baseline of 4 applies. Description adds context about what the tool returns but doesn't need to explain params.
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 retrieves metadata for crypto prediction markets, specifies what is returned (market IDs and basic info), and distinguishes itself from sibling get_market_metadata. Verb+resource+scope are all explicit.
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 guidance: 'Free tier, no API key required' and directs users to an alternative tool for main tweet-count markets (get_market_metadata). Clear when to use and when not.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get live metadata for the active Polymarket tweet-count markets of one tracked account. Returns one entry per active market with its event_id, title, and three live counters: real_counter (Polystrike's independent 60-second count), polymarket_xtracker_counter (the official XTracker count that settlement pays out on), and polymarket_ui_counter (the number shown in Polymarket's UI), plus the deltas between them (deltas are null while an event is warming up). Free tier, no API key needed. Call this first to discover active markets and event IDs before using get_predictions or get_trading_signals. Read-only; makes a single HTTPS request to polystrike.xyz.
| Name | Required | Description | Default |
|---|---|---|---|
| account | Yes | Tracked account: 'elon' (Elon Musk on X), 'cruz' (Ted Cruz on X), or 'trump' (Donald Trump on Truth Social). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully discloses behavioral traits: states it is read-only, makes a single HTTPS request to polystrike.xyz, requires no API key, and explains the behavior of deltas during warm-up (null until ready). It also details the sources of the three counters.
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 concise (single paragraph) and front-loaded with the main verb and resource. Every sentence adds value, covering purpose, usage, return fields, and special conditions without redundant phrasing.
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 output schema, the description fully explains the return structure (event_id, title, three counters, deltas) and contextualizes deltas as null during warm-up. It also specifies the data source (Polystrike) and the tool's role in the workflow. All relevant aspects are covered.
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 description for the 'account' parameter, including an enum. The description adds context about the tracked accounts (e.g., Elon Musk on X) and explains the return fields, which adds value for understanding output but not for parameter semantics beyond what the schema provides.
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?
Description clearly states it gets live metadata for Polymarket tweet-count markets of a tracked account, listing specific return fields (event_id, title, three counters, deltas). It distinguishes from sibling tools by recommending this as the first call to discover markets before using get_predictions or get_trading_signals.
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 says to call this first to discover active markets and event IDs, mentions free tier and no API key needed, and notes that deltas are null during warm-up. However, it does not explicitly state when not to use it or exclude alternatives beyond the recommendation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get Monte Carlo forecast data for the active tweet-count markets of a tracked account. The free tier (no key) returns a limited view; a PRO key (POLYSTRIKE_API_KEY environment variable) adds forecast percentiles (p5/p50/p95), per-bucket model probabilities, and posting velocity/sleep-schedule fields. Use this for market analysis; for concrete buy/sell recommendations use get_trading_signals instead. Read-only.
| Name | Required | Description | Default |
|---|---|---|---|
| account | Yes | Tracked account: 'elon' (Elon Musk on X), 'cruz' (Ted Cruz on X), or 'trump' (Donald Trump on Truth Social). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully convey behavioral traits. It states 'Read-only' at the end, clearly indicating the tool does not modify data. It also reveals that the free tier returns a limited view while a PRO key unlocks additional fields. This is good coverage, though it lacks explicit statements about authorization 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 three sentences long with no wasted words. The main purpose is front-loaded, and every sentence adds value: first sentence defines the core action, second sentence details tier behavior, third sentence provides usage guidance and read-only status.
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 (fully described), no output schema, and no annotations, the description covers all necessary context: what it does, differences between free and PRO access, and when to use an alternative. It is complete enough for an agent to decide whether to invoke this 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% with a description for the only parameter 'account'. The tool description reiterates the enum values and their meanings ('elon' = Elon Musk on X, etc.), but this largely duplicates the schema. No additional semantic value is provided beyond what the schema already offers, so 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?
Clearly states the tool retrieves 'Monte Carlo forecast data for the active tweet-count markets of a tracked account.' The verb 'get' and specific resource 'Monte Carlo forecast data' make the purpose unmistakable. It also distinguishes itself from the sibling 'get_trading_signals' by contrasting market analysis vs. buy/sell recommendations.
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 says to use this tool 'for market analysis' and for 'concrete buy/sell recommendations use get_trading_signals instead.' It also mentions tier differences (free vs PRO key), giving clear context for when to expect limited vs. full data.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get concrete rebalancing actions (ADD_MORE or TRIM, with USD amounts) for a Polymarket wallet's positions in the active Elon tweet-count markets, based on current model signals. Only positions whose suggested adjustment exceeds the threshold are returned. Elon markets only. Requires a PRO API key (POLYSTRIKE_API_KEY environment variable); fails with HTTP 402 without one. Read-only — returns recommendations, never executes trades.
| Name | Required | Description | Default |
|---|---|---|---|
| wallet | Yes | Ethereum address of the Polymarket wallet to analyze, hex '0x...' format. | |
| bankroll | Yes | Bankroll in USD for Kelly position sizing, 1-1,000,000. Required. | |
| threshold | No | Minimum adjustment size in USD for a recommendation to be included, 1-100 (default 5). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description discloses read-only behavior, authentication requirement (HTTP 402 on failure), and filtering condition. Provides enough behavioral context for safe invocation, though rate limits or idempotency are not mentioned.
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?
Four sentences, each concise: purpose, filtering, scope, and auth/behavior. Front-loaded with key action and resource. No redundant or unclear phrasing.
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 3 parameters and no output schema, description explains return type (actions with type and USD amounts), filtering logic, required auth, and read-only nature. Adequately covers all aspects for an agent to use 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?
Schema coverage is 100%, but description adds value by explaining bankroll is 'for Kelly position sizing' and threshold as 'minimum adjustment size in USD', providing context beyond the schema descriptions.
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?
Description specifies verb 'Get', resource 'rebalancing actions', context 'Polymarket wallet positions in active Elon tweet-count markets', and output type 'ADD_MORE or TRIM with USD amounts'. Distinguishes from siblings like get_trading_signals and analyze_portfolio by focusing on concrete actionable rebalancing.
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?
Clearly states when to use: for rebalancing in Elon markets, with threshold filtering. Mentions requirement for PRO API key. However, does not explicitly compare to alternatives like get_trading_signals for when one might prefer signals over actions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the most recent captured posts for a tracked account, newest first, with per-post metadata including whether each post counts toward the active tweet-count markets. Use it to understand posting pace and to verify what is being counted. The free tier returns the latest 15 posts and ignores pagination; with a PRO key (POLYSTRIKE_API_KEY environment variable) limit can go up to 100 and offset paginates. Read-only.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Number of posts to return, 1-100 (default 15). Values above 15 require a PRO key; the free tier caps at the latest 15. | |
| offset | No | Pagination offset, 0 or greater (default 0). PRO only; ignored on the free tier. | |
| account | Yes | Tracked account: 'elon' (Elon Musk on X), 'cruz' (Ted Cruz on X), or 'trump' (Donald Trump on Truth Social). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explicitly states 'Read-only' and details free-tier limits (15 posts, pagination ignored) and PRO key requirements for higher limits and pagination. It also mentions metadata content. No contradictions with missing 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 a single paragraph, starts with the main action, and every sentence adds value. No fluff, appropriate length for the complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, the description explains output includes per-post metadata and its relevance to tweet-count markets. Tier differences are covered. Parameter descriptions in schema complement the description well. Complete for a read-only list 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%, but the description adds significant context: explains default limit 15, free-tier cap, PRO key for values >15, offset pagination, and clarifies account enum values. This goes well 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 the tool retrieves the most recent captured posts for a tracked account, newest first, with per-post metadata. It distinguishes from siblings which focus on predictions, markets, and other analytical tasks.
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 usage intent: 'understand posting pace and verify what is being counted.' It also explains tier differences (free vs. PRO) but does not explicitly mention when not to use the tool or name alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get actionable BUY/SELL signals with Kelly-criterion bet sizing for a tracked account's tweet-count markets. Each signal carries its strategy context, e.g. BUY TWO_BUCKET (predicted bucket plus lower adjacent) or BUY SINGLE_BUCKET (high-conviction single bet), and a suggested stake for the given bankroll. Requires a PRO API key in the POLYSTRIKE_API_KEY environment variable; without one the call fails with HTTP 402 and an explanatory message. Informational only — this tool never places orders and is not financial advice.
| Name | Required | Description | Default |
|---|---|---|---|
| account | Yes | Tracked account: 'elon' (Elon Musk on X), 'cruz' (Ted Cruz on X), or 'trump' (Donald Trump on Truth Social). | |
| bankroll | No | Bankroll in USD used for Kelly bet sizing, 1-1,000,000. If omitted, the API's default bankroll setting is used. | |
| only_with_signals | No | If true, return only events that currently have a BUY or SELL signal (default false). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description bears full responsibility for behavioral disclosure. It explicitly states the tool never places orders and requires a PRO API key, revealing its read-only nature and authentication needs. This goes beyond basic descriptions but could mention rate limits or other operational details.
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, using only a few sentences to convey purpose, behavior, prerequisites, and examples. Every sentence adds value without redundancy or fluff. The structure is well-organized, with examples embedded naturally.
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's moderate complexity (3 parameters, no output schema), the description provides sufficient context: it explains strategy contexts (TWO_BUCKET, SINGLE_BUCKET) and stake suggestion. It does not describe the exact output format, but the examples imply a list of signals. Overall, it is nearly complete for an informational tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description does not add further meaning beyond what the schema provides for the parameters; the schema already describes the account enum, bankroll range, and only_with_signals boolean. Thus the parameter semantics are adequately covered by 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 the tool retrieves actionable BUY/SELL signals with Kelly-criterion bet sizing for tweet-count markets. It provides concrete examples of strategy contexts (TWO_BUCKET, SINGLE_BUCKET) and explicitly distinguishes it from order-placing tools by stating it never places orders, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description specifies a critical prerequisite (PRO API key) and the failure mode (HTTP 402) if missing. It also clarifies the tool is informational only and not financial advice. While it does not explicitly compare with sibling tools like get_predictions or analyze_portfolio, the unique focus on actionable signals with bet sizing provides implicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool targets a distinct aspect: predictions, metadata, tweets, signals, crypto metadata, portfolio analysis, rebalancing, and health. No two tools have overlapping purposes.
All tools use snake_case with verb_noun pattern (mostly 'get_'), but 'check_health' uses a different verb. Still highly consistent and predictable.
8 tools is well-scoped for a specialized prediction market API, covering all necessary operations without bloat.
Covers all key operations: discovery, forecasting, signals, portfolio analysis, rebalancing, and health. Intentionally read-only, so no gaps for its stated purpose.
X/Twitter reads, search, monitors and posting. Pay-per-call in USDC — no signup, no API keys.
Read-only MCP server for live Polymarket, Kalshi, Limitless odds; Manifold sentiment.
Twitter/X read-only MCP server — 12 tools: search, users, tweets, followers, timelines, trends.
FastMCP server for posting formatted content to X (Twitter) — Tollbooth-monetized, DPYC-native
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/dizpers/polystrike-examples'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
