@igoforth/polymarket-mcp

Server Quality Checklist

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

Latest release: v1.1.0
Disambiguation2/5
Many tools have unclear boundaries. For example, get_tags_related_to_tag and get_related_tags appear to do the same thing, and get_sampling_markets vs get_sampling_simplified_markets are nearly identical. Price-related tools (get_prices, get_midpoint, get_spreads) also overlap significantly.
Naming Consistency3/5
The naming pattern is mixed: some tools use list_ (list_markets, list_comments), others use get_ (get_event, get_market_tags), and a few use neither (query_markets, public_search). While most names are readable, the inconsistency makes the API less predictable.
Tool Count2/5
With 47 tools, the server feels overloaded. Many are minor variations (e.g., get_sampling_markets vs get_sampling_simplified_markets, get_related_tags vs get_tags_related_to_tag) that could be merged or removed. The large count increases cognitive load without clear added value.
Completeness4/5
The server covers a broad range of Polymarket data: events, markets, prices, user positions, comments, tags, sports, and builder analytics. It is almost entirely read-only, which seems intentional, and lacks only minor convenience features like batch queries or combined endpoints.
Average 2.9/5 across 47 of 47 tools scored. Lowest: 2/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
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.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior1/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 only says 'Get sports metadata,' which implies a read operation but doesn't disclose return format, side effects, rate limits, authentication needs, or any other behavioral traits. This is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, but it is under-specified rather than concise. It simply restates the title without adding any usable information, so the sentence does not earn its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given 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 is the only source of context. It fails to define what 'sports metadata' refers to, what the response looks like, or how this tool relates to the many similarly named siblings. This is completely inadequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema is trivially complete. Per the rubric, 0 params earns a baseline of 4. The description doesn't add parameter-related meaning, but there are no parameters to explain.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get sports metadata' is a tautology, restating the tool name and title exactly without adding any additional meaning. It uses a verb+resource format but 'sports metadata' is undefined and does not distinguish this tool from siblings like get_event_metadata or get_series_metadata.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance whatsoever on when to use this tool versus the many alternative metadata tools in the sibling list. No context, prerequisites, or exclusions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility for behavioral disclosure. It only reveals that the selection is random, but omits any mention of pagination (next_cursor parameter), response format, or whether it is a read-only operation. This is insufficient for an agent to understand the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence with no fluff, but it is under-specified. For a tool with one undocumented parameter and no annotations, this is not appropriately sized; it omits critical usage and parameter information that could be conveyed in just a few more words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has one parameter, no annotations, and no output schema, so the description must explain the tool's role and the cursor parameter. It does neither, leaving the agent without a clear understanding of how to invoke the tool or interpret results. The existence of similar siblings further increases the need for more context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the tool description provides no explanation for the 'next_cursor' parameter. The parameter's purpose (likely pagination) is completely undocumented, so the description fails to compensate for the schema's lack of semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear action ('Get') and resource ('markets') with the modifier 'random sample', which distinguishes it from list_markets or query_markets. However, it does not specify the sample size or whether it supports pagination, and it does not differentiate from the sibling tool get_sampling_simplified_markets.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. The description does not mention any context, prerequisites, or exclusions, leaving the agent without information to choose between this and sibling tools like list_markets or get_sampling_simplified_markets.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description alone must disclose behavioral traits. It merely states 'get live volume' without explaining whether the volume is a snapshot, how it updates, any rate limits, required permissions, or what the response contains. This is a significant transparency gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, which is efficient and front-loaded. However, it borders on under-specification, as it contains no additional context that would help an agent understand the tool's niche.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations, no output schema, and no parameter explanation, the description is grossly incomplete. It fails to convey what 'live volume' means, how to interpret the response, or any contextual details necessary for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema defines a single required 'id' parameter (type number, minimum 1), but the description does not explain that 'id' refers to an event or how it is used. With 0% schema description coverage, the description fails to add any meaning beyond the raw schema, leaving the parameter ambiguous.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action ('get live volume') and the target ('for an event'), providing a specific verb and resource. It distinguishes itself from siblings like get_event or list_markets by focusing on 'live volume,' but does not explicitly call out alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives such as get_event_metadata or query_markets. The description lacks any context on scenarios, prerequisites, or exclusions, leaving the agent without decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It only restates the action in the name and provides no details about pagination, filtering, data latency, or what constitutes a 'closed' position. No behavioral traits are revealed beyond the tool name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasteful words. It conveys the core purpose efficiently, though at the cost of missing necessary detail. It earns its place as a concise statement.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 4 parameters and no annotations or output schema, so the description must compensate. It fails to explain pagination, market filtering, or the meaning of 'closed positions', making it incomplete for an agent to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description only mentions 'for a user', which maps to the required 'user' parameter. The remaining parameters (limit, market, offset) are entirely unexplained, leaving the agent without semantics for optional filters and pagination.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the specific action ('Get closed positions') and the target ('for a user'), distinguishing it from the sibling 'get_user_positions' by focusing on closed positions. However, it does not explicitly contrast with alternatives, leaving some ambiguity about the exact 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'get_user_positions' or 'get_recent_trades'. It lacks any context about prerequisites, exclusions, or recommended usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavioral traits but only states the basic function. It does not mention limitations, error behavior, rate limits, or how the data is returned. For a read-only data retrieval tool, the lack of any behavioral context makes the description minimally adequate at best.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise, consisting of a single sentence. However, conciseness crosses into under-specification, as it omits critical information. It is front-loaded but not adequately informative, so it earns a middle score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given five parameters with no schema descriptions, no output schema, and no annotations, the description is severely incomplete. It does not explain parameter meanings, expected return format, or usage context. The tool cannot be used correctly based on this description alone.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for the lack of parameter documentation. It fails to explain any of the five parameters, and it even misleads by using 'token' instead of the actual parameter 'market'. This is a clear gap in semantic clarity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool's action ('Get') and resource ('historical price data'), which is specific enough to distinguish it from siblings like get_prices and get_midpoint. However, it uses 'token' while the schema uses 'market', which causes slight ambiguity but does not obscure the core purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to choose this tool over alternatives. It lacks any mention of use cases, exclusions, or sibling tools such as get_prices for current data. The only implicit hint is the word 'historical', but no explicit direction is given.
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 doesn't state whether this is a read-only operation, whether authentication is required, how errors are handled, or the structure of the response. It only mentions that related tags can be fetched by ID or slug, leaving critical behavior undiscussed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one short sentence with no filler, which is appropriately concise for the little information it conveys. However, the brevity contributes to under-specification rather than being a model of concise clarity, so it doesn't earn a 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with only two parameters and no output schema, the description should be self-sufficient, but it is not. It leaves unclear the exact input semantics and what 'related tags' means, making it incomplete for a simple tool. The absence of annotations and schema descriptions makes this gap significant.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero description coverage, and the description only repeats the parameter names. It doesn't explain that 'id' is a numeric tag identifier and 'slug' is a string identifier, nor does it discuss precedence when both are provided. The description adds no value beyond the parameter names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear action ('Get related tags') and identifies the lookup methods (by ID or slug). However, it doesn't explain what 'related' means or what the ID/slug refers to. It also fails to distinguish itself from the sibling tool get_tags_related_to_tag, which sounds nearly identical.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like get_tags_related_to_tag. It doesn't clarify whether to use id or slug, whether they are mutually exclusive, or whether one is preferred in certain contexts.
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 full burden for behavioral disclosure. It only states the basic purpose and gives no insight into return formats, error handling, data freshness, or potential side effects. For a read operation, the lack of detail on what exactly is returned or how missing identifiers are handled is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence with no filler or redundant phrasing. It is well-structured and easy to parse. However, it is perhaps too terse, omitting important details, but from a pure conciseness standpoint it earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 3 parameters, no output schema, and no annotations, the description is severely incomplete. It does not explain how to identify a series, what the metric options produce, or any expected response structure. This is inadequate for an agent to invoke the tool correctly without additional external knowledge.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description fails to compensate. It mentions 'comments count or summary' which loosely maps to the 'metric' parameter, but does not explain 'id' or 'slug' as identifiers, nor does it clarify that 'metric' is required. The description adds almost no meaning beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get series comments count or summary' uses a specific verb and resource, clearly indicating the tool's function. It differentiates from siblings like get_series by focusing on comments count or summary rather than full series details. However, it could be more explicit about what 'summary' entails.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as get_series, get_event_metadata, or list_comments. There are no exclusions, prerequisites, or context about typical use cases.
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 present, so the description carries full responsibility. 'Get' implies a read-only operation, but the description does not disclose return formats, token requirements, rate limits, or any other behavioral traits. It adds minimal information beyond the verb itself.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no wasted words, but it is under-specified to the point of being terse. It communicates the core action but omits helpful details that could be added without verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (one array parameter, no output schema), but the description still lacks essential context. It never defines 'spreads', explains how tokens are referenced, or hints at the return shape. Given the absence of annotations, this is insufficient for an agent to reliably select and use the tool among many similar siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter (token_ids), and the description's phrase 'for multiple tokens' simply restates the parameter's plurality. With 0% schema description coverage, the description should explain what tokens are, how to format them, or how spreads relate to token_ids, but it does not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('get') and identifies the resource ('spreads') with a scope qualifier ('for multiple tokens'), making the core purpose clear. However, it doesn't distinguish from sibling tools like get_prices or get_midpoint beyond the term 'spreads', and it doesn't explicitly connect to the title's 'bid-ask' phrasing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as get_prices, get_midpoint, or get_orderbooks. No context, prerequisites, or exclusions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavior, but it only notes randomness. It omits pagination (despite the `next_cursor` parameter), return format, the meaning of 'simplified,' and any side effects or requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with no filler or redundant wording. It is appropriately front-loaded but slightly under-specified, missing key details that would be valuable in the same concise format.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool appears to be a simple paginated list, but the description does not explain pagination, result count, or the 'simplified' concept. With no output schema and no annotations, the description is insufficient for an agent to fully understand the tool's behavior and edge cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides no description for `next_cursor`, and the description does not mention it either. With 0% schema description coverage, the description fails entirely to clarify the cursor's role in pagination or any other parameter behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action and resource: 'Get a random sample of simplified markets.' It identifies a distinct resource ('simplified markets') but does not explicitly contrast with the sibling tool `get_sampling_markets`, so it does not fully differentiate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like `get_sampling_markets` or `query_markets`. There is no mention of context, exclusions, or preferred scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states that the tool returns total value, without explaining whether it includes current vs. historical positions, how valuation is computed, whether authentication is required, or any rate limits. This is a significant gap for a tool that likely performs aggregation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single clear sentence with no filler or redundancy. It is front-loaded with the action 'Get' and immediately specifies the resource. However, it is somewhat terse, but the conciseness itself is appropriate; the issue is missing content, not verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This tool has 2 parameters, no output schema, and no annotations, so the description must carry more weight. It only covers the basic purpose, leaving out parameter semantics, return format, and behavioral context. For an agent to select and invoke this tool correctly, more detail is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain the meaning of the 'user' or 'market' parameters. 'market' is an array of strings and is entirely unexplained, while 'user' is only implied. The description adds no value beyond the bare schema, failing to compensate for the lack of parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get total value of a user's positions' uses a specific verb 'get' and identifies the resource as 'total value of a user's positions'. It clearly distinguishes from sibling tools like get_user_positions, which likely return position lists rather than an aggregate value. However, it doesn't clarify what 'value' means (e.g., current market value, cost basis) or whether it includes open and closed positions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as get_user_positions, get_closed_positions, or get_user_activity. The description implies a use case for retrieving aggregate value, but it does not state any context, prerequisites, or exclusions, leaving the agent without decision criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states a read operation ('Get') and the ranking basis ('by volume'), but omits important details like sort direction (descending/ascending), whether date filters affect results, pagination behavior, or any rate limiting. This is thin coverage for a tool with no structured safety context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise and front-loaded. However, it sacrifices necessary detail for brevity—it's not verbose but is under-specified. While it earns its place as a clear statement of purpose, it leaves significant gaps that more sentences could address without becoming wordy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and no annotations, and the description only states 'Get builder rankings by volume.' It doesn't specify the return structure, whether rankings are ordered by volume descending, how date boundaries work, or how pagination behaves. Given the existence of closely related sibling tools, this description is incomplete and leaves an agent without sufficient context to invoke the tool confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 4 parameters (limit, offset, start_date, end_date) with 0% description coverage. The description adds no meaning to any parameter—it doesn't explain what 'by volume' means for the date parameters or how limit/offset affect results. Since the schema provides only names and basic constraints, the description fails to compensate, leaving parameter semantics essentially unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get builder rankings by volume' clearly identifies the tool's function with a specific verb ('Get') and resource ('builder rankings'), and includes the ranking criterion ('by volume'). This distinguishes it from sibling tools like get_builders_volume, which focuses on volume rather than rankings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as get_builders_volume or get_user_volume. There is no mention of intended use cases, exclusions, or context that would help an agent choose this tool over similar options.
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 does not mention safety (read-only), authentication, rate limits, pagination, or return format. It merely restates the action without contextual details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no unnecessary words. It is front-loaded and effectively communicates the basic purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one optional parameter, the description gives the fundamental purpose but omits parameter details, default behavior, and response structure. Since there is no output schema, the agent has limited guidance on what to expect beyond 'time-series'.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, and the description does not explain the `timePeriod` parameter. The word 'daily' imperfectly implies a default granularity but contradicts the enum values WEEK/MONTH/ALL. No additional meaning is added beyond what the enum already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves volume time-series for builders, but the qualifier 'daily' is misleading since the `timePeriod` parameter supports WEEK, MONTH, and ALL as well. It does not explicitly distinguish from sibling tools like `get_live_volume` or `get_traded`.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description only states the core function without mention of exclusions, prerequisites, or related 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 present, so the description carries the full burden of behavioral disclosure. It merely states 'get comments by comment ID' without revealing return format, pagination, permissions, or any side effects, leaving the agent with very little behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no wasted words. It is easy to parse and front-loaded, though it is somewhat under-specified; still, it earns its place without bloat.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and 2 parameters, the description is incomplete for an agent. It does not explain the meaning of 'get_positions', nor does it describe any return values or limitations, making it insufficient for reliable tool invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds minimal meaning. It hints that 'id' is a comment ID, but the second parameter 'get_positions' is completely unexplained. The description fails to compensate for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool retrieves comments by a comment ID, using a specific verb and resource. However, it doesn't distinguish from siblings like list_comments or get_comments_by_user, so it lacks explicit differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as list_comments or get_comments_by_user. There are no prerequisites, exclusions, or context signals to help the agent decide.
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 only states the basic function without disclosing behavior such as pagination (despite limit/offset params), authentication requirements, or return format. The description does not add transparency beyond the name and title.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that is easy to parse, but it is perhaps too terse, omitting valuable context. However, it is appropriately front-loaded with the verb.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and no annotations, and the description does not specify return values or pagination behavior. Given the overlapping sibling tools, the description is insufficient for an agent to fully understand the tool's scope.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, and the description only implies that user_address is the filter. The limit and offset parameters are not explained, and there is no information about defaults or ordering.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get comments by wallet address' clearly states the action (get) and resource (comments) with a specific scope (wallet address). However, it does not explicitly differentiate from sibling tools like list_comments or get_comments_by_id.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, such as whether to use it when querying a specific user's comments versus listing all comments. No alternative tools are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure, but it only states the function without revealing any behavioral traits such as authentication requirements, output format, error conditions, or whether it counts unique markets or trades. This is a significant gap for a tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, using a single front-loaded sentence that gets straight to the point. However, it is slightly under-specified, lacking any additional context that would make it more useful without adding bulk.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, but with no output schema and no annotations, the description is too minimal. It does not explain what constitutes a 'market traded,' whether the count is unique, the return format, or any edge cases, leaving the agent with insufficient information to fully understand the tool's behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage for the 'user' parameter, and the description adds no explanation about the parameter's format, expected values, or semantics. While the parameter name is self-explanatory, the description fails to compensate for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves the number of markets a user has traded, using a specific verb and resource. It is more specific than merely restating the tool name and is distinguishable from sibling tools like get_recent_trades or get_user_activity, though it does not explicitly differentiate itself.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, no prerequisites, and no exclusions. It is a bare statement without context or usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations provided, so the description must communicate safety and behavior. It only mentions pagination and neither confirms read-only semantics nor explains return format, ordering, authentication requirements, or rate limits. The verb 'list' implies read-only, but other behavioral traits are not disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence and is easy to parse. It does not waste words, though the brevity approaches under-specification rather than well-balanced conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema and no annotations, the description does not communicate what the response contains (e.g., event creator IDs, names, total count), nor does it mention any details about ordering or defaults. The absence of behavioral and return information makes it incomplete for an agent to invoke confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no descriptions for limit and offset (0% coverage). The description's mention of pagination gives a high-level hint that limit and offset control pagination, but it does not explain their meaning, defaults, or constraints beyond what the schema already provides in type/min/max.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists event creators and mentions pagination. It uses the specific verb 'list' and resource 'event creators', but it does not explicitly differentiate from the sibling tool get_event_creator, so it is clear but not fully distinguishing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool over alternatives such as get_event_creator or list_events. The description only states what it does, not in which situation it should be chosen.
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 behavioral disclosure burden. The phrase 'List' implies a read operation, but the description gives no detail about pagination behavior, default filters, output shape, or any limitations. This is a minimal disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It is appropriately concise for the simple purpose it conveys.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and no annotations, yet the description does not explain return values, filter semantics, or default behavior. For a tool with four optional parameters and several close siblings, this is insufficient for correct selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description mentions no parameters at all. With four parameters (limit, closed, offset, volume_num_min) and no explanatory text, the agent gets no added meaning beyond the raw property names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List') and resource ('prediction markets from Polymarket'), so the agent knows what the tool does. However, it does not distinguish this from sibling tools like query_markets, which likely serves a similar purpose, so it doesn't earn 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use list_markets instead of the many sibling tools, particularly query_markets. The description only states what it does without providing context, exclusions, or alternative tool references.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only mentions pagination but does not explain behavior such as result ordering, filtering, authentication requirements, rate limits, or the meaning of 'results'. This leaves the agent without critical operational context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, front-loaded with the action, and contains no wasted words. However, it is so brief that it borders on under-specification, though structurally it is efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and no annotations, so the description should provide context about return format and usage. It does not describe what the response contains, any ordering, or clarify what a 'result' is. For a simple list tool, this lacks essential detail for an agent to fully understand the tool's behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for the missing parameter documentation. It only mentions 'pagination' in passing, which hints at limit and offset but does not explain their semantics or usage. The schema provides defaults and constraints, but the description adds minimal meaning beyond that.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'List' and the resource 'sports events results', which distinguishes it from sibling tools like 'list_events' that list events themselves. However, it does not elaborate on what 'results' means (e.g., scores, outcomes), leaving some ambiguity about the exact resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. The description does not mention use cases, exclusions, or related tools, which is a significant gap given the large number of sibling tools that might also list event-related data.
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 present, so the description bears the full burden. It only says 'get event by numeric ID or URL slug' and does not disclose behavior such as error handling for invalid IDs, return format, or any rate/latency considerations. This is minimal transparency for a retrieval tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that conveys the essential purpose without waste. It is appropriately concise for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations, no output schema, and an empty input schema, the description should compensate by explaining expected return values, error behavior, or relationship to sibling tools. It does none of this, leaving significant gaps for an agent trying to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is empty (0 properties), yet the description references numeric ID and URL slug as inputs. This creates a mismatch: the description adds meaning by naming identifier types, but it does not specify parameter names, locations, or formats, making correct invocation unclear. Baseline for 0 params would be 4, but the implied parameters and missing schema reduce it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get event by numeric ID or URL slug' clearly states the action (get) and the resource (event), and specifies how the event is identified. It distinguishes from list-type siblings like list_events, but does not explicitly differentiate from get_event_metadata, so it isn't a perfect 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives like get_event_metadata or list_events. There is no mention of preferred usage, exclusions, or fallback 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?
There are no annotations provided, so the description bears full responsibility for behavioral disclosure. It does not mention potential errors (e.g., invalid market_id), required permissions, return format, or whether the operation is read-only. The 'get' verb implies read-only, but no explicit behavioral traits are disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It efficiently communicates the core purpose, though it omits any usage guidance or parameter context, which would be expected in a fuller description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple tool with one parameter and no output schema or annotations. However, the description does not explain what the returned 'clarifications' look like, how they are structured, or any edge-case behavior. Given the lack of an output schema, the description should provide more detail to be complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has only market_id with a type of 'number' and zero description coverage. The tool description does not mention market_id at all, adding no meaning beyond the schema. For a low-coverage case, the description was expected to compensate but did not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get clarifications about a market's resolution criteria' uses a specific verb ('get') with a specific resource ('market clarifications') and adds scope ('resolution criteria'). This clearly distinguishes it from sibling tools like get_market_tags or get_market_rewards, which target different aspects of a market.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, nor any exclusions or prerequisites. It merely states the action without contextualizing it among related tools like get_event or get_market_metadata.
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 full responsibility for behavioral disclosure. It only states the basic action without addressing pagination limits, return format, or data scope details, which are important for a market data retrieval tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no extraneous wording. It is appropriately short for its simplicity, earning a perfect score for efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is too brief. It omits information about pagination, the nature of reward data, and the role of condition_id, making it insufficient for a tool with 3 parameters and moderate complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It mentions 'a market' but does not connect it to the required 'condition_id' parameter, nor does it explain the 'limit' or 'next_cursor' parameters related to pagination.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: retrieving reward data for market makers on a specific market. It has a specific verb and resource, though it does not explicitly distinguish itself from sibling tools like get_current_reward_markets.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There is no mention of typical use cases, preconditions, or exclusions, leaving the agent to infer usage solely from the name and schema.
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?
There are no annotations, so the description must carry the full burden of behavioral disclosure. It only states the basic operation without mentioning return format, error handling, or side effects. No annotation contradiction is present.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no redundant wording. It is front-loaded and directly states the action and subject, making it easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (one parameter), the description is somewhat sufficient but fails to provide context about the return value, common failure modes, or usage scenarios. With no output schema or annotations, the description leaves significant gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter, 'id', with no description. The description adds only that the ID is numeric and refers to a market, which is minimal and partially implicit in the tool name. It does not clarify the type of tag data returned or how the ID is used beyond lookup.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Get tags') and the target resource ('a market'), which is clear and distinguishes it from sibling tools like get_tag or list_tags. However, it does not explicitly describe what the tags are or how they relate to the market beyond the name, so it falls short of a perfect 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives. There is no mention of alternative tools, prerequisites, or typical use cases, leaving the agent without context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It merely says 'recent trades' without clarifying time windows, ordering, pagination, or read-only nature. There is no added value beyond the tool name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence with no filler. It is front-loaded with the verb and resource, making it easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 3 optional parameters and no output schema. The description does not explain return values, result ordering, or the meaning of 'recent', leaving the agent under-informed for a tool of this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It does explain 'market' and 'user' as optional filters, but it omits the 'limit' parameter entirely, leaving its purpose and constraints unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Get') and resource ('recent trades'), and mentions the optional filtering by market or user. However, it does not differentiate from sibling tools like get_traded, which might overlap in purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives. No exclusions, prerequisites, or context for selecting this over other trade-related tools like get_traded or get_user_activity.
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 disclosure, but it only provides a minimal statement of functionality. It doesn't disclose any behavioral aspects such as authentication, rate limits, pagination behavior, or return format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded and contains no superfluous text. It effectively communicates the core purpose without waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool lacks annotations, an output schema, and has 3 parameters with zero schema descriptions. The one-sentence description is insufficient to fully understand the tool's behavior, especially given related tools like get_closed_positions that suggest a need for clarity on the 'open' scope.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It only clarifies that 'user' refers to a wallet address, but leaves 'limit' and 'offset' unexplained, which carry meaning for pagination.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (get) and the resource (open positions) along with the scope (for a wallet address). It differentiates from get_closed_positions by the 'open' qualifier, but does not explicitly mention alternative tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus siblings like get_closed_positions or get_user_activity. The description simply states what it does without any contextual usage instructions.
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 burden of behavioral disclosure. It only mentions 'pagination,' which hints at paged results, but it does not disclose whether the operation is read-only (though 'list' implies it), any required authentication, ordering, or the response format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, focused sentence with no extraneous words. It is front-loaded and easy to parse, earning a high score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, but the description omits guidance on when to use it, any filtering or ordering behavior, and the shape of the response. Without an output schema or annotations, this minimal description may leave the agent uncertain about expected results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions cover 0% of the parameters, so the description must compensate. It only mentions 'pagination' generically and does not explain that 'limit' controls the maximum number of teams or that 'offset' controls the starting point, though these are inferable from names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'List' with the resource 'sports teams' and notes pagination, making it clear this is a collection-returning operation. It is distinct from sibling get_team, which retrieves a single team, though it doesn't explicitly name the alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool versus alternatives like get_team or other list tools. The description merely states what it does without providing context for selection or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden for behavioral disclosure. It only states the calculation and does not mention return format, edge cases, or that this is a read-only operation. The description adds no extra behavioral context beyond the name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that directly states the purpose. There is no wasted information or filler, and the key action is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one parameter and no output schema, the description is too sparse. It fails to explain what the returned midpoint is (number, string), what happens if there are no orders, or the role of token_id. The description leaves significant gaps for a simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has no description for token_id (coverage 0%), and the description does not mention the parameter at all. The agent receives no semantic information about what token_id should be, leaving its purpose entirely unstated.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: to get the midpoint between the best bid and ask. It uses a specific verb and resource, and the definition of midpoint is precise, distinguishing it from sibling tools like get_prices or get_spreads.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. There is no mention of use cases, comparisons to get_prices or get_spreads, or any contextual preference.
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 disclose behavior. It implies a read-only operation via 'Get' but does not state side effects, error handling, authentication needs, or rate limits. The description's brevity leaves behavioral expectations largely unspecified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the verb, and contains no extraneous information. It is appropriately succinct, though it may be too terse to fully convey intent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description should explain return values and usage context. It fails to describe what the response contains, what 'Other size' means, or what the user input expects. This is minimal coverage for a tool with two required parameters and no structured output details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for parameter meaning. It provides general context ('for a neg risk event and user') but does not explicitly map parameters to concepts. The schema covers types and constraints, and parameter names are self-explanatory, giving partial compensation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action ('Get') and the resource ('Other' size for a neg risk event and user). It differentiates the tool from siblings by specifying a unique data point ('Other' size) and context (neg risk event). However, the term 'Other size' is ambiguous without additional domain context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus alternatives, no prerequisites, and no exclusionary criteria. While the purpose narrows its use, there is no explicit mention of alternative tools or conditions for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of explaining behavior. It only states that it retrieves related tags, but does not disclose whether id or slug is required, what happens if both are provided, the response format, or any side effects. This is a significant gap for a tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence that front-loads the core action ('Get all tags related to a tag') and includes the identifier options. It contains no wasted words, making it highly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with two optional parameters and no output schema, the description is minimal. It leaves unclear what 'related' means, what the return structure looks like, and how to handle ambiguous inputs (both id and slug). The lack of annotations and underspecified parameters makes this below the minimum viable for safe invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema lists id and slug with 0% description coverage. The description adds that the tag is identified 'by ID or slug', implying either parameter can be used, which is useful. However, it does not specify precedence, required status, or format constraints, so the added meaning is limited.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Get' and identifies the resource as 'all tags related to a tag' with the identifier options 'ID or slug'. This clearly states the tool's function, but it does not explicitly distinguish it from the similar sibling tool 'get_related_tags', leaving potential ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as 'get_related_tags' or 'get_tag'. It mentions no context, prerequisites, or exclusions, leaving the agent without direction for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavior. It only states the action and does not address read-only nature, side effects, pagination behavior, or rate limits. The schema hints at pagination via limit/offset, but the description does not mention 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that directly communicates the core purpose without fluff. It is front-loaded and appropriately sized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool lacks an output schema and annotations, and the description does not clarify what 'trading activity' encompasses or how the data is returned. The information is minimal and insufficient for an agent to understand the full context, especially given the presence of overlapping sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning to the 'user' parameter by identifying it as a wallet address. However, with 0% schema description coverage, it should also explain the semantics of limit and offset, which are left implicit. Some added value, but incomplete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Get trading activity for a wallet address.' It specifies a verb ('Get'), a resource ('trading activity'), and an object ('wallet address'). However, it does not distinguish from sibling tools like get_recent_trades or get_user_positions, which also retrieve trading-related data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus other similar tools. There is no mention of alternatives, prerequisites, or scenarios that favor this tool. Usage context is entirely absent.
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 for disclosing behavior. It only says 'list comments' without mentioning pagination, ordering, default limits, or how filters combine. For a listing tool, this is minimal and does not disclose return format or potential side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that is front-loaded and contains no fluff. It effectively communicates the primary function and key filter capability in minimal words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no annotations and no output schema, so the description must carry more weight. It fails to mention pagination behavior, default limits, or the shape of the return value. Given the existence of sibling comment tools, more context on when this is appropriate would be expected.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description mentions 'optional market/event filter' which clarifies the purpose of event_id and market_id parameters. However, it does not explain the limit and offset parameters, which are also present in the schema. With 0% schema description coverage, the description partially compensates but leaves gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb+resource: 'List comments' with an optional filter by market/event. This distinguishes it from sibling tools like get_comments_by_id and get_comments_by_user, though it does not explicitly name them. It is specific enough to understand the core function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for listing comments with filters but provides no explicit guidance on when to choose this tool over alternatives like get_comments_by_id or get_comments_by_user. No exclusions or alternative recommendations are given.
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 full responsibility for behavioral disclosure. It only mentions offset/cursor pagination, which is already visible in the schema, and doesn't cover default ordering, active filter behavior, or return format. The read-only nature is implied but not explicitly stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no fluff. It is front-loaded with the action and resource, making it easy to parse. However, the brevity limits its informative value, though that is more a completeness issue than conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 5 parameters, no output schema, and no annotations, this description is insufficient. It does not describe the return structure, default values, or how the tool behaves with different parameter combinations. An agent cannot confidently invoke this tool for a specific task without more details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate by explaining parameters. It acknowledges offset and cursor as pagination options, but leaves limit, order, and active unexplained. Without additional context, the agent cannot determine how these parameters affect the result.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('List') and resource ('prediction events'). This distinguishes it from sibling tools like get_event (singular) and list_sport_events_results (filtered results). Mentioning pagination adds further specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There are no exclusions, prerequisites, or context about which scenario this tool is best suited for. The agent is left to infer its usage from the name alone.
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?
There are no annotations, so the description must carry the behavioral disclosure burden. It only says 'Search across markets, events, and profiles,' with no mention of result structure, pagination, sorting, rate limits, or any side effects. This is minimal but not misleading.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence. Every word contributes to meaning, and there is no unnecessary verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and only two parameters, the description is too sparse for an agent to understand what the tool returns or how to use it effectively. It lacks details on result formats, limits, or how the search aggregates across types.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not mention the parameters (q, limit_per_type) at all. It fails to explain what the query string should contain or how limit_per_type behaves.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches across markets, events, and profiles. This is a specific verb (search) and resource scope that distinguishes it from sibling tools like get_event or list_markets.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus the many alternative sibling tools. It does not state when a search is preferable to using specific list/get endpoints, nor does it mention any 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 return format, the meaning of 'prices' (e.g., bid/ask, mid), or any side semantics despite the `side` parameter. It does not mention rate limits, authentication, or any side effects. The tool is a read operation, but the description leaves the agent guessing about response structure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. It conveys the core purpose and modes efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description is too sparse. It fails to explain the return format, the role of `side`, and edge cases like whether 'all' means all tokens or all sides. For a tool with 3 parameters and no output schema, more detail is needed for confident invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It partially maps parameters: `token_id` for single token and `prices` for batch, and implies 'all' when neither is provided. However, the `side` parameter is entirely unexplained, and the description does not specify how the array items should be structured or whether `side` can be used with `token_id`. This leaves significant ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool's function ('Get market prices') and lists three usage modes (all, single token, batch), making it distinct from siblings like get_spreads or get_orderbooks. However, the term 'market prices' is somewhat generic and could be confused with price history tools, so it doesn't fully achieve top-tier clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear modes of invocation (all/single/batch) but gives no guidance on when to prefer this tool over alternative price-related tools such as get_midpoint, get_orderbooks, or get_price_history. There are no explicit when-to-use or when-not-to-use conditions.
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 behavior. It states that the profile is 'public' and the operation is a 'Get', implying a read-only action, but it does not disclose response format, potential errors, authentication requirements, or any rate limits. This is minimal disclosure and not enough for a tool operating without annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence of seven words: 'Get public profile by wallet address.' Every word carries meaning and there is no redundancy or filler, making it highly concise and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one parameter and no output schema, so the description covers the core function and key parameter. However, it lacks context about what fields the profile contains, whether it works for any wallet address, and any edge cases. For a public profile getter this is sufficient but with clear gaps in completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides only a parameter name 'user_address' with type string and no description (coverage 0%). The description compensates by identifying it as a 'wallet address', which adds meaning beyond the schema. However, it does not specify format, examples, or whether it accepts an ENS name or only a hex address, so compensation is partial.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies the verb 'Get' and the resource 'public profile', and adds the important qualifier 'by wallet address', which clarifies the input parameter. It is clear about what the tool does, though it does not explicitly distinguish itself from sibling tools like get_user_activity or get_user_positions aside from the resource name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as get_user_activity or get_user_positions. There are no use cases, prerequisites, or exclusions mentioned, leaving the agent to infer when this is the right tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for behavioral disclosure. It only states the action but omits any details about pagination, the effect of the 'limit' parameter, output format, or error behavior. This is a minimal disclosure 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, front-loaded with the verb and resource. There is no filler or redundancy, making it highly efficient for agent consumption.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the agent needs the description to explain return values and behavior. The description only states the basic function, leaving out what a 'revision' contains, how results are ordered or limited, and what the response looks like. This is incomplete for a tool of moderate complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds little parameter meaning. It implies 'questionID' refers to a market question but says nothing about the 'limit' parameter, its purpose, or how it interacts with the results. The description does not compensate for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get revision history for a market question' uses a specific verb and resource, clearly indicating the tool's function. Among all sibling tools, only this one mentions revisions, so it is well-differentiated. The noun phrase 'revision history' is precise and 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention related tools, exclusions, or prerequisites. The agent is left without context for selecting this tool over other market data getters.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only says 'Get series by ID' and does not elaborate on return format, error handling, authorization requirements, or what fields are included, leaving significant behavioral ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no wasted words. It is appropriately front-loaded and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter get-by-id tool, the description is minimally viable, but given the absence of an output schema and annotations, it lacks detail on return structure or possible variations. It is sufficient for a trivial fetch but leaves questions about the response and domain context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. 'By ID' clarifies that the 'id' parameter is the series identifier, which adds some semantic meaning beyond the raw schema. However, it does not explain the nature of the ID or any constraints, so compensation is only partial.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get series by ID' uses a specific verb and resource, making it clear the tool fetches a single series by its identifier. It distinguishes itself from list_series (which lists all series) implicitly, but does not explicitly differentiate from get_series_metadata, which is a closely named sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as list_series or get_series_metadata. The description simply states the function without any context on selection criteria, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden for behavioral disclosure. It only repeats the verb 'get,' implying a read-only operation, but does not mention return format, whether the response is a list or a map, potential errors, or any access constraints. This is minimal disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of five words, front-loaded with the key verb and resource. Every word earns its place; there is no wasted text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the tool's low complexity (no parameters), the description is too sparse. There is no output schema to explain return values, and the description does not clarify what 'market types' are or give examples. This leaves a meaningful gap for an agent trying to understand the tool's output or behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, and the list of properties is empty. Per the rubric, a zero-parameter tool gets a baseline of 4 because there are no parameter semantics to describe; the description adds nothing here but doesn't need to.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get sports market types' clearly states a get operation for a specific resource ('sports market types'), making its core purpose evident. However, it does not distinguish itself from siblings like get_sports_metadata or query_markets, and 'market types' remains undefined.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. With many sibling tools like get_sports_metadata or list_markets, the agent is left without context to decide whether this tool is the right choice for a given task.
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 present, so the description must disclose behavior. It only states 'Get tag by ID or slug' without clarifying whether the parameters are mutually exclusive, what happens if both are provided, or error/not-found behavior. This ambiguity is significant given both parameters are optional.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that conveys the core action and parameter usage without waste. Perfectly front-loaded and appropriately sized for a simple getter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Simple tool, but the lack of output schema and annotations means the description should clarify return details and parameter requirements. It's adequate for a basic get but leaves questions about return format and parameter exclusivity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds the crucial insight that id and slug are alternative identifiers via 'by ID or slug'. However, it doesn't explain format, precedence, or constraints beyond the schema types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
States the specific operation 'Get tag' and the lookup method 'by ID or slug', clearly identifying the resource and scope. It is distinct from sibling list/related tags tools, though it doesn't explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides no guidance on when to use this tool versus alternatives like list_tags or get_tags_related_to_tag, and no mention of prerequisites or selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only says 'Get' which implies read-only, but it doesn't disclose return format, error behavior, rate limits, or side effects, leaving significant 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no filler. It is front-loaded and gets straight to the point, maximizing clarity per word.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although the tool is simple with only one parameter and no output schema, the description omits any detail about the response structure or content. An agent would not know what an orderbook entry contains or how multiple tokens affect the output, making the description insufficient for complete understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning by clarifying that token_id refers to 'market tokens' and can be 'one or more', which aligns with the schema's anyOf string/array type. However, it doesn't define token format, allowed values, or constraints, so it only partially compensates for the 0% schema description coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: getting orderbook(s) for market tokens. It uses a specific verb+resource ('Get orderbook(s)') and distinguishes from sibling tools like get_prices or get_midpoint by targeting orderbook data specifically.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, no prerequisites, and no exclusions. It implies usage only through its stated purpose, which is insufficient for an agent deciding between this and related price/orderbook tools.
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 weight. 'List' implies a read-only operation and 'pagination' discloses that results are chunked. It does not describe ordering, response format, or potential rate limits, but for a simple list operation, this minimal behavioral context 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence with no filler. It conveys the core action and key behavior (pagination) in six words, earning its place without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with two optional params and no output schema, the description provides the essential purpose and pagination behavior. However, it lacks mention of what fields each series includes, ordering, or how this differs from sibling tools like get_series or get_series_metadata, leaving some ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, yet the description only says 'with pagination,' which merely hints at limit/offset without explaining their semantics or defaults. The schema already exposes the parameter names and constraints, so the description adds negligible meaning beyond what is structurally evident.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List series with pagination' clearly identifies the verb (list) and resource (series), and the pagination phrase signals a collection-oriented operation. It implicitly differentiates from sibling tools like get_series (singular) and get_series_metadata, though it does not explicitly name them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when the agent needs to enumerate series, with pagination controlling result size. However, it offers no explicit when-to-use or when-not-to-use guidance, nor does it mention alternative tools for retrieving series details.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure, but it only says 'Get event creator by ID'. It does not mention return format, potential errors, authentication requirements, or confirm that the operation is read-only, leaving behavioral expectations implicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that conveys the core purpose without any filler. Every word contributes to the meaning, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple get-by-ID tool with one parameter and no output schema, the description is mostly sufficient. However, it leaves minor ambiguity about which ID is being referenced and does not mention potential output details, though these are easily inferred from the tool name and operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema is minimal with a single 'id' parameter and no description, while the description adds only 'by ID', which indicates the lookup key but does not clarify whether it refers to the creator's ID or the event's ID. Given 0% schema coverage, the description offers some semantic meaning but does not fully compensate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action ('Get') on a specific resource ('event creator') using an identifier ('by ID'), which distinguishes it from sibling tools like 'list_event_creators' that perform a different operation. The wording is precise and 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as 'list_event_creators' or 'get_event'. It lacks any mention of exclusions, prerequisites, or conditions that would help an agent decide between this and related tools.
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 must carry the full burden of disclosing behavior. It states the tool returns a timestamp but does not specify format (e.g., ISO 8601, Unix milliseconds), timezone, or whether it reflects request receipt time. This is minimal disclosure but adequate for a seemingly 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no filler or redundancy. It efficiently communicates the core purpose, which is ideal for such a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters and no output schema, the description is relatively complete for basic usage. However, it fails to mention the timestamp format or any nuances (e.g., whether it is the server's current time or a cached value), which could lead to incorrect parsing or interpretation by the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline score of 4 applies. The description adds no parameter-specific semantics, but none are needed since the schema already shows an empty properties object.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and identifies a concrete resource ('CLOB server timestamp'), which clearly distinguishes it from sibling tools like get_event or list_markets. However, it assumes familiarity with the acronym 'CLOB', which could be ambiguous to an agent without domain knowledge.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide any explicit guidance on when to use this tool versus alternatives, nor does it mention exclusions or prerequisites. While the unique function (server time) makes its use case obvious, the absence of any contextual direction leaves the agent to infer usage entirely.
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 for behavioral disclosure. It implies a read-only operation via 'Get' but does not state any safety profile, auth requirements, rate limits, or what the response contains. This is extremely thin 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with no filler or redundancy. It front-loads the verb and object, making it maximally concise and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of output schema and annotations, the description should clarify what a caller gets back. It mentions 'markets' but not whether the result is a list, what fields are included, or what 'current' means. This is adequate for a simple retrieval but leaves notable gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so schema coverage is trivially 100%. The description adds no parameter-specific semantics, but none are needed. Baseline 4 is appropriate since there are no parameters to document.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Get' and clearly identifies the resource as 'markets offering liquidity rewards,' distinguishing it from siblings like get_market_rewards or list_markets. The qualifier 'current' adds temporal scope, making the tool's intent 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as get_market_rewards or list_markets. There are no explicit conditions, exclusions, or references to sibling tools, leaving the agent without contextual decision support.
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 full burden for behavioral disclosure. It reveals that it returns counts, but does not state whether the operation is read-only, potential errors (e.g., unknown event id), or any caching/rate-limit behavior. Name suggests 'get' implies read, but description provides no explicit safety or side-effect context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence that immediately states the tool's purpose and the meaning of the metric parameter. No filler or redundancy; every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple count retrieval with two parameters and a clear enum, the description is nearly sufficient, but missing details like return format (just a number or JSON) and behavior for invalid inputs. Given no output schema and no annotations, a bit more context would make it more complete, but the core functionality is covered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It effectively explains the 'metric' parameter by enumerating its allowed values (tweets, comments, tags) and clarifies that it returns a count. The 'id' parameter is implied as event id from the tool name, but not explicitly described, leaving some ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: retrieving event metadata specifically counts of tweets, comments, or tags. This is a specific verb+resource and differentiates from siblings like get_event (full event details) or get_comments_by_id (actual comments) by focusing on metadata counts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when you need counts of tweets/comments/tags for an event, and the metric parameter exposes the choices. However, it does not explicitly state when to prefer this over alternatives (e.g., fetching comments directly) or provide any exclusions, so guidance is only implied, not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the full burden. 'List' implies a read-only operation, and 'with pagination' discloses the pagination behavior. However, it does not explicitly state that no data is modified, nor does it mention any authentication or rate-limit considerations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. It conveys the core purpose and pagination in the fewest words possible, making it appropriately concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, and the description does not mention the return format or whether tag objects are full or partial. It also lacks any mention of ordering or filtering. Given the many sibling tools and the absence of structured metadata, the description is too minimal to fully inform an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, and the description only says 'with pagination', which vaguely hints at the limit and offset parameters but does not explain their meaning or usage. The schema provides types and defaults, but the description adds no substantive semantic value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists all tags with pagination, using the specific verb 'List' and resource 'tags'. This distinguishes it from singular tools like get_tag and related-tags tools like get_related_tags.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The name and description imply it is used to enumerate all tags, but there is no explicit guidance on when to choose this over sibling tools. It neither mentions alternatives nor provides exclusions, so the 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey safety and behavior. 'Get' implies a read-only operation, but the description adds nothing about return format, error handling, or required permissions. For a simple getter, the implied safety is clear, but additional context is lacking.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence, front-loaded and concise, with no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter getter, the description is minimally sufficient but omits details such as the return object structure, not-found behavior, or relationship to list_teams. Without annotations or an output schema, more context would be helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description says 'by ID,' which is redundant with the parameter name and type in the schema. It does not explain where to obtain the ID, its format beyond being a number, or any additional semantic meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and resource ('sports team') with a clear scope ('by ID'). It distinguishes from the sibling 'list_teams' by indicating a single team lookup.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool is for retrieving a single team by its ID but does not explicitly state when to use it over alternatives like 'list_teams' or 'get_event'. No exclusionary guidance is provided.
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 is the sole source of behavioral info. It implies a safe read operation ('Get detailed market data') and explains flexibility (filtering, field selection). However, it does not disclose potential side effects, rate limits, authentication needs, or what happens on invalid queries. This is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary action. It covers all key aspects—query modes, field selection, presets—without any filler or redundancy. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (no schema, no output schema, no annotations), the description does a good job covering the main query capabilities and user choices. It is complete enough for an agent to understand the tool's flexibility and start using it, though it could mention pagination or response format if needed. The presets list (pricing, metadata, trading, holders, status) enhances completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is empty, so the description fully carries parameter documentation. It mentions querying by id/condition_id/slug, arrays, and tag, plus field selection and presets. This gives the agent meaningful guidance, but lacks exact parameter names, types, and syntax, which would be expected for a zero-schema tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get detailed market data with flexible querying.' It specifies the resource (market data) and the verb (get), and lists multiple query modes (by id/condition_id/slug, arrays, tag) that distinguish it from siblings like list_markets or get_event.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool: when you need flexible filtering by single or multiple markets, or by tag, and want to select specific fields. It does not explicitly name alternatives or say when not to use it, but the coverage of query modes implies a general-purpose query tool, making usage clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

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

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

Card Badge

Copy to your README.md:

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

Score Badge

Copy to your README.md:

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

Latest Blog Posts

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

MCP directory API

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

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

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