Live prediction markets: Polymarket + Kalshi prices, odds, order books. Pay-per-call USDC, no key.
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.
Average 3.7/5 across 11 of 11 tools scored. Lowest: 2.5/5.
The paid data tools all share the predict_ prefix and search by keyword, which can blur boundaries—especially predict_markets vs predict_events, both returning Polymarket data. However, predict_orderbook, predict_trades, and predict_kalshi have distinct purposes, and the free server-management tools are clearly separate. Overall, some overlap exists but descriptions mostly clarify the intended use.
Most data tools follow a consistent predict_<resource> pattern, making it easy to guess functionality. The free tools break the pattern (install_snippets, list_endpoints, pricing_info, usage_stats, wallet_helper) and predict_360 is an outlier, but the overall convention is still predictable and readable.
At 11 tools, the server covers the core prediction-market data needs without bloat. Each tool addresses a distinct data need or server-management function, and the split between free and paid tools is well-balanced.
The server provides comprehensive Polymarket coverage (markets, events, order book, trades) plus Kalshi markets, which spans the main prediction-market data needs. Gaps include no direct single-market lookup by ID and no Kalshi order book/trades, but agents can likely work around these via keyword search.
install_snippetsAInspectReturn 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 | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description adequately reveals behavior: returns ready-to-paste snippets for multiple IDEs and notes it's free. No hidden side effects are expected for this read-only tool.
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, no wasted words. All essential information is 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?
Given no parameters and no output schema, the description covers the tool's purpose and output sufficiently. Minor room for improvement (e.g., format of snippets) but not necessary.
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, so baseline score of 4 applies. Description does not need to add parameter semantics.
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 configuration snippets for installing the MCP server in specific IDEs. It is distinct from sibling tools like list_endpoints or pricing_info.
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 snippets are needed but does not explicitly state when to use or avoid this tool versus siblings. No alternatives mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_endpointsAInspectList 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 | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. While the read-only nature is implied for a list operation, it does not explicitly state safety or lack of side effects. Mentions 'Free' but does not cover rate limits 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?
Two sentences, front-loaded with action and result. Every sentence adds value: first defines action, second gives usage hint. No wasted 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?
Describes return content (prices, live status) but lacks detail on format or potential filtering. Adequate for a simple list tool with no output schema, though could be more precise.
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 schema (100% coverage), so baseline of 4 applies. Description adds no parameter detail beyond schema, which is expected.
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 lists all paid endpoints with prices and live status. Uses specific verb 'list' and resource 'paid endpoints', distinguishing it from siblings like pricing_info which may focus on pricing details.
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 'Use this first to discover what tools are available' and 'Free — no wallet required', providing clear ordering and prerequisite guidance. Does not explicitly contrast with alternatives but offers strong usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
predict_360BInspectPremium 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 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It does reveal the cost per call ($0.005–$0.05 USDC on Base) and frames the tool as 'premium', which is crucial for an agent deciding whether to invoke it. However, it leaves unspecified whether the operation is read-only, what authentication or account requirements exist, and what happens on errors, leaving meaningful gaps.
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 succinct and front-loaded, immediately listing the bundle components (top market, live odds, order-book depth, recent trades) and following with cost information. It uses bullet-like brevity and avoids fluff. However, the visible truncation ('Trading & forecasting ag...') suggests incompleteness, slightly reducing polish.
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 multi-part output and single opaque parameter, the description is notably incomplete. It omits any description of the expected response structure, provides no meaning for 'arg', and does not situate itself relative to sibling tools despite the availability of such context. The cost disclosure is useful, but the core operational details required for correct use are absent.
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 no description, and schema coverage is 0%. The tool description adds zero explanation of what 'arg' should contain (e.g., a market ID, symbol, or query string). This is a critical deficiency: without any clue about the parameter, an agent cannot correctly form a call.
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 identifies predict_360 as a premium Polymarket bundle that aggregates top market data, live odds, order-book depth, and recent trades into a single call, setting it apart from more focused sibling tools like predict_orderbook and predict_trades. The 'in 1 call' phrasing reinforces the consolidation intent, though no explicit verb like 'get' or 'retrieve' appears.
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 this should be used when a complete market snapshot is needed in one request, as opposed to calling multiple single-purpose tools. However, it never explicitly contrasts it with alternatives like predict_markets or predict_orderbook, nor does it state when NOT to use it (e.g., if only odds are needed). The cost disclosure hints at premium usage but lacks broader guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
predict_eventsBInspectReturns 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 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavior itself. It adds value by mentioning cost ('$0.005–$0.05 USDC on Base per call') and listing return components. However, it omits side effects, error handling, payload size, and the truncated fragment 'Forecasting & trading agents d' is unclear.
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 first sentence is concise and front-loaded, but the second sentence is truncated mid-word ('Forecasting & trading agents d'), creating a structural flaw. This is not merely under-specification but broken syntax, which harms readability.
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?
The tool returns complex nested content (event groups, markets, outcomes, implied odds) with no output schema, so the description must provide structural context. It does not explain how these components relate, pagination, rate limits, or answer behavior for invalid keywords, and the truncated sentence leaves critical context missing.
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's single parameter 'arg' has zero description coverage, but the description compensates by specifying 'for any keyword,' which clarifies that arg is a search keyword. This is a direct semantic addition lacking in 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 opens with a clear, specific verb and resource: 'Returns Polymarket event groups + live markets + outcomes + implied odds for any keyword.' This distinguishes it from sibling tools like predict_markets and predict_kalshi, which likely focus on narrower scopes.
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 usage guidance or alternative comparisons are provided. The description does not explain when to prefer predict_events over sibling tools such as predict_markets or predict_orderbook, leaving the agent without decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
predict_kalshiBInspectSearches 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 |
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 the cost ('Cost: $0.005–$0.05 USDC on Base per call') and the fields returned, which is useful. However, it does not mention rate limits, read-only status, or potential side effects beyond the cost. The description is adequate but not rich in behavioral detail.
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 the main purpose, and the cost is presented clearly. However, it is truncated ('Kalshi is t...'), which disrupts the flow and leaves an incomplete sentence. This is a structural failure that makes the description feel unfinished and less professional.
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 single-parameter search tool, the description covers the purpose, returned fields, and cost. No output schema exists, so it doesn't need to explain return values in detail. However, the truncation and lack of explicit parameter mapping leave some context missing, such as what exactly can be searched (e.g., market titles vs. topics). Moderate 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 has one required parameter 'arg' with no description and 0% coverage. The description mentions 'by keyword', which strongly implies that 'arg' is the keyword, but it does not explicitly state this or provide any format constraints. It adds some meaning beyond the schema but does not fully compensate for the lack of schema 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 states 'Searches live Kalshi prediction markets by keyword' which clearly specifies the verb (searches), resource (live Kalshi prediction markets), and method (by keyword). It also lists the returned fields (title, YES probability, bid/ask, volume, close time), adding specificity. However, it does not explicitly differentiate from sibling tools like predict_markets or predict_events, though the keyword-based scope implies a distinction.
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 phrase 'by keyword' gives an implied usage scenario: use this tool when you have a keyword to search for prediction markets. No explicit when-not-to-use or alternative tool names are mentioned, but the guidance is at least implicit. The cost information also provides context for when the tool might be appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
predict_marketsAInspectSearches 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 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the return fields and the cost per call, which adds useful behavioral context. However, it does not explicitly state that the operation is read-only, nor does it mention any potential side effects, rate limits, or error behavior. This is minimal but not grossly inadequate.
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 concise sentences. The first sentence immediately states the purpose and the data returned; the second provides pricing. No filler or redundancy. It is well-structured and 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?
For a simple one-parameter search tool, the description covers the essential return fields and cost, which is important since there is no output schema. It does not mention result limits, failure modes, or whether the data is as-of-request or cached. These gaps are relatively minor given the tool's simplicity, so it is fairly 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?
The schema has only a parameter named 'arg' with zero description coverage. The tool description compensates by clarifying that arg is a keyword used for searching Polymarket markets. This is essential semantic context. It lacks format examples or edge-case handling, but it 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's function: 'Searches live Polymarket prediction markets by keyword' and enumerates the returned data (market question, YES/NO odds, volume, liquidity). This is a specific verb+resource+scope that distinguishes it from sibling tools like predict_kalshi (different exchange) or predict_orderbook (different data focus).
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 the many predict_* siblings. It does not mention alternatives, exclusions, or specific use cases beyond 'by keyword'. The usage scenario is only implied, not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
predict_orderbookCInspectReturns 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 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of disclosure. It does mention the cost per call and implies real-time data ('live'), but fails to disclose response format, rate limits, or whether it is strictly read-only. This leaves significant behavioral ambiguity.
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 ends mid-sentence ('use this fo'), making it structurally incomplete. The cost line appears as an abrupt appendage, reducing coherence and overall 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?
The tool description is incomplete due to truncation, lacks parameter semantics, and provides only minimal usage context. With no output schema and no annotations, the description fails to cover essential information needed to invoke the tool effectively, even for a simple one-parameter 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?
The input schema has a single parameter 'arg' with no description, and schema description coverage is 0%. The description does not explain what value 'arg' should take or how to specify the market outcome token, leaving the agent without essential parameter guidance.
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 live bid/ask depth from Polymarket CLOB for any market outcome token,' which specifies the verb, resource, and scope. It distinguishes from sibling tools like predict_kalshi by naming Polymarket CLOB, though it doesn't explicitly contrast with other predict_* 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?
The phrase 'Trading & market-making agents use this fo...' implies a target audience and use case, but the sentence is truncated and no explicit alternatives or exclusions are given. The guidance is implied rather than directly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
predict_tradesAInspectReturns 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 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries full responsibility for behavioral disclosure. It does reveal the cost and output fields, but it fails to explain how 'top market' is chosen, how recent 'latest' is, or whether multiple fills are returned, leaving meaningful ambiguity.
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 and front-loaded with the core function and output fields. The second sentence appears truncated ('resear') and the cost line is included, which slightly reduces clarity but overall it is 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?
With no output schema or annotations, the description should compensate fully. It lists output fields and cost, but omits return structure, number of fills, pagination, and the definition of 'top market'. Sibling tools provide some contextual clue, but the description itself is not fully self-contained.
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% and the single parameter is only named 'arg'. The description adds essential meaning by identifying it as a keyword for matching a market, which is critical for correct invocation. It lacks formatting or matching details but is sufficient for a simple keyword.
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 fields (side, price, size, time), giving a specific verb and resource. It distinguishes itself from sibling tools like predict_orderbook and predict_markets by focusing on trade fills rather than book depth or market listings.
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 phrase 'Trading-signal & research' provides clear intended use cases, and the description implies usage for recent trade data. However, it does not explicitly mention when to avoid this tool or name alternatives, though sibling names provide some context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
pricing_infoAInspectReturn 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 | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavioral traits. It indicates the tool is read-only by stating it 'returns' pricing details and adds 'Free' to signal no cost. However, it could more explicitly confirm no side effects 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 two sentences long, starting with the main action and listing key outputs. Every word adds value; no redundancy. It is ideally sized for a simple info tool.
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 simplicity (no parameters, no output schema), the description covers the essential information an agent needs. It could be slightly more complete by hinting at the return format (e.g., JSON), but it is sufficient for most use 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?
The tool has zero parameters, so baseline is 4. The description does not need to add parameter meaning, and the schema coverage is 100% (no parameters to document). The description adds no param info, which 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 tool returns pricing details for the GoCreative Agent API, listing specific components (base price per call, premium endpoints, cache TTLs, supported payment networks). This distinguishes it from sibling tools like list_endpoints or usage_stats, which serve 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 implies usage for retrieving pricing information but does not explicitly state when to use this tool over alternatives or mention any prerequisites. The context (siblings) suggests it's the go-to for pricing, but no direct guidance is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
usage_statsAInspectReturn 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 | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It mentions the tool is free and returns stats, but does not state whether it has side effects, requires authentication, or has rate limits. For a stat retrieval tool, more clarity on read-only nature and output details would be beneficial.
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 with two short sentences, each serving a clear purpose: first defines the function, second provides usage context. There is no unnecessary verbiage.
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 covers the essential aspects: what the tool returns and a typical usage scenario. It could be slightly more detailed about response structure or limitations, but overall it is sufficient.
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, so schema description coverage is 100%. The description adds value by detailing what the output contains (top tools, success rate, recent activity), which helps the agent understand the semantic meaning 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 about MCP server usage, including specific items like top tools called, success rate, and recent activity. It effectively conveys the core function, though it does not explicitly contrast with sibling tools to further distinguish itself.
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 a practical use case ('verify your own integration is hitting the right tools') and notes it's free. However, it lacks explicit guidance on when not to use this tool or mention of alternatives among siblings, leaving room for ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
wallet_helperAInspectReturn 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 | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It correctly identifies the tool as returning instructions and being free, but lacks details on output format or any potential rate limits. However, given the tool's simplicity (zero parameters), the disclosure is sufficient.
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, front-loaded with the core action, and every word adds value. No redundancy or unnecessary detail.
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, simple instruction-returning tool, the description covers purpose and usage context adequately. It could mention the return format (e.g., text) but is otherwise 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?
The input schema has zero parameters and 100% coverage, so the description does not need to add parameter details. The baseline of 4 applies, and the description offers no extra param information, which is acceptable.
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 ('return') and the resource ('step-by-step instructions for setting up x402 USDC autopay'), and the context signals show no sibling overlaps, making its purpose distinct.
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 specifies when to use ('if a paid tool returned a 402 error or you're onboarding a new agent') and notes it is free, providing clear guidance against alternatives.
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.
No comments yet. Be the first to start the discussion!
