Predict — Prediction Market Data for AI Agents
Server Details
Live prediction markets: Polymarket + Kalshi prices, odds, order books. Pay-per-call USDC, no key.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
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.
Tool Definition Quality
Average 3.6/5 across 11 of 11 tools scored. Lowest: 2.3/5.
Each tool has a clearly distinct purpose. The predict_* tools are differentiated by suffix (360, events, kalshi, markets, orderbook, trades), and the auxiliary tools (install_snippets, list_endpoints, etc.) serve separate functions. No overlap or ambiguity.
All tools use snake_case with a consistent verb_noun pattern. The predict_ prefix groups related market tools, and other tools follow similar conventions (install_snippets, list_endpoints, pricing_info, usage_stats, wallet_helper). Minor variation like predict_360 is fine.
11 tools is well-scoped for a prediction market data server. It covers discovery, installation, wallet setup, and multiple data endpoints for two platforms. Neither too few nor too many; each tool earns its place.
The tool set covers the full lifecycle for its domain: installation snippets, endpoint discovery, pricing and usage info, wallet setup, and multiple data queries for Polymarket and Kalshi. No obvious gaps for a read-only market data API.
Available Tools
11 toolsinstall_snippetsAInspect
Return ready-to-paste configuration snippets for installing this MCP server in Claude Code, Cursor, Cline, Continue.dev, Windsurf, and Zed. Free.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses the tool returns snippets (read-only information) and mentions it is free. For a parameterless tool with no side effects, this is sufficient transparency.
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 that is front-loaded with the verb and key noun. Every word earns its place, though 'Free' is slightly redundant but not harmful. No wasted content.
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 parameterless tool with no output schema, the description fully covers what the agent needs to know: the tool provides installation snippets for listed platforms. No additional context is required.
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?
Tool has zero parameters, so schema coverage is 100%. The description adds no parameter information, which is acceptable since none are needed. Baseline 4 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?
Description clearly states the tool returns ready-to-paste configuration snippets for installing the MCP server, listing specific target platforms. It distinguishes well from sibling tools that focus on predictions, pricing, and other server operations.
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 implicitly indicates when to use: when the agent needs to provide installation configuration for Claude Code, Cursor, Cline, etc. No explicit exclusions or alternatives are provided, but the purpose is narrow and clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_endpointsAInspect
List all paid endpoints exposed by this MCP server with their prices and live status. Free — no wallet required. Use this first to discover what tools are available.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description adds value by stating 'Free — no wallet required,' indicating no cost or authentication. Describes a read-only listing with no destructive effects.
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 efficient sentences: first states purpose, second adds usage advice and key trait. No fluff, 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?
Fully adequate for a zero-parameter tool. Tells what, when, and a key behavioral trait. No output schema needed for this simple list.
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 zero parameters, so baseline is 4. Description does not need to add parameter info; it focuses on tool behavior.
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 verb 'list' and the resource 'paid endpoints' with specifics (prices and live status). Differentiates from sibling tools by focusing on endpoint discovery.
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 'Use this first to discover what tools are available,' providing clear when-to-use guidance. Lacks explicit when-not or alternatives, but sufficient given context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
predict_360CInspect
Premium Polymarket bundle: top market + live odds + order-book depth + recent trades in 1 call. Trading & forecasting ag
Cost: $0.005–$0.05 USDC on Base per call.
| Name | Required | Description | Default |
|---|---|---|---|
| arg | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description only mentions cost and bundling. Does not disclose what 'top market' means, how parameter works, or any failure modes.
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?
Very short but truncated (missing end of sentence). Wastes space with 'Premium' but cost info is useful. Incomplete structure harms clarity.
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?
Complex bundled tool with no output schema, vague parameter, and missing behavioral details. Description fails to adequately inform agent usage.
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?
Single parameter 'arg' has no description in schema or description text; 0% schema coverage. Agent has no guidance on what to pass.
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 is a bundle of Polymarket data (top market, odds, order book, trades) in one call, distinguishing it from more specific sibling tools. However, 'top market' is vague and description is truncated.
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?
Implies use when comprehensive data is needed ('in 1 call'), but no explicit when-to-use, when-not-to-use, or mention of alternatives among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
predict_eventsCInspect
Returns Polymarket event groups + live markets + outcomes + implied odds for any keyword. Forecasting & trading agents d
Cost: $0.005–$0.05 USDC on Base per call.
| Name | Required | Description | Default |
|---|---|---|---|
| arg | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description does not disclose behavioral traits beyond cost (monetary fee). No mention of read-only nature, auth, or rate limits. Cost is a positive but insufficient.
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 short but appears cut off with a trailing 'd'. It is not optimally front-loaded and could be more structured. Acceptable for 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?
No output schema and limited parameter description. The tool returns complex data (event groups, markets, outcomes, odds) but the description names only components without details on structure or pagination. Incomplete for a data-heavy 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 0%. The description implies 'arg' is a keyword but provides no details on format, examples, or constraints. Minimal value added over 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 it returns Polymarket event groups, live markets, outcomes, and implied odds for a keyword. The verb 'returns' and resource specification are specific, but it does not differentiate from sibling tools like 'predict_markets' which may have similar functionality.
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 this tool versus alternatives. Mentions 'for any keyword' but lacks context on when not to use or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
predict_kalshiCInspect
Searches live Kalshi prediction markets by keyword — title, YES probability, bid/ask, volume and close time. Kalshi is t
Cost: $0.005–$0.05 USDC on Base per call.
| Name | Required | Description | Default |
|---|---|---|---|
| arg | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions cost per call ($0.005–$0.05 USDC) but does not disclose other important behaviors such as rate limits, authentication requirements, or what happens when no results are found.
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 short but appears truncated ('Kalshi is t...'), making it incomplete. While the first sentence is concise, the truncation undermines clarity and completeness.
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 or annotations, the description should fully explain both input and output. It partially describes output fields but omits input format details, and the truncation leaves it incomplete.
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 has one required parameter 'arg' with no description, and schema description coverage is 0%. The description does not clarify what 'arg' should contain or how it should be formatted (e.g., a keyword or exact title), failing to compensate for the schema gap.
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 searches live Kalshi prediction markets by keyword and lists the returned fields (title, YES probability, bid/ask, volume, close time). This distinguishes it from sibling tools like predict_360, predict_events, and predict_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 does not provide any guidance on when to use this tool versus alternatives. There is no mention of optimal scenarios or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
predict_marketsAInspect
Searches live Polymarket prediction markets by keyword — returns market question, current YES/NO odds, volume, liquidity
Cost: $0.005–$0.05 USDC on Base per call.
| Name | Required | Description | Default |
|---|---|---|---|
| arg | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description adds cost information ($0.005–$0.05 USDC per call) which is helpful. However, it lacks details on rate limits, authentication, data freshness, or any side effects. For a search tool, this is moderately informative but incomplete.
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. Includes crucial cost information upfront. Very 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?
Description lists the key returned fields (question, odds, volume, liquidity) and cost. For a simple keyword search tool without an output schema, this is reasonably complete. Could mention maximum results or pagination, but not essential for basic understanding.
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 has one required parameter 'arg' with 0% description coverage. The description states 'by keyword', which clarifies that 'arg' is the search keyword. This adds meaningful semantic context beyond the bare schema name.
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 specifies the tool searches live Polymarket prediction markets by keyword and lists the returned fields (market question, odds, volume, liquidity). It implicitly distinguishes from sibling tools like predict_kalshi (for Kalshi) and predict_events (likely broader).
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 states search by keyword and mentions cost but does not provide explicit when-to-use or when-not-to-use guidance relative to sibling tools. No prerequisites or alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
predict_orderbookBInspect
Returns live bid/ask depth from Polymarket CLOB for any market outcome token. Trading & market-making agents use this fo
Cost: $0.005–$0.05 USDC on Base per call.
| Name | Required | Description | Default |
|---|---|---|---|
| arg | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses live data and cost ($0.005-$0.05 USDC), but does not mention rate limits, error handling, read-only nature, or other behavioral traits.
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 short and front-loaded with purpose and cost, but appears truncated (ends mid-sentence), losing potential value. It could be more structured.
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 single parameter with no schema description, no output schema, and no annotations, the description is incomplete. It fails to explain the input format, return structure, or edge cases.
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 0% with a single parameter 'arg' of type string. The description does not explain what 'arg' is, only implying it relates to a market outcome token. This is insufficient for an agent to correctly invoke the tool.
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 explicitly states it returns live bid/ask depth from Polymarket CLOB for any market outcome token, which is a specific verb+resource. This clearly differentiates from sibling tools like predict_markets or predict_trades.
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?
It mentions 'Trading & market-making agents use this' but lacks explicit guidance on when to use this tool versus alternatives, no when-not or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
predict_tradesCInspect
Returns latest Polymarket fills (side, price, size, time) for the top market matching a keyword. Trading-signal & resear
Cost: $0.005–$0.05 USDC on Base per call.
| Name | Required | Description | Default |
|---|---|---|---|
| arg | Yes |
Tool Definition Quality
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 like data freshness, caching, idempotency, authentication needs, or rate limits. The cost is mentioned but not behavioral 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 short and front-loaded with key information, but it appears truncated (cuts off mid-word), which reduces readability and completeness. A complete sentence would improve structure.
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 limited annotations, the description explains the return fields and cost, but lacks details on how results are ordered, pagination, error handling, or the exact meaning of 'top market'. The truncation leaves a 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?
The single parameter 'arg' has 0% schema description coverage. The description adds meaning by indicating it is a keyword for matching a market, but does not specify expected format, examples, or validation rules.
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 returns latest Polymarket fills with specific fields (side, price, size, time) for the top market matching a keyword. The verb 'returns' and resource 'fills' are specific, though it does not explicitly differentiate from sibling tools like predict_orderbook.
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 on when to use this tool versus alternatives such as predict_markets or predict_orderbook. The description lacks context on appropriate use cases or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
pricing_infoAInspect
Return pricing details for the GoCreative Agent API — base price per call, premium endpoints, cache TTLs, and supported payment networks. Free.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions that the tool is 'Free', indicating no cost, but does not disclose whether it is read-only, has rate limits, or requires authentication. The return content is listed, which adds some transparency.
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 sentence that conveys all essential information without redundancy. It is front-loaded with the verb 'Return' and covers key aspects efficiently.
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 no parameters and no output schema, the description reasonably covers the return content. However, it could mention that it requires no authentication or that pricing is static, but overall it is 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?
The input schema has no parameters (100% coverage with 0 params), so the baseline is 4. The description adds value by detailing what the tool returns, compensating for the lack of parameter documentation.
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 returns pricing details for the GoCreative Agent API, including specific items like base price per call, premium endpoints, cache TTLs, and supported payment networks. This distinguishes it from sibling tools that focus on predictions, installation, or usage statistics.
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 does not explicitly state when to use this tool versus alternatives like usage_stats or wallet_helper. It is implied that it provides pricing information, but no direct guidance on context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
usage_statsAInspect
Return summary stats of how this MCP server has been used (top tools called, success rate, recent activity). Free. Use to verify your own integration is hitting the right tools.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility. It states it returns stats and is free, but lacks details on authentication, rate limits, data freshness, or potential side effects. 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 purpose, no wasted words. Efficiently conveys what it does and why to use it.
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 parameterless tool with no output schema, the description is sufficiently complete. It explains the output (summary stats), a use case (verify integration), and is clear about being free. Sibling tools are unrelated, so no confusion.
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?
There are no parameters, so baseline is 4. The description adds value by explaining what the stats contain (top tools, success rate, recent activity), which is helpful beyond the empty 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 returns summary stats of MCP server usage, including specific items like top tools, success rate, and recent activity. It distinguishes itself from sibling tools (predictions, wallet) by focusing on server introspection.
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 mentions a specific use case: 'verify your own integration is hitting the right tools.' It's free to use. However, it doesn't explicitly state when not to use or provide alternatives, though the context of sibling tools makes it clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
wallet_helperAInspect
Return step-by-step instructions for setting up x402 USDC autopay for this MCP server. Use this if a paid tool returned a 402 error or you're onboarding a new agent that needs to pay for API calls. Free.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the tool returns instructions (not executing actions) and is free. It adds context about the tool's read-only nature and purpose, though could mention no side effects.
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 efficient sentences with no waste. First sentence states the verb and resource, second provides usage context. Information is front-loaded and every sentence earns its place.
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 tool with no output schema, the description covers purpose, usage, and a behavioral note ('Free'). It could specify the output format, but overall is sufficiently 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?
No parameters exist in the schema, so the description does not need to add parameter details. It adds value by explaining the output will be step-by-step instructions.
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 returns step-by-step instructions for setting up x402 USDC autopay, specifying the resource and action. It distinguishes itself from sibling tools which are prediction and pricing tools.
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 states when to use: after a 402 error or when onboarding a new agent needing payment for API calls. This provides clear context and exclusions relative to other tools.
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.
Discussions
No comments yet. Be the first to start the discussion!