graph-polymarket-mcp
Server Quality Checklist
Latest release: v2.0.0
- Disambiguation3/5
Several tools have overlapping purposes (e.g., get_market_data vs get_market_info, search_markets vs search_markets_enriched, and the multiple live CLOB tools). Descriptions help differentiate them, but misselection is still possible.
Naming Consistency4/5Most tools follow a get_ prefix with snake_case (e.g., get_market_resolution, get_live_orderbook), but a few use search_, list_, or query_, and search_markets_enriched adds an inconsistent suffix. The pattern is mostly consistent but has deviations.
Tool Count2/532 tools is excessive for a single server. Many tools are excessively granular (e.g., get_live_prices, get_live_spread, get_live_orderbook, get_last_trade could be one tool with parameters), making the surface feel bloated.
Completeness4/5The server covers the main needs of Polymarket data consumers: market discovery, live order book, trader analytics, resolution status, and platform stats. Minor gaps exist (e.g., per-trader trade history), but the core is solid.
Average 3.8/5 across 32 of 32 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 2 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
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.
This repository includes a glama.json configuration file.
If you are the author, simply .
If the server belongs to an organization, first add
glama.jsonto 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, the description carries the full burden but only adds the meaning of open interest and subgraph uniqueness. It does not disclose ordering defaults, limits, return format, or any other behavioral traits. This is minimal disclosure for a query 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences. The first gives the core purpose; the second adds relevant uniqueness context without waste. Every phrase earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description should explain what is returned, but it does not mention the result structure or fields. It also lacks guidance on how to use the parameters in context. The moderate complexity and optional params are only partially addressed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, including defaults (first=10, orderBy=amount, orderDirection=desc) and valid enums. The description adds no parameter-specific information, but the schema is sufficient, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Get the top Polymarket markets ranked by open interest' with a definition of OI. It is specific in verb and resource, though it does not explicitly contrast with sibling tools like get_global_open_interest or get_oi_history, so it falls just short of a 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as get_global_open_interest for aggregate OI or get_oi_history for historical trends. The only contextual note is about subgraph uniqueness, which does not help an agent choose between related OI tools.
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 fully disclose behavior. It mentions the data source ('Uses the Gamma API') but does not disclose read-only semantics, default filtering behavior (e.g., whether only active events are returned), pagination, or response format. The concept of events bundling markets is useful context but not a 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with three short sentences, front-loading the action. The final sentence 'Uses the Gamma API' adds little value for selection and invocation, slightly detracting from conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the purpose is clear and the schema is comprehensive, the description lacks information about the response format (no output schema), default behaviors, and alternatives to sibling tools. This leaves some gaps for an agent trying to correctly invoke and interpret results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides detailed descriptions for all 6 parameters including defaults, ranges, and enums (100% schema coverage). The tool description adds no additional parameter semantics beyond the schema, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb ('List') and resource ('Polymarket events'), and clarifies that events are groups of related markets with a concrete example. However, it does not explicitly distinguish this from the sibling tool 'search_polymarket_events', so it lacks explicit 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used for listing all Polymarket events, but it provides no explicit guidance on when to use it versus searching/filtering via siblings like 'search_polymarket_events', and no exclusions are stated. Usage is only implied by the verb 'List'.
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 disclosing behavioral traits, but it only states 'execute a custom GraphQL query' without mentioning potential risks (e.g., expensive queries, large responses), rate limits, authentication, or return format. The power and arbitrary nature of GraphQL queries warrant more 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the action ('Execute') and resource ('custom GraphQL query against a Polymarket subgraph'). It is concise and contains no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the tool's complexity (arbitrary GraphQL queries, multiple subgraphs, optional variables), there is no output schema, and the description does not explain the return format, query execution behavior, or recommended subgraph selection. This leaves the agent underinformed about important runtime details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all parameters are documented at a basic level. The tool description adds no additional semantic meaning beyond the schema. However, the subgraph parameter's schema description is incomplete (lists only 5 of 8 enum values), but this is not the tool description's fault; the description does not compensate either.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Execute a custom GraphQL query against a Polymarket subgraph' clearly identifies the tool as a generic query executor, using a specific verb ('execute'), resource ('Polymarket subgraph'), and distinguishing 'custom GraphQL query' from the feature-specific sibling tools like get_market_data or get_account_pnl.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 the many sibling getters. It does not mention that this should be used as a flexible fallback when specific endpoints are insufficient, or that specific getters should be preferred for standard data retrieval.
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 must carry the full burden. It discloses that this is a data-retrieval operation from the Main subgraph and that results include outcomes and volumes, but it does not describe pagination behavior, return shape, or any auth/rate-limit considerations. This is adequate for a simple read tool but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler, front-loads the verb and resource, and is appropriately sized for a simple query tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (three optional parameters, no nested objects), and the description covers the basic resource and source. However, with no output schema and no annotations, the description could be more explicit about return shape and filtering/sorting behavior beyond what the schema names imply, and it lacks sibling differentiation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All three parameters are fully documented in the schema with descriptions and defaults, so the schema already covers parameter semantics. The description adds no extra detail about how first/orderBy/orderDirection behave.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Get' and names the resource 'Polymarket market/condition data' with content ('outcomes and volumes') and source ('Main subgraph'). It is clear what the tool does but does not explicitly distinguish it from similarly named siblings such as get_market_info or query_subgraph.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool instead of alternatives. It does not mention use cases that map to query_subgraph, get_market_info, or search_markets, nor does it provide any exclusions or prerequisites.
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 mentions the return includes holders and P&L, but it doesn't disclose sorting defaults, pagination behavior via the 'first' parameter, or any other behavioral traits like authentication requirements or data freshness. This is a significant gap for a tool with no annotation safety hints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences, front-loaded with the action and followed by a brief return summary. No filler or redundant phrasing; every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there is no output schema, the description provides a high-level statement about returning top holders and their P&L, but it lacks details on how the results are ordered, pagination limits, and how positions are defined. For a simple read-only query with a well-described schema, this is adequate 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/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% coverage of parameter descriptions, including detailed semantics for tokenId and enums for orderBy. The description adds minimal extra meaning by saying 'top positions,' which hints at ordering, but this is already captured by the orderBy parameter with its default valueBought. Thus, the description's added value is marginal.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it gets the top positions for a specific market token from the Beefy P&L subgraph and shows who holds the largest positions with their P&L. This specifies the verb and resource, and the mention of 'top positions' distinguishes it from per-user position tools, though it doesn't explicitly name sibling alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The usage context is implied: use this tool when you need the largest positions and their P&L for a particular market token. However, there is no explicit guidance on when not to use it or which alternative tools might be preferable, such as get_user_positions or get_top_traders.
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, the description carries the full burden of behavioral disclosure. It uses the verb 'Get' which implies a read-only operation, but does not explicitly state safety or side effects. It also does not clarify what 'recent' means, whether results are sorted, or any rate limits or auth requirements, leaving significant behavioral ambiguity for a tool with no annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that conveys the core purpose without wasted words. It is concise and well-structured, earning a top score for efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (3 optional params, no output schema, no annotations), the description is minimally adequate but incomplete. It fails to mention return format, ordering, or how 'recent' is determined. The lack of any behavioral context, especially given the many sibling tools, leaves gaps that could lead to incorrect selection or invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with each parameter ('first', 'maker', 'taker') individually described in the input schema. The description itself adds no additional parameter information, but since the schema fully documents parameters, 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.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get recent order fills from the Orderbook subgraph' clearly states a specific verb ('Get'), a specific resource ('recent order fills'), and the source ('Orderbook subgraph'). This distinguishes it from sibling tools like query_subgraph (generic) and get_live_orderbook (real-time order book, not trades), making its purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 such as query_subgraph, get_recent_activity, or get_last_trade. There is no mention of appropriate use cases, exclusions, or trade-offs, leaving the agent to infer from the name and 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 must carry the full burden. It does not disclose read-only nature, output format, pagination behavior, or any time-bound definition of 'recent'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single 11-word sentence that is front-loaded with the verb and leaves out all extraneous detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the schema covers parameters and the purpose is clear, the lack of annotations and the absence of any mention of output structure or temporal boundaries leaves some contextual gaps for a complete understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents both parameters with descriptions (100% coverage). The description adds no additional meaning about the parameters, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Get' with a precise resource ('Activity subgraph') and enumerates the specific event types (splits, merges, redemptions), clearly distinguishing it from the broader sibling tools like query_subgraph.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool versus alternatives. It doesn't mention that it complements query_subgraph or that account filtering is possible via parameters.
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 disclosing behavioral traits. It mentions 'full schema' indicating a complete introspection response, but does not disclose read-only nature, potential response size, error handling, or any prerequisites. This is minimal 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the action and resource with no redundant or filler words. It is appropriately sized for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one parameter and no output schema. The description adequately states the purpose but lacks details about the response format or how to select a subgraph. Given the minimal complexity, it is sufficient but not comprehensive, leaving some gaps for an agent to fill.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides an enum for the 'subgraph' parameter with 100% coverage, so the baseline is 3. The tool description adds no additional parameter semantics. However, the schema's description lists only five of the eight enum values, which could be misleading, but that is a schema issue rather than the tool description's responsibility.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action ('get'), the resource ('full GraphQL schema (introspection)'), and the scope ('for a Polymarket subgraph'). It distinguishes this tool from siblings like query_subgraph, which executes queries, and list_subgraphs, which lists available subgraphs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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, no prerequisites, and no exclusions. It only states what it does, leaving the agent to infer usage 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, and the description does not disclose operational behaviors such as return format, pagination, or safety characteristics. It only adds conceptual context about disputes, leaving the agent without critical behavioral 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded, with no waste. The second sentence provides useful context without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description sufficiently explains the tool's purpose and the meaning of disputed markets. With a single optional parameter documented in the schema, the description is adequate for invocation, though it lacks details about the response structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema fully documents the 'first' parameter with description, default, and bounds. The description adds no additional parameter semantics, so the baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves disputed Polymarket markets with a specific verb and resource. It adds context about what disputes are but does not explicitly differentiate from sibling tools like get_market_resolution.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is useful for finding high-signal events, but provides no explicit guidance on when to use it versus alternatives or any exclusions. Usage context is implied rather than 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 only states that it retrieves P&L data from a subgraph, without mentioning data freshness, output format, potential latency, or any prerequisites. It does not disclose anything beyond the basic read operation, which is a significant gap given the lack of 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one concise sentence that is front-loaded with the action verb. Every word earns its place, and there is no redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with a single parameter and no output schema. The description names the return content ('P&L and performance metrics') but does not specify the exact structure, fields, or response format. Since there is no output schema to rely on, the description could be more explicit about the shape of the return value, but it covers the essential purpose.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage for the single parameter ('account' with description 'Ethereum address of the trader (lowercase)'). The tool description adds no additional meaning to the parameter beyond what the schema already provides, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('Get') and resource ('a trader's P&L and performance metrics'), and identifies the data source ('Beefy P&L subgraph'). It distinguishes from sibling tools like get_trader_profile and get_trader_usdc_flows by focusing on P&L metrics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool (when P&L/performance metrics are needed from the subgraph) but provides no explicit exclusions or comparisons to alternatives. Given the large list of sibling tools, the absence of explicit 'when not to use' or alternative recommendations leaves the agent to infer usage context.
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 the full burden. It discloses a useful behavioral detail: 'Falls back gracefully if indexers are behind.' However, it does not explain what 'falls back' means in terms of data freshness or return format, leaving some opacity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences, front-loaded with the primary action. Every word adds value, including the fallback note. No wasted space.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given 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), the description is fairly complete as a retrieval operation. It states what is returned and the data source. However, it could clarify the structure of positions (e.g., fields like size, entry price), but this is not critical for a basic read.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does 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 no additional parameter meaning beyond the schema, which already specifies 'Ethereum address of the user (lowercase)'. No extra syntax or format details are provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool fetches a user's current positions, specifying the data source (Slimmed P&L subgraph). This directly distinguishes it from user PnL or market-specific position tools, giving a specific verb, resource, and scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description mentions fallback behavior but does not contrast with sibling tools like get_account_pnl or get_market_positions. There are no usage criteria 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, and the description does not disclose behavioral traits such as read-only nature, authentication requirements, rate limits, or pagination. It only describes the content of the listing, not side effects or constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no unnecessary words. It efficiently states the action and the resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with no parameters, the description adequately specifies what is listed and what fields are included. However, it does not mention the return format (e.g., array, pagination), which would be helpful given no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the empty schema is fully covered. The description adds context about the output containing descriptions and key entities, which is useful but not parameter-related. Baseline 4 for zero-parameter tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists all available Polymarket subgraphs, including descriptions and key entities. It distinguishes from sibling tools like query_subgraph (which queries) and get_subgraph_schema (which retrieves schema) by focusing on enumeration.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. It does not mention that this is the discovery step before querying a specific subgraph or any prerequisites for using the results.
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 clearly states what data is shown (initialized/proposed/disputed/resolved status, proposed/final prices, dispute history), but it does not disclose any additional behavioral traits such as pagination, default ordering, or response structure. It is not misleading, but lacks richness beyond the basic 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no fluff. It front-loads the verb and resource, then lists the key output types in a compact list. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 4 optional parameters, no output schema, and no annotations. The description covers the main purpose and some return values, but it does not explain the return structure, pagination behavior, or how the response is organized. Given the absence of an output schema, more detail would be helpful for an agent to know what to expect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description does not add extra meaning beyond the schema's parameter descriptions. It mentions statuses but does not clarify how parameters like 'first' or 'orderBy' affect the result beyond what the schema already documents.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Get' and identifies the precise resource: 'UMA oracle resolution status for Polymarket markets.' It distinguishes itself from siblings like get_market_data by focusing on resolution status, prices, and dispute history. The scope is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool (when you need UMA oracle resolution status), but it does not explicitly mention alternatives or exclusions. It does not differentiate itself from similar tools like get_disputed_markets or get_market_revisions, leaving the agent to infer the appropriate context from the name and description alone.
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 present, so the description carries the full burden. It discloses the ranking criteria and data source, implying a read operation. However, it does not specify sort order (ascending/descending), pagination behavior, or how the 'first' and 'minTrades' parameters affect results beyond their schema descriptions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence with no redundant content. It front-loads the core purpose and names the data source, achieving excellent conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is straightforward and its parameters are well-documented, but the lack of an output schema means the return format is undisclosed. It also does not mention sort direction or offer any comparison to sibling tools, leaving some context gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with each parameter (first, orderBy, minTrades) having its own description. The tool description adds no extra parameter context beyond the schema, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') with a distinct resource ('top Polymarket traders ranked by realized P&L, win rate, or volume') and names an explicit data source ('Beefy P&L subgraph'). This clearly differentiates it from sibling tools like get_trader_profile or get_account_pnl that target individual traders.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for fetching leaderboard-style data but provides no explicit when-to-use guidance or alternative tools. It only states what it does, not when to prefer it over siblings like get_trader_profile or query_subgraph.
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 data source (CLOB) and the operation (get last trade price), but does not detail return format, error behavior, permissions, or rate limits. For a simple read operation, this 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the action and includes the key source. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool with no output schema, the description adequately explains the purpose and source. However, it could be improved by noting the price format (e.g., USDC) or typical edge cases (e.g., no trades yet), so it's not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema describes tokenId as 'CLOB token ID' with 100% coverage. The description adds no additional parameter semantics beyond referencing the CLOB source, which is already in the schema. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Get' with a clear resource: the last trade price for a Polymarket outcome token from the CLOB. It unambiguously distinguishes from siblings like get_price_history or get_live_prices by focusing on 'last trade price'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used when needing the last trade price, but does not provide explicit guidance on when to use this vs alternatives like get_live_prices or get_orderbook_trades. No exclusions or alternative recommendations 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?
With no annotations provided, the description carries the full burden. It discloses the general behavior (showing when and how moderators intervened) but does not mention pagination, rate limits, or any side effects. Since this is a read-only tool, the lack of side-effect disclosure is less critical, but the description doesn't fully detail the return 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is succinct and front-loaded: two short sentences that immediately state the action and scope. Every word contributes meaning, with no waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list retrieval tool with two optional parameters and no output schema, the description is adequately complete. It clearly explains what the tool returns and its focus on moderator intervention. It does not describe the exact response format, but the tool's low complexity makes this acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for both parameters ('first' and 'questionId'), so the description does not need to add parameter details. The description provides context about the market revisions but does not elaborate on parameter usage, matching the baseline for full schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Get moderator revisions/updates for Polymarket markets' and elaborates on the content: 'Shows when and how moderators intervened in market resolution.' This specific verb+resource pairing distinguishes it from sibling tools like get_market_resolution and get_market_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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear context of what the tool does, implying it should be used when there is a need to see moderator interventions. However, it does not explicitly state when not to use it or mention alternatives, so the usage guidance remains implicit.
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 that the tool returns time-series price points, but does not explain the response format, ordering, pagination, or any potential limitations (e.g., date range restrictions). This is adequate but lacks richer behavioral detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, tightly focused sentence that is front-loaded with the key action and resource. It is free of redundancy or irrelevant detail, exemplifying concise structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has moderate complexity (3 parameters, no output schema) and no annotations. The description states the return type (time-series price points) but not its structure (e.g., array of {timestamp, price}), which is a meaningful gap given the lack of an output schema. It is sufficient for basic understanding but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the input schema fully documents all three parameters. The description does not add additional meaning beyond what the schema already provides, meriting the baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and resource ('historical price data for a Polymarket outcome token'), clearly distinguishing it from related tools like get_live_prices. It also specifies the intended use case (charting and trend analysis), making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states 'for charting and trend analysis,' giving clear context for when to use the tool. However, it does not explicitly mention alternatives (e.g., 'use get_live_prices for current prices') or exclusions, so it falls short of a 5.
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 states the tool 'Shows inbound and outbound USDC transfers,' which is useful, but it does not disclose return format, pagination behavior, or whether only confirmed transfers are included. This adds some context but leaves important behavioral traits unaddressed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary action, and contains zero fluff. Every word contributes to understanding the tool's purpose and use case.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description should explain what is returned. It gives a high-level view ('Shows inbound and outbound USDC transfers') but does not describe the individual fields (e.g., amount, timestamp, transaction hash) or any default time range. This is a moderate gap for a tool with no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (all three parameters have descriptions), so the baseline is 3. The description's mention of 'deposit/withdrawal' and 'inbound/outbound' loosely aligns with the direction parameter but does not add any semantic detail beyond what the schema already specifies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get USDC deposit/withdrawal history for a trader' with a specific verb and resource. It distinguishes itself from sibling tools like get_trader_profile and get_user_positions by focusing on USDC flows, making the tool's purpose immediately identifiable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context with 'useful for tracking when traders fund or withdraw from Polymarket.' However, it does not explicitly name alternative tools or mention when not to use this tool, so it lacks the explicit exclusions that would earn a 5.
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 present, so the description carries the full burden. It explains the multi-API enrichment behavior and notes the limit is 'kept small for enrichment speed,' implying performance trade-offs. However, it doesn't disclose what happens when results are empty, how errors are handled, or the structure of the enriched output, leaving some gaps for a complex 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the key purpose ('Power tool'), and every clause adds value. It wastes no words and is easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (combining three APIs) and the absence of an output schema, the description could explain more about the enriched result format. It does mention 'live CLOB prices' and 'on-chain resolution status,' but doesn't clarify how these appear in the response or whether pagination/limits affect enrichment depth. This is adequate but incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does 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 (query, limit, active, closed). The description adds one extra insight about the limit parameter ('kept small for enrichment speed'), but for other parameters it repeats no new meaning. 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.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description opens with 'Power tool: search Polymarket markets then auto-enrich each result with live CLOB prices and on-chain resolution status.' This clearly identifies the verb (search+enrich), resource (Polymarket markets), and the unique combined behavior that distinguishes it from sibling tools like search_markets or get_live_prices.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Combines Gamma API + CLOB API + The Graph in one call — no need to chain tools manually' provides clear context for when to use this tool: when you want both search results and enrichment in a single call, avoiding manual chaining. It doesn't explicitly state when not to use it, but the implied use case is strong.
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 data source (Beefy P&L subgraph) and the metrics returned, adding some behavioral context. However, it does not address data ordering, freshness, pagination, or explicitly confirm it is a read-only operation, which would enhance transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences: the first states what the tool retrieves, the second states its intended use. No filler or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one optional parameter, the description covers the purpose, data source, included metrics, and a usage scenario. It lacks an explicit return format or sort order, but given the simplicity and the listed metrics, it is sufficiently complete for selection and basic invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with the single 'days' parameter fully described ('Number of recent days to return (1-90)'). The tool description adds no additional parameter semantics, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves daily platform statistics from the Beefy P&L subgraph, listing specific metrics (volume, fees, trader counts, market activity). This distinguishes it from sibling tools like get_global_stats, which likely returns aggregated totals rather than daily breakdowns.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly recommends using this tool for trend analysis and historical performance, providing clear context. However, it does not name alternatives or explicitly state when not to use it, stopping short of a full when/when-not comparison.
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 responsibility. It discloses that the tool returns all resting limit orders with prices and sizes and indicates real-time data. However, it does not clarify whether this is a one-time snapshot or a stream, nor does it mention response structure, rate limits, or authentication needs. Some useful context is present, but gaps remain.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loaded with the primary action and resource, with no wasted words. Each clause adds value: 'full real-time', 'bids and asks', 'CLOB', 'all resting limit orders with prices and sizes'. Excellent conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool without an output schema, the description adequately conveys what is returned (order book, resting orders, prices, sizes) and the domain (Polymarket CLOB). It lacks details on order book depth, bid/ask structure, or whether the response is paginated, but overall it is sufficiently complete for this complexity level.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already covers the only parameter with 'CLOB token ID', achieving 100% coverage. The description adds that the token is for a Polymarket outcome token, which slightly clarifies context, but it does not add deeper meaning like format, validation, or how to obtain the token ID. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves the full real-time order book (bids and asks) for a Polymarket outcome token from the CLOB. It specifies the resource (order book), scope (bids/asks, all resting limit orders, prices and sizes), and differentiates it from sibling tools like get_orderbook_trades or get_live_prices.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when one needs a complete order book view, and the mention of 'full real-time' and 'all resting limit orders' gives context against price/spread tools. However, it does not explicitly name alternatives or exclusion criteria, so it does not fully reach the 'explicit when/when-not' level.
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 full burden. It states the tool returns the current best price and is real-time, but it does not disclose the return format, potential edge cases (e.g., inactive markets, zero liquidity), or rate limits. The read-only nature is implied by 'Get' but not explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences plus a separate token-ID source line, front-loaded with the main purpose. No filler or redundant restatement of the name; every sentence adds information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 2-parameter tool with no output schema, the description covers the core purpose and token sourcing. It does not explicitly contrast with siblings, but the purpose clarity already differentiates it. The mention of 'current best price' gives a reasonable hint of the return value.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for both parameters, but the description adds a third source for token IDs ('token_id in get_clob_market') not included in the schema's description. The 'side' parameter meaning is already fully captured in the schema, so the description only adds marginal value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets real-time CLOB prices for Polymarket outcome tokens and returns the current best buy/sell price. This specific verb+resource phrasing distinguishes it from siblings like get_live_spread (spread), get_price_history (history), and get_live_orderbook (orderbook).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied: use this for current real-time prices. The description tells you where to obtain token IDs, but it does not explicitly say when to prefer this over alternatives or mention any exclusions. No direct comparison to similar quotes tools.
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 the full burden of disclosure. It provides actionable context: the data source (Traders subgraph), the exact data points (first appeared, CTF event types, USDC flows), and the ability to limit events via eventLimit. It does not elaborate on read-only behavior or error cases, but for a get operation, this is reasonably transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that lists the tool's purpose and key data components without redundancy. It is front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with only two parameters and no output schema, the description adequately captures the main functionality and returned data categories. It could mention return structure or caveats, but the simplicity of the operation does not demand it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides comprehensive descriptions for both parameters (address and eventLimit), covering 100% of the schema. The description does not add additional parameter-level insight, so a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource: a trader's on-chain profile from the Traders subgraph. It enumerates specific contents (first appearance, recent CTF events, USDC flows), which distinguishes it from siblings like get_trader_usdc_flows or get_recent_activity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies a use case—obtaining a consolidated trader profile—but does not explicitly state when to prefer this tool over alternatives. It mentions the data source (Traders subgraph) but lacks explicit exclusions or alternative tool names.
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 adds meaningful context by noting the Gamma API source and listing the return fields, plus hints at chaining for deeper data. It lacks details on rate limits, pagination defaults, or error behavior, but for a search tool this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three concise sentences: the first defines the action, the second lists outputs, and the third gives chaining suggestions. It is front-loaded, avoids redundancy, and every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a search tool with no output schema, the description adequately covers return values and provides integration guidance. It could be more complete by stating the exact response structure or default filters, but given the simplicity of the tool, it is sufficiently complete for an agent to select and use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so each parameter is already well-documented. The description adds minimal parameter-specific semantics beyond what the schema states; it merely restates that the query is text search and that CLOB token IDs are included in results, which is useful but not sufficient to exceed the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches Polymarket prediction markets via text query and lists the returned metadata (question, prices, volume, liquidity, CLOB token IDs). However, it does not differentiate this tool from the sibling search_markets_enriched, which likely serves a similar but possibly more detailed purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear usage context by suggesting chaining with other tools like get_clob_market and get_live_prices, implying this is the initial discovery step. It does not explicitly exclude alternatives or state when not to use this tool, 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.
- 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. It discloses the output structure (token_id, live prices, min order/tick sizes, market status) and the tool's role as a data bridge. This goes beyond a minimal read-only statement and gives concrete expectations about the returned data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loaded with the primary action in the first sentence, followed by return details and usage guidance. Every sentence serves a distinct purpose with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (one parameter, no output schema), the description is sufficiently complete. It lists return fields, explains the tool's integration role, and names related tools for follow-up actions. It could mention response structure (e.g., array vs object) but that is not essential for a simple getter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already covers the sole parameter with a description ('Market condition ID (hex string)') at 100% coverage. The description adds contextual meaning by calling it 'on-chain condition ID' and explaining the bridge role, but it does not add syntax or format details beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get'), identifies the resource ('CLOB market details'), and scopes it by 'condition ID'. It clearly distinguishes itself from sibling tools by focusing on the bridge between on-chain condition IDs and CLOB token IDs, which is unique among the listed siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool ('This is the bridge between on-chain condition IDs and CLOB trading data') and provides explicit next-step guidance ('Use the returned token_id values with get_live_prices, ...'). It does not explicitly mention when not to use it, but the bridge metaphor and chaining instructions give clear usage context.
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 that the tool returns 'best bid, best ask, and spread' and labels the data as 'real-time'. It does not mention potential side effects, rate limits, or whether the token ID must be an outcome token, but for a simple getter this is acceptable. More detail on data latency or error handling would improve it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loaded with the primary action, and every word adds value. It states what it does, what it returns, and why it's useful—no filler, no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter getter with no output schema, the description provides adequate information: the purpose, the return value (best bid, best ask, spread), and a use case. It doesn't cover potential edge cases like illiquid markets or update frequency, but given the tool's simplicity, this is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides 100% coverage for the single parameter tokenId with description 'CLOB token ID'. The tool description adds semantic value by explaining that the token is a 'Polymarket outcome token' and contextualizing the parameter's role in retrieving a spread, which goes slightly beyond the schema's bare description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Get' and identifies the exact resource: 'real-time bid-ask spread for a Polymarket outcome token'. It clearly distinguishes itself from siblings like get_live_prices (which would give prices) and get_live_orderbook (which gives full order book) by focusing specifically on the spread.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context by stating it is 'useful for assessing market liquidity and trading costs', giving the agent a sense of when to invoke it. However, it does not explicitly mention alternatives or exclusions such as 'use get_live_orderbook for full depth' or 'use get_live_prices for midprice', so it stops short of a full 5.
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 burden. It discloses the hourly cadence, the market-specific scope, and the time-series nature. It implicitly indicates a read-only operation ('Get') but does not explicitly state safety, permissions, or return behavior beyond 'snapshots.'
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, each earning its place. It front-loads the core purpose, adds a use case, and provides a parameter hint. No fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (3 params, no output schema), the description covers the essential purpose and usage. It could be more explicit about the exact return fields, but 'hourly open interest snapshots' already implies the structure. The schema fills in parameter details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds value by telling the user how to obtain conditionId (from get_market_open_interest or the main subgraph), which enriches the required parameter's meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with 'Get hourly open interest snapshots for a specific Polymarket market,' which clearly states the verb and resource. It distinguishes itself from siblings like get_market_open_interest (current OI) by emphasizing 'hourly' and 'over time,' and from query_subgraph by being a dedicated endpoint.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly says 'Use this to chart OI trends over time,' providing a clear use case. It also mentions that conditionId can be obtained from get_market_open_interest, which helps navigate the workflow. However, it does not explicitly say when not to use it or name alternatives.
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 fully carries the transparency burden. It discloses the core behavior (fetching a single event and all its markets) and explains the event's structure. While it doesn't mention edge cases or response details, it's sufficiently transparent for a simple 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences with the key action front-loaded. Every word adds value, with no redundancy or filler. It achieves maximum clarity in minimal space.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description explains what an event is and that the tool returns all associated markets, which is sufficient for a single-parameter retrieval tool. It lacks an explicit return value list, but no output schema exists, so the description carries this responsibility adequately. Minor omission: doesn't mention that 'eventId' can be a slug, but that's in the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of parameter semantics with a description for 'eventId' ('Event ID or slug'). The tool description adds no parameter-specific information, but the schema already provides the needed meaning, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and resource ('Polymarket event') and clearly states it returns all associated markets. This distinguishes it from sibling tools like list_polymarket_events and search_polymarket_events, which operate at the collection level.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: call this when you have a specific event ID or slug and need all related markets. It clarifies the event concept, giving context for choosing this over list/search. However, it doesn't explicitly state when not to use it or name alternatives.
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. It clearly states the search behavior and return content (sub-markets + live prices), making the tool's effects transparent. It does not mention rate limits or auth, but for a read-only search tool, the disclosure is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: the first states the core function and output, the second gives a concrete use case. Front-loaded and free of any filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the tool's main purpose, expected output, and provides a use-case example. The schema fully documents parameters. No output schema exists, but the description indicates return content. For a simple search tool, it is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and every parameter already has a descriptive explanation. The description adds only a minor example for the query parameter, which is already covered in the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific verbs and resources: 'Search Polymarket events' and specifies output ('sub-markets + live prices'). It distinguishes itself from sibling tools like search_markets and list_polymarket_events by focusing on events and providing an example use case.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Best for finding sports match markets' and gives an example query, which provides clear context for when to use it. However, it does not mention alternatives or exclusions, so it stops short of a 5.
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 the full burden. It discloses exactly what is returned: aggregate USDC locked in outstanding positions platform-wide. This adds semantic clarity beyond the tool name, though it doesn't discuss potential limitations or frequency of updates.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the key information ('total open interest') and adds a clarifying detail ('USDC locked in outstanding positions'). No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (zero params, no output schema), the description sufficiently answers what the tool does and what the returned value means. It even specifies the currency unit (USDC). It doesn't cover edge cases like the possibility of zero open interest, but that's not necessary for this simple metric.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. The description doesn't need to explain parameters, and the empty schema fully covers this aspect.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the specific resource: total open interest across all Polymarket markets. It distinguishes from siblings by emphasizing 'platform-wide' and 'all markets', which differentiates it from get_market_open_interest and get_oi_history.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies clear usage context: use when you need the aggregate platform-wide open interest. It doesn't explicitly mention alternatives or exclusions, but the 'all markets' scope provides natural differentiation from market-specific siblings. Slight deduction for not naming alternatives.
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 the burden of behavioral disclosure. It reveals that the tool combines two subgraphs and emphasizes 'accurate' volume/fee/trade data, which is useful context. It does not mention return format or potential latency, but for a simple no-parameter read operation, it provides sufficient transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences, front-loaded with the primary purpose. The second sentence adds essential detail about data sources without unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a no-parameter tool, the description covers the key aspects: what it returns (aggregate stats), which data sources, and specific metrics. It lacks an explicit return format, but given the simplicity and the mention of the included stats, it is nearly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema is fully complete by definition. The description adds no parameter information, but none is needed. Baseline for 0 params is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves aggregate Polymarket platform statistics and specifies the exact data sources (Main and Orderbook subgraphs) and metrics (market counts, volume, fee, trade data). This distinguishes it from sibling tools like get_global_open_interest or get_daily_stats.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool—when aggregate platform-wide statistics are needed, with a note about combining sources for accurate volume/fee/trade data. However, it does not explicitly mention alternatives or when not to use it.
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?
There are no annotations, so the description carries the full burden for behavioral transparency. It states it 'Returns full market metadata from the Gamma API' and is a 'Get' operation, implying a read-only nature. However, it does not disclose how the tool handles cases where both slug and conditionId are provided, nor does it mention error behavior, rate limits, or authentication requirements, leaving some ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loaded with the core purpose in the first sentence. Every word contributes: it states the action, the target, the source, the return contents, and usage guidance for related tools. There is no redundancy or unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple tool (2 parameters, no output schema), the description is complete: it explains what the tool does, what data is returned ('full market metadata including description, prices, outcomes, and CLOB token IDs'), and how to proceed with the returned conditionId. It also names the API source, which is useful context. There is no missing critical information for a typical use case.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% parameter description coverage, so the baseline is 3. The description adds meaning by clarifying that parameters are alternatives: 'by slug or condition ID,' which is not explicitly stated in the schema. This helps the user understand that either identifier can be used, and it also indicates the return includes a conditionId, which is useful for subsequent calls.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Get detailed Polymarket market info by slug or condition ID.' It specifies the resource (Polymarket market info), the source (Gamma API), and the contents returned (description, prices, outcomes, CLOB token IDs). This effectively distinguishes it from sibling tools by detailing its scope and output.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance: 'Use the returned conditionId to query get_clob_market for live CLOB data, get_market_open_interest for OI, or get_market_resolution for oracle status.' This tells the user when to use this tool (to obtain metadata) and directs them to alternative tools for specific follow-up data, clearly establishing the workflow.
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:
Score Badge
Copy to your README.md:
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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/phon3/Polymarket-MCP'
If you have feedback or need assistance with the MCP directory API, please join our Discord server