Polymarket MCP Server

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.0.15
Disambiguation3/5
The tool set has clear thematic groupings (e.g., market data, user data, real-time subscriptions), but within groups there is significant overlap that could confuse agents. For example, tools like get_current_price, get_midpoint, get_spread, and get_liquidity all retrieve similar CLOB-based metrics, and multiple tools (get_market_by_id, get_market_by_slug, get_market_details) fetch market details with minor variations. Descriptions help differentiate, but the boundaries are fuzzy.
Naming Consistency4/5
Most tools follow a consistent verb_noun pattern (e.g., get_market_by_id, list_active_markets, subscribe_market_prices), with a few deviations like analyze_market_opportunity and filter_markets_by_category. The naming is largely predictable and readable, though not perfectly uniform across all 59 tools.
Tool Count2/5
With 59 tools, the server is overloaded for a prediction market domain, making it cumbersome for agents to navigate. Many tools are highly specialized (e.g., separate tools for batch prices, spreads, order books) that could be consolidated. This excessive count suggests poor scoping and will likely overwhelm users.
Completeness5/5
The tool surface is remarkably complete for the Polymarket domain, covering market discovery, detailed analytics, user data, real-time subscriptions, and auxiliary functions like bridging and health checks. There are no obvious gaps; agents can perform end-to-end workflows from browsing markets to trading and monitoring.
Average 3.4/5 across 59 of 59 tools scored.
See the Tool Scores section below for per-tool breakdowns.
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions using 'first clobTokenIds entry when available', hinting at data selection behavior, but lacks details on permissions, rate limits, response format, or error handling. This is inadequate for a tool that performs analysis without output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences, front-loading the core purpose and including a practical example. However, the second sentence about 'first clobTokenIds entry' is somewhat cryptic and could be better integrated or explained.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and a single parameter with high schema coverage, the description is incomplete. It fails to explain what the analysis returns, how results are structured, or any behavioral constraints, making it insufficient for effective tool use in this context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents the 'slug' parameter. The description adds minimal value by providing an example slug ('will-biden-win-2024'), which clarifies format but doesn't explain semantics beyond what the schema states. Baseline 3 is appropriate given high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool performs 'heuristic market analysis' using specific metrics (volume, liquidity, spread, time-to-close), which is a specific verb+resource combination. However, it doesn't explicitly differentiate from sibling tools like 'compare_markets' or 'get_market_details', which might offer similar analysis capabilities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides minimal guidance, only mentioning an example slug ('will-biden-win-2024') without explaining when to use this tool versus alternatives like 'compare_markets' or 'get_market_details'. There's no context on prerequisites, timing, or exclusions, leaving usage unclear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions the tool is 'public' (implying no authentication needed) and hints at data retrieval, but fails to disclose critical behaviors: rate limits, data format (e.g., time series structure), pagination, or error handling. For a tool with no annotation coverage, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and front-loaded, with two sentences that directly address purpose and parameter usage. However, the example could be integrated more smoothly, and some redundancy exists (e.g., 'Use limit' repeats schema info), slightly reducing efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description is incomplete. It lacks details on return values (e.g., time series format, data points), error cases, or behavioral constraints. For a data retrieval tool in a complex sibling set, this leaves the agent under-informed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the 'limit' parameter fully documented in the schema. The description adds marginal value by providing an example ('limit=30'), which clarifies usage but doesn't expand beyond the schema's semantics. Baseline 3 is appropriate as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get builder daily volume timeseries (public).' It specifies the verb ('Get'), resource ('builder daily volume timeseries'), and scope ('public'). However, it doesn't explicitly differentiate from sibling tools like 'get_live_volume' or 'get_market_volume', which might have overlapping functionality, preventing a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides minimal usage guidance: 'Use limit for number of points.' It lacks explicit when-to-use instructions, alternatives (e.g., vs. 'get_live_volume'), prerequisites, or exclusions. This leaves the agent with insufficient context for optimal tool selection among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions the tool 'returns active markets sorted by volume' but lacks critical behavioral details: whether this is a read-only operation, if it has rate limits, authentication requirements, pagination behavior, or what 'active markets' means operationally. The description is insufficient for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured in two sentences: one stating the purpose and return behavior, and one providing a concrete example. Every sentence adds value without redundancy, making it appropriately concise and front-loaded with essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (a ranking tool with volume-based sorting), no annotations, and no output schema, the description is incomplete. It doesn't explain the return format (e.g., list structure, fields included), error conditions, or how ties in volume are handled. For a tool that likely returns structured market data, more context is needed to use it effectively without trial and error.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents both parameters (timeframe with enum values and default, limit with constraints and default). The description adds minimal value beyond the schema—it provides an example ('timeframe=24h, limit=10') that reinforces defaults but doesn't explain parameter semantics like what 'trading volume' measures or how 'active markets' are defined. Baseline 3 is appropriate when schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get markets with highest trading volume for timeframe. Returns active markets sorted by volume.' It specifies the verb ('get'), resource ('markets'), and key criteria ('highest trading volume', 'active markets sorted by volume'). However, it doesn't explicitly differentiate from siblings like 'list_markets' or 'get_market_volume', which slightly reduces clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With many sibling tools like 'list_markets', 'get_market_volume', 'get_featured_markets', and 'filter_markets_by_category', there's no indication of when this specific volume-based ranking tool is preferred. The example mentions parameters but doesn't address tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions that 'each series can include a large events array' which provides some behavioral context about potential response size, but doesn't address rate limits, authentication requirements, error conditions, or what the response structure looks like beyond the example parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately concise with two sentences. The first states the purpose, the second provides an example and clarifies the limit parameter scope. No wasted words, though it could be slightly more front-loaded with key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list operation with 2 well-documented parameters and no output schema, the description is minimally adequate. However, with no annotations and multiple similar sibling tools, it should provide more context about what 'series' are and when to use this specific listing tool versus others in the API.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both parameters (limit, offset) well-documented in the schema. The description adds minimal value beyond the schema by providing an example (limit=1, offset=0) and noting that 'limit applies to series count', but doesn't explain parameter interactions or provide additional semantic context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List series') and source ('from the Gamma API'), providing a specific verb+resource combination. However, it doesn't differentiate this tool from sibling tools like 'list_events', 'list_markets', or 'list_comments' that also list resources from the same API.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With multiple sibling listing tools (list_series, list_events, list_markets, list_comments), there's no indication of what distinguishes series from events or markets, or when an agent should choose one over another.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. While it mentions 'limit applies per type (events/markets/profiles)', it doesn't disclose important behavioral aspects: whether this is a read-only operation, authentication requirements, rate limits, pagination behavior, search algorithm details, or what happens when no results are found. The description provides minimal behavioral context for a search operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately concise with two sentences that both add value. The first sentence states the purpose, and the second provides a concrete example. There's no wasted text, though it could be slightly more structured by separating purpose from behavioral notes.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a search tool with no annotations and no output schema, the description is insufficient. It doesn't explain what the search returns (structure of results, what fields are included), how results are ranked, whether it's a fuzzy or exact match search, or error conditions. The example helps but doesn't compensate for missing behavioral and output context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already fully documents both parameters. The description adds the example 'query=trump, limit=3' which provides concrete usage, but doesn't add meaningful semantic context beyond what's in the schema descriptions. This meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches for 'markets, events, and profiles using text search', which is a specific verb+resource combination. However, it doesn't explicitly differentiate from sibling tools like 'list_markets', 'filter_markets_by_category', or 'get_markets_by_tag', which also retrieve market data through different mechanisms.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With many sibling tools that retrieve market/event data (list_markets, filter_markets_by_category, get_markets_by_tag, get_event_by_id, etc.), there's no indication of when text search is preferred over other filtering methods or when this tool should be avoided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses some behavioral traits: HTTP method (POST), endpoint (/books), return behavior for empty input (returns []), and example token ID format. However, it misses critical details like authentication needs, rate limits, error handling, or response structure, which are essential for a batch operation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded, starting with the core purpose. Each sentence adds value: method/endpoint, source guidance, empty-case behavior, and example. However, the example syntax is slightly informal and could be clearer, and some redundancy exists (e.g., 'via POST CLOB /books' could be streamlined).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description is incomplete for a batch tool. It covers basic purpose and parameter sources but lacks details on authentication, rate limits, error responses, and return format (e.g., structure of order books). For a tool with 1 parameter and no structured safety info, this leaves significant gaps for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the parameter 'token_ids' well-documented in the schema. The description adds minimal value beyond the schema: it mentions sources for token IDs and provides an example format ('token_ids=[clobTokenIds[0], clobTokenIds[1]]'), but doesn't explain semantics like what token IDs represent or constraints. Baseline 3 is appropriate given high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Batch order books via POST CLOB /books' specifies the verb ('batch'), resource ('order books'), and method. It distinguishes from sibling 'get_order_book' by indicating batch capability. However, it doesn't explicitly contrast with 'get_batch_prices' or 'get_batch_spreads', missing full sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides implied usage guidance by mentioning sources for token IDs ('Source: clobTokenIds from list_active_markets or get_market_details') and behavior when none found ('If none found, returns []'). However, it lacks explicit when-to-use vs. alternatives like 'get_order_book' for single markets or other batch tools, and no prerequisites are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions required parameters and an example, but fails to describe key behavioral traits such as whether this is a read-only operation, potential rate limits, error conditions, or what the quote output entails (e.g., estimated fees, time). This leaves significant gaps in understanding how the tool behaves beyond basic input requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded, starting with the core purpose. It uses two sentences efficiently to cover key points, though the example could be slightly more integrated. There's no wasted text, making it appropriately sized for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a bridge quote tool with 6 required parameters and no output schema, the description is incomplete. It lacks details on what the quote returns (e.g., estimated cost, time), error handling, or dependencies beyond a vague reference to 'get_supported_assets'. Without annotations or output schema, this leaves the agent with insufficient context to fully understand the tool's operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all six parameters thoroughly. The description adds minimal value by listing 'fromAmountBaseUnit and recipientAddress' as required and providing an example with 'fromChainId=137, toChainId=137', but this doesn't significantly enhance meaning beyond the schema. Baseline 3 is appropriate as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get a bridge quote') and the resource ('from /quote'), making the purpose understandable. It distinguishes from siblings by focusing on bridge quotes rather than market data or other operations, though it doesn't explicitly contrast with similar tools like 'get_bridge_transaction_status'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides some usage context by mentioning 'Source: token/chain from get_supported_assets', implying a prerequisite or data source. However, it lacks explicit guidance on when to use this tool versus alternatives like 'get_bridge_transaction_status' or other quote-related tools, leaving usage somewhat implied rather than clearly defined.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 data is 'public on-chain' (implying read-only access) and gives an example format, but lacks details on permissions, rate limits, pagination behavior (beyond schema hints), error handling, or what the return data looks like (no output schema).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately concise with two sentences: one stating the purpose and scope, and another providing usage hints with an example. It's front-loaded with key information, though the example could be more structured (e.g., clarifying it's just an illustration).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description is incomplete for a tool with 4 parameters and complex data retrieval. It lacks behavioral context (e.g., pagination details, data format, error cases) and doesn't compensate for the absence of structured metadata, leaving gaps for an AI agent to infer usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all four parameters thoroughly. The description adds minimal value by mentioning 'user address' and 'optional market conditionId' with an example format, but doesn't provide additional semantics beyond what's in the schema (e.g., format details for 'user' are already in schema). Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: retrieving a user's closed/settled positions using public on-chain data. It specifies the verb ('Get'), resource ('closed/settled positions'), and scope ('public on-chain data'), though it doesn't explicitly differentiate from sibling tools like 'get_positions' or 'get_positions_value'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides implied usage guidance by mentioning the required 'user address' and optional 'market conditionId', but it doesn't explicitly state when to use this tool versus alternatives (e.g., 'get_positions' for open positions). No exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 filtering and includes an example but doesn't disclose key behavioral traits such as whether this is a read-only operation, what the response format looks like, pagination behavior, error handling, or rate limits. The example adds some context but is insufficient for a mutation-free tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the core purpose in the first sentence. The second sentence adds useful context and an example without unnecessary details. However, the example could be slightly more structured (e.g., using bullet points), but overall it's efficient with zero waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description is incomplete. It doesn't explain what the tool returns (e.g., market objects, error responses), behavioral aspects like rate limits or authentication needs, or how it differs from sibling tools. For a tool with 3 parameters and no structured output documentation, this leaves significant gaps for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters (tag_id, limit, closed) thoroughly. The description adds minimal value by referencing 'tag_id from get_all_tags' and providing an example, but doesn't explain parameter semantics beyond what the schema provides. Baseline 3 is appropriate when schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get markets filtered by tag ID.' It specifies the verb ('Get') and resource ('markets'), and indicates filtering by tag ID. However, it doesn't explicitly differentiate from sibling tools like 'filter_markets_by_category' or 'search_markets' beyond mentioning the tag filter.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides implied usage guidance by noting 'Source: tag_id from get_all_tags' and giving an example, which suggests using tag IDs from another tool. However, it doesn't explicitly state when to use this tool versus alternatives like 'filter_markets_by_category' or 'search_markets', nor does it mention prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool retrieves data ('Get'), implying a read-only operation, but doesn't disclose any behavioral traits such as rate limits, authentication needs, error handling, or what the return format looks like (e.g., JSON structure). This is a significant gap for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded, with the core purpose stated first ('Get volume and liquidity for a market by slug.'), followed by additional context. Both sentences earn their place by providing source guidance and an example, but it could be slightly more structured (e.g., separating usage notes). Overall, it's efficient with zero waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (a data retrieval tool with no annotations and no output schema), the description is incomplete. It lacks details on behavioral aspects (e.g., rate limits, auth), doesn't explain the return values or format, and provides minimal parameter guidance beyond the schema. For a tool in a server with many siblings, more context is needed to ensure proper agent selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the 'slug' parameter fully documented in the schema. The description adds minimal value beyond the schema by providing an example ('Example: slug=will-biden-win-2024'), which clarifies the expected format, but doesn't explain semantics like what a 'slug' represents or constraints beyond what's in the schema. Baseline 3 is appropriate given high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get volume and liquidity for a market by slug.' It specifies the verb ('Get'), resource ('volume and liquidity'), and key identifier ('by slug'), making the action explicit. However, it doesn't distinguish this tool from sibling tools like 'get_liquidity' or 'get_live_volume', which may offer similar functionality, so it misses full sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides implied usage guidance by mentioning 'Source: slug from search_markets/list_markets' and giving an example, which suggests when to use this tool (after obtaining a slug from those sources). However, it lacks explicit guidance on when to use this tool versus alternatives like 'get_liquidity' or 'get_market_details', and doesn't specify any exclusions or prerequisites, 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions the source of the market parameter but doesn't describe key traits like whether this is a read-only operation, potential rate limits, error conditions, or the format of the returned open interest data. This leaves significant gaps in understanding how the tool behaves beyond its basic function.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded, stating the core purpose in the first sentence. The additional information about the source and example is brief and relevant. However, it could be slightly more structured by separating usage notes into distinct points, but overall, it avoids unnecessary verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is incomplete for a tool that likely returns numerical or structured data (open interest). It doesn't explain what the output looks like (e.g., a value, units, timestamps) or address potential complexities like handling invalid markets. For a data-fetching tool with no structured output documentation, this is a significant shortfall.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the 'market' parameter documented as 'Market condition ID (0x...).' The description adds minimal value by reiterating this with 'Example: market=0x...' but doesn't provide additional semantics like valid ID formats or constraints beyond what the schema already states. Thus, it meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get open interest for a market.' It specifies the resource (open interest) and the target (a market), which is specific and actionable. However, it doesn't explicitly differentiate from siblings like 'get_market_details' or 'get_market_volume,' which might also provide related data, so it falls short of a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides some implied usage guidance by mentioning 'Source: market conditionId from list_markets,' which suggests using this tool after fetching market IDs from 'list_markets.' However, it doesn't explicitly state when to use this tool versus alternatives (e.g., 'get_market_details' might include open interest) or provide clear exclusions, 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions 'public on-chain data' which implies read-only access, but doesn't cover other important aspects like rate limits, authentication requirements, pagination behavior (beyond the schema parameters), error conditions, or response format. This is a significant gap for a tool with 4 parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately concise with two sentences: one stating the purpose and one providing usage guidance with an example. It's front-loaded with the core functionality. The example could be slightly more informative, but overall there's minimal waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 4 parameters, no annotations, and no output schema, the description is insufficient. It doesn't explain what the tool returns (positions format, data structure), error handling, rate limits, or authentication requirements. The lack of output schema means the description should compensate by explaining return values, which it doesn't do.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, so the schema already documents all 4 parameters thoroughly. The description adds minimal value by mentioning 'user address' and 'optional market conditionId' with an example, but doesn't provide additional semantic context beyond what's in the schema. This meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get a user's open positions (public on-chain data).' It specifies the resource (open positions) and the data source (public on-chain), but doesn't explicitly differentiate from sibling tools like 'get_closed_positions' or 'get_positions_value' beyond the 'open' qualifier.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides some usage context with 'Use user address; optional market conditionId' and an example, but doesn't explicitly state when to use this tool versus alternatives like 'get_closed_positions' or 'get_positions_value'. The guidance is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions that 'If no history, returns history=[]', which is useful, but fails to describe other critical behaviors such as rate limits, authentication requirements, error handling, or the format of returned data. For a tool with no annotations, this leaves significant gaps in understanding its operational traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded, starting with the core purpose. The additional sentences about sources, empty returns, and an example are relevant and add value without unnecessary verbosity. However, the structure could be slightly improved by explicitly separating guidelines from examples.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (5 parameters, no annotations, no output schema), the description is incomplete. It doesn't explain the output format, error conditions, or behavioral details like pagination or data freshness. While it covers basic usage, it falls short for a tool that retrieves historical data, where such context is crucial for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, meaning the input schema already documents all parameters thoroughly. The description adds minimal value beyond the schema by providing an example ('Example: token_id=clobTokenIds[0], interval=1h'), which clarifies usage but doesn't elaborate on parameter meanings or constraints. This meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get historical price data for a token.' It specifies the verb ('Get') and resource ('historical price data for a token'), making the intent unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'get_current_price' or 'get_batch_prices', which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides some usage context by mentioning data sources ('Source: clobTokenIds from list_active_markets or get_market_details') and an example, which implies when to use it. However, it lacks explicit guidance on when to choose this tool over alternatives (e.g., 'get_current_price' for real-time data or 'get_batch_prices' for multiple tokens), 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. It states the tool's action but doesn't describe key traits like whether it's read-only, potential rate limits, authentication needs, or what the output looks like (e.g., format, pagination). The example hint adds minimal context, but overall, it's insufficient for a mutation-free tool with no annotation support.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences: one stating the purpose and one providing source and example. It's front-loaded with the core function, and each sentence adds value (purpose and usage hint). However, it could be slightly more structured by separating guidelines into distinct points, but it's efficient with zero waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (a data retrieval tool with no annotations and no output schema), the description is incomplete. It lacks details on behavioral traits (e.g., safety, performance), output format, and how it differs from similar tools. While it covers basic purpose and parameter hints, it doesn't compensate for the missing structured data, making it inadequate for informed tool selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the input schema already fully documents the parameters (market and limit). The description adds marginal value by reinforcing the market parameter with an example ('Example: market=0x...') and hinting at its source, but doesn't provide additional semantics beyond what the schema offers. This meets the baseline of 3 for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get top holders for a market.' It specifies the resource (holders) and verb (get), and distinguishes it from siblings like 'get_market_by_id' or 'get_liquidity' by focusing on holder data. However, it doesn't explicitly differentiate from all siblings, such as 'get_positions' or 'get_trader_leaderboard,' which might also involve user/holder information, so it's not a perfect 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides some usage context by mentioning 'Source: market conditionId from list_markets' and giving an example, which implies when to use it (after obtaining a market ID from list_markets). However, it lacks explicit guidance on when to use this tool versus alternatives like 'get_positions' or 'get_trader_leaderboard,' and doesn't specify prerequisites or exclusions, keeping it at an implied level.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions filtering and pagination, which is useful, but doesn't describe important behavioral aspects like whether this is a read-only operation, what permissions are required, rate limits, error conditions, or the structure of returned data. The example helps but doesn't provide comprehensive behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and front-loaded with the core purpose. The two sentences are efficient, with the first stating the tool's function and the second providing an example and related tool context. There's no wasted text, though it could be slightly more structured for clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 7 parameters, no annotations, and no output schema, the description is insufficient. It doesn't explain what 'events' are in this context, what data is returned, how filtering parameters interact, or provide guidance on pagination strategy. The example helps but doesn't compensate for the lack of behavioral and output context needed for proper tool usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, so all parameters are documented in the schema. The description adds minimal value beyond the schema - it mentions 'filters' generally and provides one example parameter combination ('active=true, limit=20'), but doesn't explain parameter interactions, constraints, or provide additional semantic context. Baseline 3 is appropriate when schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('List') and resource ('events'), and mentions filtering and pagination capabilities. It distinguishes from some siblings like 'get_event_by_id' by indicating this is for listing rather than retrieving single events. However, it doesn't explicitly differentiate from other listing tools like 'list_markets' or 'list_series' beyond the resource type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides some usage context by mentioning that event IDs from this tool can be used with other tools ('list_comments/get_event_by_id/get_live_volume'), which implies a workflow relationship. It gives a usage example ('active=true, limit=20') but doesn't explicitly state when to use this tool versus alternatives like 'get_event_by_slug' or 'search_markets'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only mentions filtering and sorting capabilities without disclosing critical behavioral traits like pagination behavior (implied by limit/offset but not explained), rate limits, authentication requirements, or what the output format looks like. The example adds minimal context but leaves major gaps for a tool with 10 parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized with two sentences: one stating purpose and filters, another providing integration context and example. It's front-loaded with the core functionality, though the integration note could be more streamlined. No wasted sentences, but the example feels slightly tacked on.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 10 parameters, no annotations, and no output schema, the description is incomplete. It doesn't explain the return format, pagination behavior beyond mentioning limit, error conditions, or how multiple filters interact. The integration context is helpful but doesn't compensate for missing behavioral transparency needed for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 adds marginal value by listing filter types (active/closed/tag/date/sort) and providing a brief example, but doesn't explain parameter interactions (e.g., how active and closed filters combine) or add meaningful semantics beyond what's already documented in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('List') and resource ('markets') with the scope of filtering capabilities. It distinguishes from siblings like 'list_active_markets' by mentioning broader filters beyond just active status, but doesn't explicitly contrast with all similar tools like 'filter_markets_by_category' or 'search_markets'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides implied usage context by mentioning 'conditionId for Data API and clobTokenIds for CLOB tools,' suggesting integration points, but doesn't explicitly state when to use this tool versus alternatives like 'search_markets' or 'filter_markets_by_category.' No when-not-to-use guidance or clear prerequisites are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions 'alerts' and 'monitor for resolution' but lacks critical details: whether this creates a persistent subscription, what format alerts take, authentication requirements, rate limits, or how to unsubscribe (though 'unsubscribe_realtime' exists as a sibling). For a subscription tool with no annotations, this leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences: one stating the purpose and one providing context/example. It's front-loaded with the core functionality. However, the example syntax 'market_ids=[conditionId]' is slightly ambiguous (brackets vs. actual array), and the source list could be more efficiently formatted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (subscription with real-time behavior), no annotations, and no output schema, the description is incomplete. It doesn't explain what happens after subscription, alert delivery mechanisms, error handling, or relationship to 'unsubscribe_realtime'. For a subscription tool in this context, more behavioral and operational details are needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters thoroughly. The description adds minimal value: it mentions 'condition IDs' (implied for market_ids) and provides a brief example, but doesn't explain parameter semantics beyond what the schema provides. This meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Subscribe to market resolution alerts by condition IDs.' It specifies the verb ('subscribe'), resource ('market resolution alerts'), and key parameter ('condition IDs'). However, it doesn't explicitly differentiate from sibling tools like 'subscribe_market_prices' or 'subscribe_orderbook_updates' beyond mentioning different alert types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides some usage context by mentioning source tools ('list_markets/list_active_markets/get_market_by_slug') and an example, which implies when to use this tool (after obtaining condition IDs from those sources). However, it doesn't explicitly state when to use this versus alternatives like 'subscribe_market_prices' or provide clear exclusions. The guidance is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions 'real-time' updates and gives an example, but fails to describe critical behaviors: whether this is a persistent subscription, how updates are delivered (e.g., streaming vs polling), error handling, or authentication requirements. For a subscription tool with zero annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is reasonably concise with three sentences that each serve a purpose: stating the tool's function, providing source/reference tools, and giving an example. It could be slightly more front-loaded by leading with the core purpose more clearly, but overall it avoids unnecessary verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a real-time subscription tool with no annotations and no output schema, the description is incomplete. It lacks details on what the subscription returns (e.g., update format, frequency), how to manage/unsubscribe, and error scenarios. The example helps but doesn't compensate for these gaps, making it inadequate for confident tool invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all three parameters thoroughly. The description adds minimal value beyond the schema: it mentions 'token_ids' in the main purpose and provides an example format, but doesn't explain parameter interactions or usage nuances. This meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Subscribe to real-time orderbook updates by token_ids'. It specifies the resource (orderbook updates) and the subscription mechanism. However, it doesn't explicitly differentiate from sibling tools like 'subscribe_market_prices' or 'subscribe_market_resolution', which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides some usage context by mentioning 'Source: list_active_markets/get_market_details' and 'Use get_realtime_status to inspect events', which implies prerequisites and complementary tools. However, it doesn't explicitly state when to use this tool versus alternatives like 'get_order_book' or other subscription tools, leaving the guidelines somewhat implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 the action ('Unsubscribe') and the parameter source, but lacks critical behavioral details such as whether this is a destructive operation, if it requires specific permissions, what happens on success/failure, or if there are side effects like stopping data streams. For a tool that likely modifies state, this is insufficient disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded, stating the purpose clearly in the first sentence. The second sentence adds useful context without redundancy. However, it could be slightly more structured by separating usage notes from examples, but overall it's efficient with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a subscription management tool with no annotations and no output schema, the description is incomplete. It doesn't cover behavioral aspects like effects of unsubscribing, error conditions, or response format. For a tool that likely interacts with real-time systems, more context on implications and outcomes is needed to be fully helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the parameter 'subscription_id' fully documented in the schema. The description adds minimal value by noting the source ('from subscribe_* response') and providing an example format, but doesn't explain semantics beyond what the schema already states (e.g., what a subscription ID represents). Baseline 3 is appropriate as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Unsubscribe from a real-time feed') and identifies the resource (a subscription). It distinguishes from siblings by specifying the source of subscription_id from subscribe_* responses, though it doesn't explicitly name alternatives. The purpose is specific but could be more differentiated from sibling unsubscribe tools if they existed.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool (to stop a subscription) and provides context about the subscription_id source, but it doesn't explicitly state when not to use it or name alternatives. For example, it doesn't clarify if this is for any real-time feed or specific ones, or if there are other unsubscribe methods. The guidance is useful but not comprehensive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions the return format ('Returns market data or error per slug') and provides an example, but doesn't cover important behavioral aspects like whether this is a read-only operation, rate limits, authentication requirements, error handling specifics, or what 'market data' includes. For a tool with no annotations, this leaves significant gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately concise with three sentences that each serve a purpose: stating the core function, providing source context, and giving an example. It's front-loaded with the main purpose. There's minimal waste, though the example could be slightly more informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description provides basic context but leaves significant gaps. It covers the purpose and parameter usage but doesn't explain what 'market data' includes in the return, error conditions beyond 'error per slug', or behavioral constraints. For a comparison tool with no structured output documentation, this is minimally adequate but incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already fully documents the single parameter (market_slugs with type, constraints, and description). The description adds minimal value beyond the schema - it mentions the parameter in the example but doesn't provide additional semantic context about what constitutes valid slugs or how comparison works. Baseline 3 is appropriate when schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Compare multiple markets by slug' specifies the verb (compare) and resource (markets). It distinguishes from siblings like get_market_by_slug (single market) and list_markets (listing without comparison), but doesn't explicitly differentiate from all siblings like filter_markets_by_category. The description is specific but lacks full sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides some usage guidance by mentioning 'Source: slugs from search_markets/list_markets' which implies when to use this tool (after obtaining slugs from those tools). However, it doesn't explicitly state when NOT to use it or name specific alternatives for different use cases. The guidance is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions the tool lists tags and gives an example usage flow, but fails to disclose critical behavioral traits like whether it's paginated, rate-limited, requires authentication, returns structured data, or has performance characteristics. The example is helpful but insufficient for full transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief but could be more structured. The first sentence 'List all tags' is clear and front-loaded. However, the following sentences are somewhat fragmented ('Example: call then pick tag_id.') and could be more polished. It earns its place but lacks optimal flow.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 0 parameters, no annotations, and no output schema, the description provides basic purpose and usage context but is incomplete. It doesn't describe the return format (e.g., list of tag objects with id/name), which is critical since there's no output schema. For a simple read operation, it's minimally adequate but leaves gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters with 100% schema description coverage, so no parameter documentation is needed. The description appropriately doesn't discuss parameters, focusing instead on purpose and usage. Baseline for 0 parameters is 4, as it efficiently avoids unnecessary parameter explanations.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with 'List all tags' (verb+resource). It distinguishes from siblings by specifying it retrieves all tags rather than filtering or analyzing markets. However, it doesn't explicitly contrast with similar list operations like 'list_markets' or 'list_events'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides implied usage guidance by mentioning sibling tools 'get_markets_by_tag' and 'list_markets tag_slug' as follow-up actions, suggesting this tool is for obtaining tag IDs to use elsewhere. However, it lacks explicit when/when-not instructions or clear alternatives among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 states the tool retrieves a comment by ID but doesn't disclose behavioral traits such as error handling (e.g., what happens if the ID is invalid), authentication requirements, rate limits, or response format. The example 'id=2064395' adds minimal context but doesn't compensate for the lack of critical 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and front-loaded: the first sentence states the core purpose, followed by a source note and an example. Every sentence adds value without redundancy, making it efficient and well-structured for quick understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (1 parameter, no output schema, no annotations), the description is incomplete. It lacks details on behavioral aspects like error handling or response format, and while the schema covers parameters, the overall context for safe and effective use is insufficient. For a retrieval tool with no annotations, more guidance is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the parameter 'id' fully documented in the schema as 'The comment ID'. The description adds marginal value by specifying 'Source: id from list_comments', which clarifies the parameter's origin but doesn't provide additional semantics beyond what the schema already covers. This meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get a comment by id' specifies the verb ('Get') and resource ('comment'), and it distinguishes from siblings by focusing on individual comment retrieval rather than listing. However, it doesn't explicitly differentiate from other 'get_' tools like get_event_by_id or get_market_by_id, which follow similar patterns.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides implied usage guidance by mentioning 'Source: id from list_comments', suggesting this tool should be used after obtaining IDs from list_comments. However, it lacks explicit when-to-use vs. alternatives (e.g., when to use this over list_comments for bulk retrieval) or any exclusions, making it somewhat vague.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool retrieves markets for an event but doesn't describe key behaviors such as whether it's a read-only operation, what the output format looks like, if there are rate limits, or authentication requirements. For a tool with zero annotation coverage, this leaves significant gaps in understanding its behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded, with two concise sentences that directly state the purpose and provide an example. There is no wasted text, and every sentence adds value, making it efficient and well-structured for quick understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of retrieving event markets, the lack of annotations and output schema means the description should do more to compensate. It doesn't explain the return values, potential errors, or behavioral traits like pagination or data freshness. With no structured fields to rely on, the description is incomplete for effective tool use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with both parameters (event_slug and event_id) well-documented in the input schema. The description adds minimal value by mentioning these parameters and providing an example (event_id=80505), but doesn't elaborate on semantics beyond what the schema already states. This meets the baseline score when schema coverage is high.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get markets for a specific event.' It specifies the verb ('Get') and resource ('markets for a specific event'), making the action clear. However, it doesn't explicitly distinguish this tool from similar siblings like 'get_market_by_id' or 'list_markets', which reduces it from a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides some usage guidance by mentioning that event_id or event_slug should come from 'list_events/search_markets', which implies context for when to use this tool. However, it doesn't explicitly state when to choose this tool over alternatives like 'get_event_by_id' or 'list_markets', nor does it provide exclusions or detailed prerequisites, keeping it at an implied level.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool retrieves 'live trading volume,' implying real-time data, but does not clarify aspects like rate limits, authentication requirements, data freshness, or error handling. This leaves gaps in understanding the tool's operational behavior beyond its basic function.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded, with the core purpose stated first. It consists of two sentences that provide essential information without redundancy. However, the example could be integrated more smoothly, and there is room for slight improvement in flow, but overall it is efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema, no annotations), the description is adequate but incomplete. It covers the basic purpose and parameter source but lacks details on return values, error cases, or behavioral traits. For a read-only tool with minimal complexity, this is passable but leaves room for enhancement in providing a fuller context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the 'id' parameter documented as 'Event ID to get live volume for.' The description adds minimal value by providing an example ('Example: id=80505') and referencing 'list_events' as the source, but does not elaborate on parameter semantics beyond what the schema already states. This meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get live trading volume for an event.' It specifies the verb ('Get') and resource ('live trading volume for an event'), making the function unambiguous. However, it does not explicitly differentiate from sibling tools like 'get_market_volume' or 'get_total_traded', which might offer similar volume data, so it falls short of a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides some usage context by mentioning 'Source: event id from list_events,' which implies this tool should be used after fetching events via 'list_events.' However, it lacks explicit guidance on when to use this tool versus alternatives like 'get_market_volume' or 'get_total_traded,' and does not specify any exclusions or prerequisites beyond the event ID.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions what the tool returns ('Returns clobTokenIds and conditionId'), which is helpful behavioral information not in the schema. However, it doesn't disclose other important traits: whether this is a read-only operation, potential error conditions, rate limits, authentication needs, or what happens with invalid IDs. For a lookup tool with zero annotation coverage, this leaves significant gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately concise at three short sentences. It's front-loaded with the core purpose, followed by source context and return values, then an example. No wasted words, though the example could be slightly more informative (e.g., showing the full parameter syntax rather than just 'id=680392').
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter lookup tool with no output schema, the description provides basic completeness: purpose, parameter context, and return values. However, without annotations or output schema, it should ideally cover more behavioral aspects (error handling, data freshness, etc.). The example helps but doesn't fully compensate for missing structured information about the tool's operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents the single 'id' parameter thoroughly. The description adds minimal value beyond the schema: it reinforces that the ID is 'numeric' and provides an example ('Example: id=680392'), but doesn't explain format constraints, valid ranges, or relationship to other tools beyond the 'Source: id from list_markets' hint. With high schema coverage, baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get market details by numeric id.' It specifies the verb ('Get'), resource ('market details'), and key constraint ('by numeric id'). However, it doesn't explicitly differentiate from sibling tools like 'get_market_by_slug' or 'get_market_details', which appear to serve similar purposes with different identifiers.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides some usage context: 'Source: id from list_markets' implies this tool should be used with IDs obtained from the list_markets tool. However, it doesn't explicitly state when to use this versus alternatives like get_market_by_slug or get_market_details, nor does it provide any exclusion criteria or prerequisites beyond the ID source.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 'public data,' which hints at read-only access, but doesn't disclose other behavioral traits like rate limits, authentication needs, or what 'total value' entails (e.g., currency, calculation method). For a tool with no annotations, this leaves significant gaps in understanding its behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded, with the purpose stated clearly in the first sentence. The second sentence adds practical guidance with an example, making it efficient. However, it could be slightly more structured by separating usage notes from the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (simple read operation with one parameter) and lack of annotations and output schema, the description is moderately complete. It covers the basic purpose and parameter usage but misses details on return values, error handling, and behavioral constraints. It's adequate but has clear gaps for a tool with no structured output information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the 'user' parameter fully documented as 'User Ethereum address (0x...).' The description adds minimal value beyond this by providing an example ('Example: user=0xabc....'), but doesn't explain semantics like address validation or format requirements. Baseline score of 3 is appropriate since the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get total value of a user's positions (public data).' It specifies the verb ('Get'), resource ('total value of a user's positions'), and scope ('public data'), making it easy to understand. However, it doesn't explicitly differentiate from sibling tools like 'get_positions' or 'get_closed_positions,' which might provide related but different data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides some usage guidance by stating 'Use user address' and giving an example, which implies when to use this tool (when you need total value for a specific user). However, it doesn't explicitly mention when not to use it or alternatives (e.g., vs. 'get_positions' for detailed position data). The guidance is implied but not comprehensive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 'Series includes events array', which adds some behavioral context about the return structure. However, it fails to disclose critical traits like whether this is a read-only operation, potential rate limits, authentication needs, or error handling, which are significant gaps for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the core purpose in the first sentence. The additional sentences provide useful context without redundancy. However, the example could be more integrated, and there's slight room for tighter phrasing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description is moderately complete for a simple lookup tool. It covers the purpose, parameter source, and hints at return structure ('events array'), but lacks details on output format, error cases, or behavioral constraints, which are needed for full contextual understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the 'id' parameter documented as 'The series ID'. The description adds minimal value by referencing 'id from list_series' and providing an example 'id=10543', but doesn't explain format constraints or validation beyond what the schema implies. This meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get series by id' specifies the verb ('Get') and resource ('series'), and it distinguishes the resource from siblings like 'get_event_by_id' or 'get_market_by_id'. However, it doesn't explicitly differentiate from 'list_series' beyond mentioning the source, which keeps it from a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides implied usage guidance by stating 'Source: id from list_series', suggesting this tool should be used after retrieving IDs from 'list_series'. It doesn't explicitly state when not to use it or name alternatives, leaving some ambiguity compared to other ID-based tools like 'get_event_by_id'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions returning a 'concise usage guide' but doesn't disclose behavioral traits like whether it's read-only, requires authentication, has rate limits, or what format the guide is in (e.g., text, structured data). For a tool with zero annotation coverage, this leaves significant gaps in understanding its operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the key action ('Return') and details what the guide includes. Every word earns its place, with no redundancy or unnecessary elaboration, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters, no annotations, and no output schema, the description is moderately complete. It explains what the tool returns but lacks details on the guide's format, dependencies, or examples structure. For a tool with low complexity, it's adequate but could be more informative about behavioral aspects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and schema description coverage is 100%, so no parameter documentation is needed. The description doesn't add parameter details, which is appropriate. A baseline of 4 is applied as it compensates adequately for the lack of parameters by focusing on the tool's output purpose.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Return a concise usage guide with workflows, dependencies, and examples for this MCP.' It specifies the verb ('Return') and resource ('concise usage guide'), and outlines what the guide contains. However, it doesn't explicitly differentiate from siblings, which appear to be data retrieval tools for markets, events, and analytics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It lacks context about prerequisites, such as whether it requires prior tool usage or specific states. Without explicit when/when-not instructions or named alternatives, it offers minimal usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 'public data' which hints at read-only access, but doesn't disclose other behavioral traits such as rate limits, authentication requirements, pagination behavior (beyond parameters), or what the return format looks like. For a tool with no annotation coverage, this leaves significant gaps in understanding its operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded, starting with the core purpose. The example is helpful but could be more integrated. It avoids unnecessary words, though it could be slightly more structured (e.g., separating purpose from filtering details).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description is moderately complete for a read operation. It covers the purpose and basic filtering, but lacks details on return format, error handling, or behavioral constraints. For a tool with 4 parameters and public data access, it should provide more context about what 'trade history' entails and how results are structured.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all four parameters thoroughly. The description adds minimal value by mentioning filtering by 'user address and/or market conditionId' and providing an example, but doesn't explain parameter semantics beyond what's in the schema (e.g., format details or usage nuances). Baseline 3 is appropriate when schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get trade history (public data)' specifies the verb ('Get') and resource ('trade history'), and clarifies it's public data. However, it doesn't explicitly differentiate from sibling tools like 'get_closed_positions' or 'get_positions', which might overlap in functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides implied usage guidance by mentioning filtering options ('Filter by user address and/or market conditionId from list_markets') and includes an example. However, it doesn't explicitly state when to use this tool versus alternatives like 'get_closed_positions' or 'get_positions', nor does it mention prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions pagination and gives an example, but doesn't describe key behaviors such as rate limits, authentication requirements, error handling, or the format of returned data. For a list tool with zero annotation coverage, this leaves significant gaps in understanding how the tool operates.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded, with the main purpose stated first, followed by usage context and an example. Both sentences earn their place by adding clarity, though it could be slightly more structured (e.g., separating usage from examples). Overall, it's efficient with zero waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (2 parameters, no output schema, no annotations), the description is somewhat complete but has gaps. It covers the purpose and basic usage but lacks details on behavioral aspects like data format or error handling. For a simple list tool, this is minimally adequate but not fully comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already fully documents the 'limit' and 'offset' parameters. The description adds minimal value beyond the schema by providing an example ('limit=20, offset=0'), but doesn't explain parameter semantics or constraints further. This meets the baseline score of 3 when schema coverage is high.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'List sports teams with pagination.' It specifies the verb ('list'), resource ('sports teams'), and includes pagination as a key feature. However, it doesn't explicitly differentiate from sibling tools like 'get_sports_metadata' or 'list_events' which might also relate to sports data, leaving some ambiguity about its unique role.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides some usage guidance with 'Use to map team names/abbreviations in sports markets,' which implies a context for when this tool is helpful. However, it doesn't specify when to use this tool versus alternatives (e.g., 'get_sports_metadata' or other list tools), nor does it mention any prerequisites or exclusions, making the guidance incomplete.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but offers limited behavioral insight. It mentions the HTTP method (POST) and endpoint (/prices), and that it returns {} if no prices found, but doesn't cover important aspects like rate limits, authentication needs, error handling, or what the successful response structure looks like (only the empty case is mentioned).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately concise with three sentences that each serve a purpose: stating the tool's function, specifying the source of parameters, and providing an example. It's front-loaded with the core functionality, though the example could be slightly clearer.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations and no output schema, the description is incomplete. It doesn't explain the response format for successful cases (only mentions the empty {} case), doesn't cover error conditions, rate limits, or authentication requirements. Given the complexity of a price-fetching tool in a financial context, more behavioral context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, so the schema already documents the 'token_ids' parameter thoroughly. The description adds minimal value beyond the schema by mentioning where to source token IDs and providing an example format, but doesn't explain parameter semantics like valid token ID formats or constraints beyond what's in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Batch prices via POST CLOB /prices' indicates it retrieves multiple prices through a specific API endpoint. It specifies the resource (prices) and verb (get/batch), though it doesn't explicitly differentiate from sibling tools like 'get_current_price' or 'get_batch_order_books' beyond mentioning the source of token IDs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool: it specifies that token IDs should come from 'list_active_markets or get_market_details' and shows an example format. However, it doesn't explicitly state when NOT to use it or mention alternatives like 'get_current_price' for single prices, though the batch nature is implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It adds value by specifying the HTTP method (GET), endpoint details, and error behavior (invalid addresses may return 500). However, it doesn't cover other important aspects like rate limits, authentication needs, response format, or what 'bridge history' entails, leaving gaps for a tool with potential network interactions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is highly concise and front-loaded, with two sentences that efficiently convey the core functionality, endpoint, constraints, and an example. Every sentence adds value without redundancy, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (network call with potential errors), lack of annotations, and no output schema, the description is moderately complete. It covers the basic operation and error case but omits details like response structure, success conditions, or integration context. For a tool interacting with an external API, more behavioral context would be beneficial.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with the parameter 'address' fully documented in the input schema. The description adds minimal semantics beyond the schema by providing an example ('address=0xabc....') and noting address requirements, but it doesn't elaborate on format constraints or validation rules. This meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Check bridge transactions' via a specific HTTP endpoint. It specifies the resource (bridge transactions) and the action (check status), which is specific and actionable. However, it doesn't explicitly differentiate from sibling tools like 'get_bridge_quote', which might be related but serves a different purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides some usage context by noting that 'Address must have bridge history' and warns about invalid addresses returning 500 errors. However, it lacks explicit guidance on when to use this tool versus alternatives (e.g., 'get_bridge_quote' or other transaction-related tools), and there's no mention of prerequisites or when-not-to-use scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions the tool is 'public' (implying no authentication needed) and supports pagination, but doesn't describe rate limits, error conditions, response format, or whether the data is real-time versus cached. For a data retrieval tool with zero annotation coverage, this leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and front-loaded, with only two sentences that directly address the tool's purpose and usage. Every word earns its place, with no redundant or vague phrasing, making it easy for an AI agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (2 parameters, no annotations, no output schema), the description is minimally adequate. It covers the basic purpose and pagination but lacks details on response format, data freshness, or error handling. Without annotations or an output schema, the description should do more to compensate, but it meets the minimum viable threshold.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both parameters ('limit', 'offset') well-documented in the schema. The description adds minimal value beyond the schema by providing an example ('limit=50, offset=0'), which clarifies typical usage but doesn't explain parameter semantics beyond what the schema already states. This meets the baseline of 3 for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose as 'Get builder leaderboard (public)', which specifies the verb ('Get'), resource ('builder leaderboard'), and scope ('public'). It distinguishes this from other leaderboard tools like 'get_trader_leaderboard' by specifying 'builder', but doesn't differentiate from non-leaderboard siblings beyond the resource name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides implied usage guidance through the pagination example ('Use limit/offset for pagination'), suggesting this tool is for retrieving paginated leaderboard data. However, it doesn't explicitly state when to use this tool versus alternatives like 'get_trader_leaderboard' or other data retrieval tools, nor does it mention any prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions 'public data,' which hints at accessibility without authentication, but doesn't clarify if this is a read-only operation, its rate limits, error handling, or what 'total markets' means (e.g., count, list). For a tool with no annotations, this leaves significant behavioral gaps, though it's not misleading.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and front-loaded: it states the purpose in the first sentence and provides usage guidance and an example in the second. Every sentence earns its place with no wasted words, making it easy to parse quickly. The structure is efficient and clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (1 parameter, no output schema, no annotations), the description is adequate but has gaps. It covers the basic purpose and parameter usage, but lacks details on behavioral aspects (e.g., response format, error cases) and doesn't leverage the absence of annotations to provide more context. For a straightforward tool, it's minimally viable but could be more complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with the parameter 'user' fully documented in the schema as 'User Ethereum address (0x...).' The description adds minimal value beyond this by providing an example ('Example: user=0xabc....'), but doesn't explain semantics like address validation or format beyond what the schema states. With high schema coverage, the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get total markets a user has traded in (public data).' It specifies the verb ('Get'), resource ('total markets'), and scope ('a user has traded in'), though it doesn't explicitly differentiate from sibling tools like 'get_user_activity' or 'get_trades' which might provide related data. The purpose is specific and actionable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides some usage context by specifying 'Use user address' and giving an example, which implies when to use this tool—when you need aggregated trading data for a specific user. However, it doesn't explicitly state when to use this versus alternatives (e.g., 'get_user_activity' for detailed activity or 'get_trades' for individual trades), nor does it mention any prerequisites or exclusions. The guidance is implied but not comprehensive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the tool is 'public' (implying no authentication needed) and describes pagination behavior, but doesn't cover other important aspects like rate limits, error conditions, response format, or whether the data is real-time vs. cached. For a read operation with zero annotation coverage, this leaves significant gaps in understanding how the tool behaves.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and well-structured: a clear purpose statement followed by practical usage information (pagination parameters and example). Every sentence earns its place with zero wasted words, making it easy to parse and understand quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (public data retrieval with pagination), no annotations, and no output schema, the description provides basic but incomplete context. It covers the core purpose and pagination mechanism but lacks details about response format, data freshness, sorting criteria, or error handling. For a leaderboard tool that likely returns structured ranking data, more context would be helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both parameters ('limit' and 'offset') clearly documented in the schema. The description adds minimal value beyond the schema by mentioning these are for 'pagination' and providing an example, but doesn't explain parameter interactions, default values, or constraints beyond what's already in the structured schema. This meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get trader leaderboard (public)' specifies both the verb ('Get') and resource ('trader leaderboard'), with 'public' indicating accessibility. However, it doesn't explicitly differentiate from sibling tools like 'get_builder_leaderboard', which serves a similar function for a different resource type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides implied usage guidance by mentioning pagination parameters ('limit/offset for pagination') and giving an example ('limit=50, offset=0'), which suggests when to use these parameters. However, it lacks explicit guidance on when to choose this tool over alternatives like 'get_builder_leaderboard' or other leaderboard-related tools, and doesn't mention any prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions 'public data,' which implies read-only access, but doesn't specify permissions, rate limits, pagination behavior (beyond the example with limit), or what the activity feed contains. For a tool with no annotations, this leaves significant gaps in understanding its operational traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded: the first sentence states the purpose clearly, and the second provides concise usage guidance with an example. Every sentence earns its place without redundancy, making it efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (3 parameters, no output schema, no annotations), the description is adequate but incomplete. It covers the basic purpose and usage but lacks details on behavioral aspects (e.g., pagination, data format) and doesn't leverage annotations or output schema to fill gaps. It's minimally viable but leaves room for improvement in context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters (user, limit, offset) with clear descriptions. The description adds minimal value by providing an example ('user=0xabc..., limit=50'), which hints at usage but doesn't add semantic details beyond the schema. This meets the baseline score of 3 for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get a user's activity feed (public data).' It specifies the verb ('Get'), resource ('user's activity feed'), and scope ('public data'), which is specific and actionable. However, it doesn't explicitly differentiate from sibling tools, as none appear to be direct alternatives for fetching user activity data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides implied usage guidance by mentioning 'Use user address' and giving an example, which suggests when to use this tool (for retrieving activity feeds based on a user address). However, it lacks explicit guidance on when to use this tool versus alternatives (e.g., no mention of sibling tools like get_public_profile that might overlap) or any exclusions, leaving some ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions the API endpoint and example return structure ('returns {marketTypes:[...]}'), but lacks details on authentication needs, rate limits, error handling, or whether this is a read-only operation. For a tool with zero annotation coverage, this leaves significant gaps in understanding its behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded, with two sentences that directly state the purpose and provide a usage example. There's no unnecessary information, though it could be slightly more structured by separating the example into a distinct guideline.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters, no annotations, and no output schema, the description is moderately complete. It covers the purpose and gives a usage hint, but lacks behavioral details like response format beyond the basic example, error cases, or integration context. For a simple read operation, this is adequate but with clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately doesn't discuss parameters, focusing instead on the tool's purpose and usage. This meets the baseline for tools with no parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get valid sports market types from Gamma API /sports/market-types'. It specifies the verb ('Get'), resource ('valid sports market types'), and source ('Gamma API'), but doesn't explicitly differentiate from sibling tools like 'get_sports_metadata' or 'get_all_tags', which might also retrieve metadata-related information.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides implied usage guidance with 'Example: use result in sports filters.', suggesting this tool is for obtaining data to filter sports markets. However, it doesn't explicitly state when to use this tool versus alternatives like 'get_sports_metadata' or 'filter_markets_by_category', nor does it mention any prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 HTTP method (GET) and expected response format (JSON {data:'OK'}), which are useful behavioral traits. However, it lacks details on error handling, timeouts, or authentication needs, leaving gaps for a health check tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and front-loaded: it states the action, method, endpoint, and response in one sentence. Every word earns its place, with no wasted information, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (0 parameters, no output schema, no annotations), the description is somewhat complete but has gaps. It covers the basic operation and response, but lacks error handling or usage context. For a health check tool, more behavioral details (e.g., what 'OK' implies) would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and schema description coverage is 100% (empty schema). The description doesn't need to add parameter semantics, as there are none to explain. A baseline of 4 is appropriate since it efficiently handles the no-parameter case without redundancy.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Check Data API health via GET /.' It specifies the verb ('Check') and resource ('Data API health'), and mentions the HTTP method and endpoint. However, it doesn't explicitly differentiate from sibling tools like 'check_health_gamma', which might check a different API's health, so it's not a perfect 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'check_health_gamma' or explain the context for health checks (e.g., monitoring, diagnostics). Without any usage context, the agent must infer when this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the HTTP method (POST) and return behavior ('If none found, returns {}'), which adds some context. However, it lacks critical details: authentication requirements, rate limits, error handling, response format beyond the empty object example, or whether this is a read-only operation. For a batch query tool with zero annotation coverage, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized with three concise sentences. It's front-loaded with the core purpose, followed by source guidance and an example. There's minimal waste, though the example could be slightly more informative. Every sentence contributes useful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (batch operation with one parameter), 100% schema coverage, but no annotations or output schema, the description is partially complete. It covers purpose, usage context, and a basic example, but lacks behavioral details like authentication, response structure beyond empty cases, or error scenarios. For a batch query tool without output schema, more completeness would be beneficial.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already fully documents the single parameter 'token_ids'. The description adds marginal value by providing example token ID sources ('clobTokenIds from list_active_markets or get_market_details') and an example array format, but doesn't explain parameter semantics beyond what the schema provides. The baseline of 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Batch spreads via POST CLOB /spreads' indicates it retrieves spread data for multiple tokens in batch. It specifies the resource (spreads) and method (POST), distinguishing it from sibling tools like 'get_spread' (singular) and 'get_batch_prices' (different data). However, it doesn't explicitly contrast with all similar siblings like 'get_batch_order_books'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool: 'Source: clobTokenIds from list_active_markets or get_market_details' specifies where to obtain the required token IDs. It implies usage for batch operations rather than single-token queries. However, it doesn't explicitly state when NOT to use it or name direct alternatives like 'get_spread' for single tokens.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It usefully adds that the tool may return a 404 error if the token lacks an active CLOB/order book, which is important context. However, it doesn't describe other behavioral aspects like rate limits, authentication needs, response format, or whether it's a read-only operation (though 'Get' implies reading). The description adds some value but leaves gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately concise with three sentences that each serve a purpose: stating the tool's function, providing source and error context, and giving an example. It's front-loaded with the core purpose. There's no wasted text, though it could be slightly more structured for clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (single parameter, no output schema, no annotations), the description is somewhat complete but has gaps. It covers the purpose, parameter source, and an error condition, but doesn't explain the return value format or how the midpoint price is calculated. For a tool with no annotations or output schema, more behavioral and output context would be beneficial.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the token_id parameter fully documented in the schema. The description adds minimal value beyond the schema by providing an example ('Example: token_id=clobTokenIds[0]') and mentioning the source of valid token IDs. This meets the baseline of 3 when schema coverage is high, but doesn't significantly enhance parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get midpoint price via CLOB /midpoint.' It specifies the verb ('Get') and resource ('midpoint price'), and mentions the data source ('CLOB'). However, it doesn't explicitly differentiate from sibling tools like 'get_current_price' or 'get_spread' that might provide similar price-related data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides some usage context by mentioning the source of token IDs ('Source: clobTokenIds from list_active_markets or get_market_details') and a condition for failure ('If token has no active CLOB/order book, returns 404'). However, it doesn't explicitly state when to use this tool versus alternatives like 'get_current_price' or 'get_spread', nor does it provide clear exclusions or prerequisites beyond the token ID requirement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. While it mentions 'real-time price changes' and provides an example, it doesn't describe what 'subscribe' entails operationally - whether this creates a persistent connection, polling mechanism, or webhook. It doesn't mention authentication requirements, rate limits, error handling, or what happens when subscription ends. The description adds some context but leaves critical behavioral aspects unspecified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized with three sentences. The first sentence states the core purpose, the second provides source context and related tools, and the third gives an example. Each sentence adds value, though the structure could be slightly improved by front-loading the example more clearly. There's minimal wasted text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given this is a subscription tool with 2 parameters (100% schema coverage) but no annotations and no output schema, the description is moderately complete. It covers the basic purpose, parameter sources, and related tools, but lacks critical information about subscription behavior, return values, error conditions, and operational constraints. For a real-time subscription tool, more behavioral context would be expected.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already fully documents both parameters (market_ids and callback_type). The description adds minimal value beyond the schema: it provides an example format 'market_ids=[conditionId]' and mentions the source of market IDs, but doesn't explain parameter interactions or provide additional semantic context. This meets the baseline 3 when schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Subscribe to real-time price changes by market condition IDs' with a specific verb ('Subscribe') and resource ('real-time price changes'). It distinguishes from siblings by mentioning 'market condition IDs' and referencing specific sibling tools (list_markets, etc.), but doesn't explicitly differentiate from similar subscription tools like subscribe_market_resolution or subscribe_orderbook_updates.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool: when needing real-time price updates for specific market condition IDs obtained from list_markets/list_active_markets/get_market_by_slug. It also mentions using get_realtime_status to inspect events, providing related tool guidance. However, it doesn't explicitly state when NOT to use it or when to choose alternatives like get_current_price for one-time queries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. While it mentions what data is returned ('event details, including associated markets'), it doesn't disclose important behavioral traits like whether this is a read-only operation, potential rate limits, authentication requirements, error conditions, or response format. For a tool with zero annotation coverage, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and well-structured: a clear purpose statement, source guidance, and an example - all in just two sentences. Every element earns its place with no wasted words, making it easy for an AI agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (single parameter lookup), 100% schema coverage, but no output schema and no annotations, the description is adequate but incomplete. It covers the basic purpose and parameter source but lacks behavioral context about the operation's safety profile, response format, or error handling. For a read operation with no output schema, more detail about what 'event details' includes would be helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, so the schema already documents the single 'id' parameter with its type and description. The description adds minimal value beyond the schema by providing an example ('Example: id=80505') and indicating the source ('Source: id from list_events'), but doesn't add substantial semantic context. This meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get event details by id, including associated markets.' This specifies the verb ('Get'), resource ('event details'), and scope ('including associated markets'). However, it doesn't explicitly differentiate from sibling tools like 'get_event_by_slug' or 'get_event_markets', which reduces it from a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool: 'Source: id from list_events.' This indicates the parameter should come from the list_events tool. However, it doesn't explicitly state when NOT to use it or mention alternatives like 'get_event_by_slug' for slug-based lookup, so it falls short of a perfect score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the fallback behavior ('Falls back to top-volume active markets'), which is valuable context beyond basic retrieval. However, it lacks details on permissions, rate limits, or response format, leaving gaps for a read operation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two sentences that each serve a clear purpose: stating the tool's function and providing a usage example. It's front-loaded with the core purpose and wastes no words, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (1 parameter, no output schema, no annotations), the description is adequate but minimal. It covers the purpose and fallback behavior but lacks details on return values or error handling. For a simple read tool, this is acceptable but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents the 'limit' parameter. The description adds minimal value with the example 'limit=10', which reinforces the default but doesn't provide additional semantics beyond what's in the schema. This meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get featured/promoted markets' with the specific action 'Get' and resource 'featured/promoted markets'. It distinguishes from siblings like 'get_trending_markets' or 'list_markets' by specifying a particular subset of markets, though it doesn't explicitly contrast with them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context with 'Falls back to top-volume active markets', suggesting this tool is for retrieving promoted content with a fallback mechanism. However, it doesn't provide explicit guidance on when to use this versus alternatives like 'get_trending_markets' or 'list_active_markets', leaving the agent to infer based on the 'featured/promoted' focus.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that it returns 404 for inactive tokens, which is useful behavioral context. However, it doesn't cover other aspects like rate limits, authentication needs, or what the spread output looks like (e.g., numeric value, format). This leaves some gaps for a tool with no annotation support.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded with the core purpose. Every sentence adds value: the first states the action, the second provides source context, the third covers error behavior, and the fourth gives an example. It's efficient with minimal waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description is incomplete. It explains the input source and error case but doesn't describe the return value (e.g., spread format, units). For a tool with 1 parameter and moderate complexity, this is adequate but leaves the agent guessing about the output, which is a significant gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents the token_id parameter. The description adds value by explaining that token_id should come from clobTokenIds and provides an example (token_id=clobTokenIds[0]), which clarifies semantics beyond the schema. This justifies a score above the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool computes spread from CLOB/book best bid/ask, which is a specific verb+resource combination. It distinguishes from siblings like get_batch_spreads (batch operation) and get_midpoint (different metric), though not explicitly. However, it doesn't fully differentiate from get_order_book which might provide similar data, keeping it at 4.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides implied usage by mentioning source tokens from list_active_markets or get_market_details and noting 404 if no active CLOB. It doesn't explicitly state when to use this vs. alternatives like get_batch_spreads or get_order_book, nor does it provide exclusions, so it's adequate but with gaps.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and does well by disclosing key behavioral traits: it specifies the data source (CLOB/book depth), mentions the 404 error for inactive tokens, and provides an example token_id. It doesn't cover rate limits or authentication needs, but adds useful context beyond basic function.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized with three sentences that each add value: stating the purpose, providing context/sources, and giving an error condition with example. It's front-loaded with the core function, though the structure could be slightly more polished for readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool with no annotations and no output schema, the description is moderately complete. It covers purpose, usage context, and error behavior, but lacks details on return format (e.g., what liquidity metrics are computed) and doesn't fully compensate for the missing output schema, leaving gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents the token_id parameter. The description adds marginal value by providing an example (token_id=clobTokenIds[0]) and mentioning token sources, but doesn't explain parameter semantics beyond what's implied in the schema. Baseline 3 is appropriate given high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool computes liquidity from CLOB/book depth in USD, which is a specific verb+resource combination. However, it doesn't explicitly differentiate from sibling tools like 'get_order_book' or 'get_spread' that might also provide market data, leaving some ambiguity about uniqueness.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides implied usage by mentioning token sources (list_active_markets or get_market_details) and the 404 error condition for inactive tokens. However, it lacks explicit guidance on when to use this tool versus alternatives like 'get_order_book' for raw data or 'get_spread' for price differences, leaving the agent to infer context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states the tool is for getting metadata but doesn't disclose behavioral traits such as whether it's read-only, requires authentication, has rate limits, or what the output format looks like. The example 'no params' hints at simplicity but lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is highly concise and front-loaded: it states the purpose in the first phrase, provides usage guidance, and includes a helpful example, all in three short clauses with zero wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 0 parameters and no output schema, the description is minimally complete for a simple metadata retrieval tool. However, without annotations, it lacks details on behavior, permissions, or output structure, leaving gaps in understanding how to interpret results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description adds value by noting 'Example: no params,' which clarifies that no inputs are required, aligning with the schema. This compensates adequately for the lack of parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose as 'Get sports metadata (leagues, seasons, etc.)' which includes a specific verb ('Get') and resource ('sports metadata') with examples of what metadata includes. It doesn't explicitly differentiate from siblings like 'get_valid_sports_market_types' or 'list_teams', but the scope is reasonably clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance: 'Use with list_teams or sports market filters.' This gives clear context for when to apply this tool, though it doesn't specify when not to use it or name direct alternatives among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions that filtering is 'case-insensitive,' which is a useful behavioral detail not evident from the schema. However, it lacks information about permissions, rate limits, pagination, or what happens when no markets match the filter. For a read operation with no annotations, this leaves significant gaps in understanding the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and front-loaded: the first sentence states the core purpose, the second provides usage guidance, and the third gives an example. Every sentence earns its place with zero wasted words, making it easy for an AI agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
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, no annotations), the description is adequate but incomplete. It covers the basic purpose and usage but lacks details on behavioral aspects like error handling, response format, or performance characteristics. Without an output schema, the description should ideally hint at what the tool returns, but it doesn't, leaving gaps in contextual understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, meaning all parameters are well-documented in the schema itself. The description adds minimal value beyond the schema: it reiterates the 'category' parameter in the example and mentions 'active_only=true,' but doesn't provide additional semantic context. This meets the baseline of 3 since the schema does the heavy lifting, but the description doesn't compensate with extra insights.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Filter markets by tag/category slug (case-insensitive).' It specifies the verb ('filter'), resource ('markets'), and filtering criteria ('tag/category slug'), making the function unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'get_markets_by_tag' or 'search_markets,' which appears to offer similar filtering capabilities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for usage: 'Source: get_all_tags for slug list.' This indicates a prerequisite or alternative tool to obtain valid input values. It also includes an example ('Example: category=politics, active_only=true') that demonstrates typical parameter usage. However, it doesn't explicitly state when to use this tool versus alternatives like 'get_markets_by_tag' or 'search_markets,' which could lead to confusion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 market data with 'clobTokenIds for CLOB tools', adding useful behavioral context about the output. However, it lacks details on error handling, rate limits, or authentication needs, which are important for a read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded, with three concise sentences that each add value: stating the purpose, providing usage context, and giving an example. There is no wasted text, making it efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (1 parameter, no output schema, no annotations), the description is reasonably complete for a simple lookup tool. It covers purpose, usage, and output context, but lacks details on error cases or behavioral constraints, which could be beneficial despite the simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents the 'slug' parameter thoroughly. The description adds marginal value by providing an example ('slug=will-biden-win-2024') and mentioning the source of slugs, but doesn't significantly enhance the 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get') and resource ('detailed market info by slug'), making the purpose specific. However, it doesn't explicitly distinguish this tool from sibling tools like 'get_market_by_id' or 'get_market_details', which likely serve similar purposes but with different identifiers.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on when to use this tool by specifying the source of the slug ('from search_markets or list_markets'), which helps guide usage. However, it doesn't explicitly state when not to use it or name alternatives like 'get_market_by_id', leaving some ambiguity in sibling differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 results are sorted by volume and includes an example with parameters, adding some behavioral context. However, it doesn't cover important aspects like whether this is a read-only operation, pagination behavior beyond the offset parameter, rate limits, or error conditions. The description adds value but leaves significant gaps in behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured in two sentences: the first states the purpose and key usage context, and the second provides a concrete example. Every sentence adds value without redundancy, making it appropriately sized and front-loaded with essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (a list operation with sorting and pagination), no annotations, and no output schema, the description is moderately complete. It covers the purpose, usage context, and an example, but lacks details on output format, error handling, or behavioral traits like read-only status. For a tool with 3 parameters and many siblings, it should do more to be fully comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents the three parameters (limit, offset, order) with their types, defaults, and descriptions. The description adds minimal value beyond the schema by mentioning 'limit=20, order=volume24hr' as an example, but doesn't provide additional semantic context or usage nuances. This meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('List') and resource ('active markets'), and specifies the sorting criteria ('sorted by volume'). It distinguishes from some siblings like 'get_market_by_id' or 'list_events', but doesn't explicitly differentiate from 'list_markets' or 'filter_markets_by_category', which might have overlapping functionality. The purpose is specific but sibling differentiation is incomplete.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for usage by mentioning that results can be used for 'CLOB or Data API tools' with specific fields ('clobTokenIds/conditionId'), which helps guide when this tool is appropriate. However, it doesn't explicitly state when NOT to use it or name alternatives among the many sibling tools (e.g., 'list_markets' or 'filter_markets_by_category'), missing full alternative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and partially discloses behavior by specifying that it returns 'active markets sorted by endDate', but lacks details on permissions, rate limits, or error handling. It does not contradict any annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded, with a clear purpose statement followed by a concise example, containing no unnecessary information and earning its place efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (2 parameters, no output schema, no annotations), the description is mostly complete for a read operation, but could benefit from more behavioral context like pagination or data format details to fully compensate for the lack of annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents parameters. The description adds minimal value by providing an example that reinforces parameter usage but does not add meaning beyond what the schema already states.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verbs ('Get markets closing within specified hours') and resource ('markets'), and distinguishes it from siblings by focusing on closing timelines rather than general listing, filtering, or analysis.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context through the example ('Example: hours=24, limit=20'), suggesting when to use it for time-sensitive market queries, but does not explicitly state when to use this tool versus alternatives like 'list_active_markets' or 'filter_markets_by_category'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 key behavioral traits: the requirement for parent parameters to avoid a 422 error, and it gives an example. However, it doesn't cover other important aspects like rate limits, authentication needs, pagination behavior beyond the schema's default values, or what the output looks like. For a tool with 10 parameters and no annotations, this leaves gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded: it starts with the core purpose, then provides critical usage notes and an example. Every sentence adds value, such as explaining requirements and errors. It could be slightly more structured, but it's efficient with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (10 parameters, no annotations, no output schema), the description is partially complete. It covers the essential usage context and error avoidance, but lacks details on output format, pagination beyond defaults, or broader behavioral constraints. This is adequate for basic use but leaves room for improvement in a rich context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description adds minimal parameter semantics: it emphasizes the practical necessity of 'parent_entity_type' and 'parent_entity_id' with an example, but doesn't provide additional context for other parameters. This meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'List comments from Gamma API /comments.' It specifies the verb ('List') and resource ('comments'), making it easy to understand what the tool does. However, it doesn't explicitly differentiate from sibling tools like 'get_comment_by_id' or 'get_user_activity', which might also involve comments, so it doesn't reach the highest score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidelines: it states when to use this tool ('Requires parent_entity_type and parent_entity_id in practice') and offers alternatives ('use list_events/list_series/list_markets to get IDs'). It also warns about potential errors ('otherwise Gamma often returns 422'), which helps the agent avoid misuse. This is comprehensive guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses one important behavioral trait: 'Unknown address may return 404' which warns about potential error responses. However, it doesn't mention other behavioral aspects like rate limits, authentication requirements, response format, or whether this is a read-only operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly concise with two sentences that each earn their place: the first states the core purpose, the second provides important behavioral context and an example. No wasted words, well-structured and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter read operation with no output schema, the description is adequate but has gaps. It covers the basic purpose and one error case, but doesn't describe the response format, success cases, or other potential behaviors. With no annotations and no output schema, more completeness would be helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already fully documents the single 'address' parameter. The description adds minimal value beyond the schema by providing an example format ('0xabc....') but doesn't explain parameter semantics beyond what's in the schema description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verb ('Get') and resource ('user's public profile'), and specifies the lookup mechanism ('by Ethereum address'). It distinguishes itself from sibling tools which are focused on markets, trading, events, and other domains rather than user profiles.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool (to retrieve a public profile by Ethereum address) and includes an example. However, it doesn't explicitly state when NOT to use it or name specific alternatives among the sibling tools, which are all in different domains.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the HTTP method (GET) and return format (plain text OK), which are useful behavioral traits. However, it does not mention potential errors, rate limits, or authentication needs, leaving gaps in behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the purpose and includes essential details (method and return). There is no wasted text, and every part of the sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 parameters, no output schema, no annotations), the description is largely complete for a health check operation. It covers the action, method, and return. A minor gap is the lack of error handling or status code details, but this is acceptable for such a straightforward tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters with 100% schema description coverage, so no parameter information is needed. The description appropriately does not discuss parameters, earning a baseline score of 4 for not adding unnecessary details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Check Gamma API health'), method ('via GET /status'), and expected return ('Returns plain text OK'), distinguishing it from sibling tools like check_health_data_api. It uses precise verbs and resources without being tautological.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for health monitoring of the Gamma API, but does not explicitly state when to use it versus alternatives like check_health_data_api or other health-related tools. It provides basic context but lacks explicit guidance on exclusions or comparisons.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden and discloses key behavioral traits: it returns comprehensive market data, and livePrice may be null for closed or inactive CLOB tokens. However, it doesn't cover error conditions, rate limits, or authentication needs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences front-loaded with core functionality, zero waste. First sentence defines purpose and scope, second clarifies a key behavioral nuance (livePrice nullability).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only tool with no annotations and no output schema, the description is reasonably complete—it specifies what data is returned and a key behavioral nuance. However, it could better differentiate from siblings and mention response structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents the 'slug' parameter. The description adds no additional parameter semantics beyond implying token_id mapping, aligning with the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verb ('Get') and resource ('complete market information'), listing key data components (metadata, tokens, volume, liquidity, livePrice). It distinguishes from siblings like 'get_market_by_slug' by emphasizing comprehensiveness and the livePrice nuance.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving detailed market data by token_id, but lacks explicit guidance on when to choose this over alternatives like 'get_market_by_slug' or 'get_current_price'. No when-not scenarios or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 describes the tool as a 'Get' operation, implying it's a read-only function, which is consistent with typical 'get' tools. However, it lacks details on behavioral traits like rate limits, authentication needs, or response format. The example adds some context but doesn't fully compensate for the 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: two sentences that directly state the purpose and usage, with an example that clarifies application. Every sentence adds value without waste, making it easy to parse and understand quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 0 parameters, no annotations, and no output schema, the description does a decent job by explaining purpose and usage. However, it lacks details on what the output contains (e.g., structure of assets and chains) or any behavioral constraints, which could be important for an agent to use it effectively. It's adequate but has clear gaps in completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and schema description coverage is 100%, so there's no need for parameter documentation in the description. The baseline for this scenario is 4, as the description appropriately focuses on purpose and usage without redundant parameter info.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get bridge-supported assets and chains.' It specifies the verb ('Get') and resource ('bridge-supported assets and chains'), making it easy to understand what the tool does. However, it doesn't explicitly differentiate from sibling tools like 'get_bridge_quote' beyond mentioning it as a prerequisite, which keeps it from a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance: 'Use to fill get_bridge_quote params.' It clearly indicates when to use this tool (as a prerequisite for 'get_bridge_quote') and names the alternative tool, helping the agent understand the workflow and avoid misuse.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It clearly states this is a read operation ('Get'), specifies the return content ('event and associated markets'), and provides a concrete example. However, it doesn't mention error conditions, rate limits, authentication requirements, or whether the operation is idempotent. The behavioral disclosure is adequate but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise yet information-dense. The first sentence states the core purpose, the second provides context about slug sources, and the third gives a concrete example. Every sentence earns its place with no wasted words, and the information is front-loaded appropriately.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter read operation with no output schema, the description provides good context: purpose, usage guidance, return content, and an example. It doesn't describe the structure of returned events/markets or error responses, but given the tool's simplicity and the lack of annotations, this is reasonably complete. The main gap is the absence of output format details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already fully documents the single 'slug' parameter. The description adds minimal value beyond the schema by providing an example slug format ('presidential-election-2024') and mentioning where slugs can be obtained. This meets the baseline expectation when schema coverage is high.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Get event details'), target resource ('event and associated markets'), and method ('by slug'). It distinguishes from sibling tools like get_event_by_id by specifying the slug-based lookup approach, and mentions alternative sources for obtaining slugs (search_markets or list_events).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool ('by slug') and provides two specific alternative sources for obtaining slugs (search_markets or list_events). It also distinguishes from get_event_by_id by specifying the slug-based approach, though it doesn't explicitly say when not to use it. The example further clarifies usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and adds valuable behavioral context: it specifies the API endpoint ('via CLOB /book'), error handling ('If token has no active order book, returns 404'), and data source constraints. This goes beyond the basic schema to inform the agent about operational behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is highly concise and front-loaded, with every sentence earning its place: it states the purpose, source, error condition, and example in three efficient sentences without redundancy or unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (single parameter, no output schema, no annotations), the description is nearly complete: it covers purpose, usage, behavior, and an example. However, it lacks details on return format (e.g., structure of order book data) which could aid the agent, slightly reducing completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents the token_id parameter. The description adds minimal semantics by referencing token_id in context and providing an example, but does not elaborate on format or constraints beyond what the schema implies. Baseline 3 is appropriate as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Get order book'), resource ('via CLOB /book'), and target ('for token_id'), distinguishing it from siblings like get_batch_order_books (batch processing) or get_current_price (price only). It precisely defines the tool's function without ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on when to use it by specifying the source for token_id ('clobTokenIds from list_active_markets or get_market_details') and an example. However, it does not explicitly state when not to use it or name alternatives like get_batch_order_books for multiple tokens, leaving some guidance implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and discloses key behavioral traits: it specifies the data source (CLOB), return values (bid/ask/mid), error condition (404 if no active CLOB), and example usage. However, it lacks details on rate limits, authentication needs, or response format structure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured with three sentences: purpose statement, source/error conditions, and example. Every sentence adds essential information without redundancy, making it front-loaded and appropriately sized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description provides good context for a read-only price-fetching tool by covering purpose, usage, parameters, and error handling. However, it doesn't fully describe the return value format (e.g., structure of bid/ask/mid) or potential edge cases beyond the 404 error.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, providing full parameter documentation. The description adds minimal value beyond the schema by implying token_id should come from specific sources (list_active_markets or get_market_details) and giving an example, but doesn't explain parameter interactions or semantics further.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Get CLOB /price for BUY/SELL and return bid/ask/mid') and resource (price data for a token), distinguishing it from siblings like get_batch_prices, get_market_details, or get_order_book by focusing on current price retrieval from a CLOB with bid/ask/mid outputs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly provides when to use this tool ('Source: clobTokenIds from list_active_markets or get_market_details') and when not to ('If token has no active CLOB/order book, returns 404'), with clear alternatives named (list_active_markets, get_market_details) for obtaining valid token IDs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes key behavioral traits: it retrieves status information (implying read-only), explains the meaning of 'connected=false' (offline state), and clarifies that subscriptions can exist but won't receive events until connected. This adds valuable context beyond what a simple 'get' implies, though it could mention response format or error handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured in two sentences: the first states the purpose and key details, and the second explains critical behavioral nuances (connection state implications). Every sentence adds essential value without redundancy, making it front-loaded and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (monitoring WebSocket subscriptions), no annotations, and no output schema, the description is largely complete. It covers what the tool does, key status elements, and important behavioral notes. However, it could be enhanced by mentioning the return format or example output to fully compensate for the lack of structured output documentation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately does not discuss parameters, maintaining focus on the tool's purpose and behavior. This aligns with the baseline expectation for tools without parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific verb ('Get') and resource ('status of WebSocket subscriptions'), detailing exactly what information is retrieved (active topics, connection state, stats, recent messages). It distinguishes from siblings by focusing on WebSocket subscription status rather than market data, orders, or other real-time operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool: to check WebSocket subscription status, including connection state and subscription details. It implies usage by explaining that 'connected=false means offline' and subscriptions won't receive events until connected. However, it does not explicitly state when not to use it or name alternatives among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![polymarket-mcp MCP server](https://glama.ai/mcp/servers/traderalvin1/polymarket-mcp/badges/card.svg)](https://glama.ai/mcp/servers/traderalvin1/polymarket-mcp)

Score Badge

Copy to your README.md:

[![polymarket-mcp MCP server](https://glama.ai/mcp/servers/traderalvin1/polymarket-mcp/badges/score.svg)](https://glama.ai/mcp/servers/traderalvin1/polymarket-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/traderalvin1/polymarket-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server