polymarket-trader-mcp
Server Quality Checklist
Latest release: v1.6.7
- Disambiguation4/5
Tools are grouped by domain (analysis, markets, orders, etc.) and each has a clearly described purpose. However, some market discovery tools (search, discover, featured, trending) have overlapping functionality that could confuse an agent, though parameters help differentiate.
Naming Consistency5/5All tools follow a consistent 'category.tool_name' pattern with lowercase and underscores. The naming is uniform and predictable, making it easy for an agent to infer usage.
Tool Count3/548 tools is high, but the server aims to cover a comprehensive trading platform including analysis, market data, order execution, portfolio management, and copy trading. While each tool earns its place, the sheer number could be overwhelming for agents.
Completeness5/5The tool set covers the full lifecycle of trading on Polymarket: market discovery, price analysis, trading (buy/sell/batch), portfolio management, risk analysis, copy trading setup, and monitoring. No obvious gaps are present for the intended domain.
Average 4.1/5 across 48 of 48 tools scored. Lowest: 3.4/5.
See the Tool Scores section below for per-tool breakdowns.
- 0 of 2 community issues answered or closed in the last 6 months
- 3 commits in the last 12 weeks
- Last stable release on
- 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.
This repository includes a glama.json configuration file.
This server has been verified by its author.
How to sync the server with GitHub?
Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.
To manually sync the server, click the "Sync Server" button in the MCP server admin interface.
How is the quality score calculated?
The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).
Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.
Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).
Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.
Tool Scores
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It implies a read operation but does not disclose authentication needs, rate limits, or any special behaviors like data staleness. The mention 'Pro feature' hints at access control but no details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences: first defines purpose and filters, second lists return details and feature note. No redundant or irrelevant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description adequately informs about return content. It also notes the Pro feature. However, it lacks details on pagination or ordering, which could be expected for a history list.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds value by listing return fields (entry price, P&L, market info) beyond the schema's parameter descriptions, but does not compensate for missing output schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'retrieve', the resource 'past copy trades', and specifies optional filters and return details (entry price, P&L, market info). It is distinct from sibling tools like 'markets.price_history'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, nor any conditions for not using it. The description only mentions optional filters without context on selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavior. It reveals the ranking criteria (liquidity) and category filtering, but does not mention pagination, rate limits, data freshness, or whether it is a read-only operation. The description is straightforward but lacks depth on invariants.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loading the main action and key details (ranking by liquidity, optional category filter). Every sentence is essential and concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple listing tool with no output schema, the description adequately specifies what is returned (top markets by liquidity) and the optional category filter. It does not detail output fields or metadata, but for this context it is sufficient. Slightly more detail on the return format would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% description coverage, meaning the parameters are well-documented. The description adds value by explaining the ranking by liquidity and the active trading aspect, which clarifies the meaning of the returned data beyond the schema's parameter definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists top Polymarket markets ranked by liquidity, with an optional category filter. It includes specific categories and implies a ranking by liquidity, which distinguishes it from sibling tools like markets.trending or markets.discover, 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 Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It does not mention when to avoid it or suggest other tools for different needs (e.g., trending markets or search).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It fails to disclose behavioral traits like rate limits, authentication needs, or side effects. Only the purpose is stated, omitting any operational constraints or return 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loads the core purpose in the first sentence, and adds a use-case in the second. Every word is efficient with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description is moderately complete: it explains inputs and purpose but lacks information about the output format or pagination. With three parameters and no required fields, it could hint at what the response looks like.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with each parameter having a basic description. The tool description adds context about 'related' markets and use cases, but does not significantly enhance understanding beyond the schema since the schema already conveys parameter meanings clearly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Find' and the resource 'Polymarket markets', and distinguishes the tool by specifying the two modes of relating (by condition_id or topic keyword). It also notes utility in discovering correlated markets, differentiating it from sibling tools like markets.search or markets.featured.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when wanting related markets ('useful for discovering correlated markets...') but does not explicitly state when not to use or compare to alternatives such as markets.search or markets.trending. The guidance is present but lacks exclusion criteria.
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?
Discloses that changes are immediate and persistent, which is key behavioral info. However, with no annotations, the description should also mention potential side effects (e.g., bot behavior changes, validation of values) and any access controls. Missing details on error handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two direct sentences, no fluff. Front-loaded with action and resource. Could be more structured (e.g., bullet points) but remains efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 2-parameter tool with no output schema, the description covers purpose, supported keys, effect timing, and persistence. No major gaps. Error handling or value validation could be added but are not critical given tool simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema already provides 100% coverage on both parameters. The description adds only a brief mention of the keys and implies string format for value, but does not add significant meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clear verb 'Update' with specific resource 'bot configuration' and mention of supported keys. Distinguishes from sibling config tools (e.g., config.dashboard, config.history) by focusing on runtime mutation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool vs alternatives like config.dashboard or config.safety_limits. Does not state prerequisites, limitations, or when not to use. Only says 'Pro feature' as a vague access hint.
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 provided, so the description carries the full burden. It discloses it is a read operation and describes source (CLOB order book) and conditional behavior. However, it does not mention side effects, rate limits, data freshness, or permissions. 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences that are concise and front-loaded with the main purpose. Every sentence adds value with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description does not mention the return format or what fields (e.g., bid, ask, spread, position value) the response contains. This is a gap for completeness. Otherwise, it covers the main use cases adequately.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, baseline 3. The description adds meaning: explains the condition_id as Polymarket market condition ID and the show_positions parameter's effect. It also describes the interactive behavior when both parameters are used, which adds value beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it gets live bid/ask/spread prices from the CLOB order book for a specific market by condition_id, which is a specific verb and resource. However, it does not explicitly distinguish from siblings like markets.watch_price, which also involve prices.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: use condition_id for specific market, or omit with show_positions=true for all open positions. But it does not give explicit guidance on when to use this vs. other price-related tools (e.g., watch_price, trends) or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It states the tool 'analyzes' and 'generates recommendations', implying it is read-only (no modifications). However, it does not explicitly state that it does not alter positions or the portfolio, which would be helpful for an AI agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (two sentences), front-loaded with the core purpose, and each sentence adds value. No unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple schema (one optional parameter, no output schema), the description sufficiently covers the tool's functionality and output. It lists what it returns but could elaborate on the meaning of 'cut/hold/take-profit actions' for full clarity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'strategy' is fully described in the input schema (100% coverage). The description adds context by linking the strategy to the optimization but does not provide additional meaning beyond what the schema offers.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it analyzes open positions and generates optimization recommendations, specifying the output types (SL/TP suggestions, warnings, actions). It distinguishes from siblings like portfolio.risk by focusing on optimization. However, it does not explicitly differentiate from all related tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when you have open positions and need optimization, but does not provide explicit when-to-use or when-not-to-use guidance, nor does it mention alternative tools like portfolio.risk or positions.list for comparison.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that watched wallets are monitored for trades when the monitor is running, which is helpful. However, it does not describe side effects (e.g., duplicates, overwrites), error conditions, or authentication requirements, leaving gaps for an agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences that front-load the action and resource. It avoids redundant details. Slightly more structure (e.g., separating add from remove) could improve readability, but it remains efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (3 params, no output schema, no annotations), the description provides sufficient purpose and a usage hint. However, it omits return value details, error handling, or verification steps, which would help an agent fully utilize the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% parameter description coverage, with clear descriptions for address, alias, and action. The tool description adds no additional parameter-level information beyond the schema. Given high schema coverage, the baseline is 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool adds or removes an Ethereum wallet address from the copy trading watchlist, specifying the resource and actions. While it covers both add and remove, it does not explicitly differentiate between them beyond referencing the action parameter, and the sibling tools watchlist.list and watchlist.rebalance are distinct enough.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear usage guideline by recommending using discover_traders first to find good wallets. It also mentions that monitored wallets are watched when the monitor is running, giving context. However, it lacks explicit when-not-to-use scenarios or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full disclosure burden. It outlines the basic scanning behavior and identifies that it is a Pro feature, but does not disclose additional traits such as whether it is read-only, performance considerations, or any potential restrictions beyond the Pro label.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences only: the first front-loads the main action, the second adds detail. No fluff, every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Description explains what the tool does and the type of signal identified, but lacks details on output format, result interpretation, or usage constraints. Given no output schema, more context on return values would be beneficial.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, providing baseline adequacy. The description adds no extra meaning beyond the schema definitions; parameters like top_traders and max_age_minutes are already well described in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool scans top leaderboard traders for smart money convergence signals, identifying markets with multiple top traders buying the same outcome. It distinctly describes the specific functionality and mentions it is a Pro feature, differentiating it from sibling tools like analysis.arbitrage or analysis.compare.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when seeking smart money convergence signals but does not provide explicit guidance on when to use this tool versus alternatives like traders.analyze or analysis.opportunity. No when-not or alternative tool mentions are included.
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 provided, so description must carry the burden. It lists output metrics (price, spread, etc.) but does not disclose if the tool is read-only, requires permissions, or triggers side effects. Since comparison is typically read-only, a neutral score is warranted.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with action and scope. Every sentence adds value: first states what it does, second lists outputs and use case. No filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, description adequately summarizes the return fields (price, spread, depth, volume, quality score). It misses details like format or sorting but covers essential output for a comparison tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema already describes the single parameter (condition_ids: array of strings, 2-5) with 100% coverage. Description reinforces the count but adds no additional semantics beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the action ('Compare') and resource ('Polymarket markets') with a specific scope (2-5, side by side). It distinguishes from siblings like analysis.quality (single market) or markets.price (single price) by emphasizing multi-market comparison.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Description suggests usefulness for choosing among similar options, implying when to use (comparing multiple markets). However, it does not explicitly state when not to use or name alternative tools for single-market analysis.
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 provided, so description carries full burden. It mentions returning price points and a sparkline visualization, and notes it's a Pro feature. However, it does not disclose rate limits, authentication needs, or behavior on missing data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core purpose, no unnecessary words. Efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description provides a reasonable hint about return values (price points + sparkline). It covers the key behaviors. Missing details like pagination or response size, but acceptable for a simple data fetch.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for both parameters. The description adds '1h to 1m' as a human-readable range, which is a slight addition but not significantly beyond the enum values in the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the action (Fetch), resource (historical OHLC price data for a market token), and flexibility (configurable time window). It distinguishes from siblings like markets.price (current price) and analysis.compare.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or when-not-to-use guidance compared to alternatives. 'Pro feature' hints at access restriction but doesn't help the agent choose this vs other analysis tools. Usage is implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions the output fields but does not describe pagination, sorting, rate limits, or behavior for empty queries. For a straightforward search tool, this is minimally adequate but lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no wasted words. The first sentence front-loads the core purpose, and the second provides actionable next steps. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple parameter set and lack of output schema, the description adequately explains what the tool returns and how to use the result. However, it omits details about result limits (beyond the limit parameter) and whether pagination is needed. Still, it is complete enough for most use cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so each parameter is already documented in the schema. The description does not add extra semantics beyond what the schema provides (e.g., the query parameter is simply mentioned). Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches Polymarket markets by keyword query, specifying the return fields (question, price, volume, condition_id). This distinguishes it from sibling tools like markets.featured or markets.trending, which are curated lists rather than keyword-based search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description advises using the returned condition_id with other tools (buy, get_price, analyze_opportunity), but does not provide guidance on when to choose this tool over alternatives like markets.discover or markets.events. There is no explicit when-to-use or when-not-to-use context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses it returns market question, price, and volume, but does not mention ordering, pagination, or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose, no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a list tool with 3 optional params and no output schema, it covers purpose, parameters, and return fields adequately. Could mention ordering direction but not essential.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema covers all parameters with descriptions (100% coverage). The description adds minimal extra meaning beyond restating schema info.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'list', the resource 'trending Polymarket markets', and distinguishes from siblings by specifying ranking by trading volume with configurable periods and category filtering.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for finding trending markets but does not explicitly guide when to use this over siblings like markets.featured, markets.discover, or markets.search.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It describes the removal action but does not explicitly state that changes are permanent or if confirmation is required. The dry_run parameter is mentioned in the schema, but the description could add more context about consequences.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no wasted words. It is front-loaded with the action and immediately followed by the usage context. Every sentence serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (3 required parameters, no output schema), the description covers the purpose, parameters, and use case. It could mention the return value or impact on the watchlist, but the schema descriptions already clarify the parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description does not add meaning beyond the schema's parameter descriptions, which already define min_score, min_win_rate, and dry_run accurately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (analyze and remove underperformers), the resource (traders on watchlist), and the criteria (conviction score or win rate below threshold). It is specific and distinguishable from sibling tools like watchlist.add or watchlist.list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description says 'Use to keep your watchlist focused on high-quality traders,' providing clear context. However, it lacks explicit when-not-to-use instructions or alternatives, e.g., if only viewing is needed.
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. It notes it's a 'Pro feature' but lacks details on side effects, rate limits, or authentication needs. The tool likely is read-only, but this is not stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loaded with the core purpose, then the return value, then the action to take. No wasted words; every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter discovery tool, the description adequately explains what it returns (current price, fair price, discount percentage). No output schema exists, but the description fills the gap well. Still, lacks details on result limits or pagination.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter (discount_pct) has high schema coverage with description in the schema itself. The description repeats the schema's meaning without adding new semantic context, so it meets but does not exceed the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it finds WTA tennis match markets on Polymarket where the favorite is discounted, returning price comparisons and discount percentage. This is specific and distinguishes it from siblings like wta.bid or markets.discover.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly advises to use place_stink_bid for acting on opportunities, providing clear next-step guidance. However, it does not mention when not to use or compare to alternative tools like traders.discover.
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 provided, so description carries full burden. It discloses two modes (live vs preview) and their effects, but lacks details on side effects (e.g., irreversible live order), prerequisites, error conditions, or return behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no wasted words. The core action is front-loaded, and the mode distinction is clearly stated.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, so description should explain return values, but it does not. It also fails to clarify partial sells, how to enable preview mode, or prerequisites like having an open position.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions already cover all three parameters (trade_id, condition_id, price) adequately. The description adds minimal extra value beyond the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool sells an open position using either trade_id or condition_id, and differentiates between live and preview modes. This distinguishes it from sibling tools like orders.buy or orders.cancel.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for open positions and provides two methods of identification. It does not explicitly state when not to use or mention alternatives, but context from sibling tools is sufficient for differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It states it's a read operation and mentions output fields, but lacks detail on error handling, data freshness, or behavior on invalid condition_id.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no filler: first states purpose and key parameter, second describes output and use case. Efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read tool with two parameters and no output schema, the description covers purpose, input, output fields, and a use case. Could mention sorting or return format but is largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, baseline 3. Description adds minor context about output (wallet address, position size, side) but largely restates schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'View the largest position holders...' with a specific resource and action. It distinguishes from siblings like analysis.flow or analysis.compare by focusing on holders and sentiment.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool ('gauging smart money sentiment'), but does not explicitly exclude alternatives or discuss when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must cover behavioral traits. It correctly states it is read-only and does not place trades, but omits details such as data freshness, rate limits, or behavior with insufficient data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, with the first sentence delivering the core purpose and the second clarifying safety. No extraneous information is present.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple parameter set and no output schema, the description adequately explains the tool's purpose and safety. However, it could be slightly more detailed about the return value (e.g., score with reasoning).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single parameter 'condition_id'. The tool description adds context that it is a Polymarket market condition ID, but does not provide additional semantic value beyond the schema description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it generates a BUY/SELL/HOLD recommendation for a Polymarket market, specifying the factors analyzed (price, spread, trend, liquidity). This verb+resource combination is specific and distinguishes it from sibling tools like analysis.arbitrage or analysis.compare.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly indicates use for analysis by stating it is 'read-only' and does not place trades. However, it lacks explicit guidance on when to use this tool versus alternatives (e.g., analysis.price_history for historical data) or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries full burden. It discloses key behaviors: real orders, real money, pro feature, and confirmation requirement (via schema). However, it does not address reversibility (can you switch back?) or failure behaviors, leaving some gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences long, no fluff, front-loaded with purpose and critical context. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema), the description is fairly complete. It covers purpose, prerequisites, and consequences. Lacking only optional details like reversibility or error handling, which are minor for this basic toggle.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the description does not add new semantic meaning beyond the schema's own description of the 'confirm' parameter. The description essentially repeats the schema's documentation, so no extra value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool switches from preview to live trading mode, using a specific verb ('switch') and resource ('mode'). It distinguishes itself from sibling config tools (e.g., config.set, config.dashboard) by focusing specifically on the go-live transition.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions prerequisites (API credentials configured in environment) and implications (uses real money, pro feature), which helps the agent decide when to use it. However, it does not explicitly state alternatives (e.g., staying in preview mode) or scenarios where it should not be used.
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 communicate behavioral traits. It states the tool records data to a database, implying a side effect. It does not detail whether it overwrites or appends, required permissions, or error handling. The instruction to call after each cycle suggests idempotency but isn't explicit. Adequate but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long with no unnecessary words. The first sentence states the purpose and data stored; the second provides usage timing. Every sentence adds value, making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple logging tool with no output schema, the description adequately covers purpose, when to use, and data stored. It lacks details on return values or side effects beyond recording, but given the tool's straightforward nature, this is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description summarizes parameters as 'PnL, win rate, positions, budget usage, and notes', providing a high-level overview that complements the detailed schema. It does not add significant new meaning beyond the schema, but it helps identify the most important parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Record', the resource 'an AI agent's trading cycle metrics to the database', and the purpose 'for dashboard tracking and performance analysis'. It also lists key data stored (PnL, win rate, positions, etc.), effectively distinguishing it from sibling tools like config.dashboard or config.set which focus on configuration rather than logging.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to call the tool: 'Call this after each automated trading cycle.' This provides clear usage context. However, it does not mention when not to use it or suggest alternatives, which would improve the score further.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses persistence and enforcement scope, but lacks details on authorization needs, error behavior if limits are exceeded, or whether changes are incremental or full replacements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no redundant information. The description is front-loaded with the action and resource, followed by behavioral notes, making it easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 6 optional parameters and no output schema, the description covers core purpose and behavior. However, it omits what the tool returns (e.g., success message or updated limits) and does not clarify that all parameters are optional.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description mentions three parameters (max order size, exposure cap, spread) but adds no extra meaning beyond the schema. Other params like max_per_market and min_liquidity are not elaborated.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Configure' and the resource 'trading safety guardrails', specifying three concrete limit types. This distinguishes the tool from siblings like config.dashboard or config.set, which focus on different aspects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: limits are enforced on all subsequent buy/sell operations and persist in the database. However, it does not explicitly state when not to use this tool or mention alternative tools like config.set or config.go_live.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must convey behavior. It discloses the three actions and their effects (start streaming, stop, check status). However, it lacks details on connection management, error handling, or how updates are delivered after subscribing, leaving some behavioral aspects 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences that front-load the purpose and enumerate actions. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter tool with no output schema, the description covers the core actions and parameter conditions. It could mention the WebSocket update channel after subscribing, but given the low complexity, it is nearly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the schema descriptions already clarify the enum values and token_id requirement. The tool description adds no new parameter information beyond what is in the schema, so it does not increase semantic value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool's purpose: managing live WebSocket price subscriptions. It specifies the resource (price updates) and the actions (subscribe, unsubscribe, status), making it easily distinguishable from siblings like 'markets.price' (single fetch) and 'markets.watch' (watchlist).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states the context for using the tool ('real-time market updates') and the three actions. While it does not explicitly mention when not to use or compare with alternatives, the context is clear enough for an agent to decide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that automatic closing happens via check_exits when price crosses levels, but omits details such as what happens when both orders are set (which triggers first) or whether existing exit rules are replaced.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, each serving a distinct purpose: stating the action, explaining the automatic mechanism, and providing a usage hint. No unnecessary information, efficiently front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (3 params, no output schema), the description covers the core functionality, automatic behavior, and a key prerequisite. It could mention that stop_loss and take_profit are optional (implied by schema) and whether setting new rules overwrites old ones, but it is largely sufficient for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, so the baseline is 3. The description adds value by directing users to get_positions for the trade_id but does not significantly enhance the schema descriptions for stop_loss and take_profit, which already include examples.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Set') and resource ('stop-loss and/or take-profit price levels on an open position'). It further explains the automatic closing behavior via check_exits, distinguishing this tool from manual close operations. The purpose is specific 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 Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly advises using get_positions to find trade IDs, providing a clear prerequisite. It also labels the feature as 'Pro'. However, it does not explicitly contrast this tool with alternatives like orders.sell or positions.close for immediate vs automated exit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully convey behavioral traits. It describes what it returns but does not mention read-only nature, rate limits, authentication, or data freshness. However, for a simple analysis tool, it is reasonably transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no wasteful language. The first sentence states purpose and outputs, the second provides usage guidance. Well-structured and concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool without output schema, the description lists key return values. It lacks error handling details but is sufficient for typical use. Adequate for the complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the description adds no additional meaning beyond what the schema provides (wallet address). The description's mention of 'by wallet address' is redundant.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the tool's action (Analyze a Polymarket trader), the resource (wallet address), and the outputs (profile stats, active positions, win rate, volume, PnL, recent trade activity). This distinguishes it from sibling tools like traders.backtest, traders.discover, and traders.score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use the tool: 'Use before adding a trader to your watchlist to assess their quality.' This provides clear context, though it does not mention when not to use or list alternatives.
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 bear full burden. It correctly states the tool performs a simulation ('hypothetical P&L') and is non-destructive. However, it lacks disclosure on potential limitations like data latency, rate limits, or 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise—three sentences front-loaded with the main purpose. Every sentence adds value: purpose, when to use, and a feature designation. No redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simulation tool with no output schema, the description gives sufficient context for an AI agent to understand its function and usage. It could optionally detail the return value format, but the core purpose is clear.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already covers both parameters with descriptions (address and copy_budget). The description adds minimal extra meaning beyond restating defaults (e.g., '$5 default'). Since schema coverage is 100%, the baseline is 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: simulate copy-trading a trader's historical trades to calculate hypothetical P&L. It uses a specific verb ('simulate', 'calculate') and resource ('trader's historical trades'), distinguishing it from sibling tools like traders.analyze or traders.score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly recommends using the tool 'before adding a trader to your watchlist to validate their performance', providing clear context for when to invoke it. It also notes it's a 'Pro feature', implying access restrictions, though it doesn't mention alternatives or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility. It discloses the read-like nature (fetching data) and mentions the auto_watch parameter can modify the watchlist. However, it does not discuss rate limits, pagination details, or other potential side effects, leaving some gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise with four short sentences, each adding unique value. It front-loads the core purpose and follows with usage guidance, return details, and a direct call to action for the auto_watch parameter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description provides essential return fields (address, PnL, volume, win rate). It also mentions the ranking metrics. However, it does not clarify the primary sort order or default filtering behavior, which would enhance completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% coverage of parameter descriptions. The description adds minimal extra meaning, only highlighting auto_watch as a convenience feature. It does not elaborate on how min_volume/min_pnl affect results or the default behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool fetches top traders from the Polymarket leaderboard, specifying the ranking metrics (PnL, volume, ROI). It also distinguishes itself from siblings like traders.analyze or traders.backtest by emphasizing leaderboard discovery and trader copying.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly suggests using this tool to find profitable traders worth copying, providing a clear use case. It does not directly compare with alternatives, but the context implies it is for broad discovery rather than individual analysis.
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 exist, so description must carry behavioral burden. It states 'current open positions' (read operation) and 'Pro feature' (subscription requirement). Does not detail rate limits, data freshness, or behavior on no positions. Adequate but could be more explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: first states action and resource, second adds specifics and use case. No fluff, every sentence adds value. Efficient and clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool is simple (2 params, no output schema). Description covers input (address, limit) and output (market name, outcome, size, current price). Lacks details on pagination or empty results, but overall sufficient for a straightforward tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 100% coverage with descriptions for both parameters. The description adds context ('by their wallet address') and output fields, but the schema already documents the parameters well. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Describes a clear verb (View) and resource (another trader's open positions on Polymarket), and lists the fields shown (market name, outcome, size, current price). Distinguishes from sibling tools like positions.list (own positions) and traders.analyze.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit context: 'Useful for due diligence before copy trading.' Implies when to use this tool. No direct exclusions or alternative recommendations, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that orders sit until filled and differentiates preview/live modes, but does not cover order lifetime, cancellation, or failure handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core action and resource. Every sentence adds value, with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given only two parameters and no output schema, the description covers purpose, mode, and access (pro). It lacks details on order lifecycle, but is fairly complete for a simple bidding tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the description largely restates the schema definitions (discount below fair price, USDC amount). It adds the concept of 'stink bids' but offers no additional semantic detail beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('place limit orders'), resource ('WTA tennis match favorites'), and mechanism ('at a discount'). It distinguishes itself from general order tools by specifying WTA tennis and the stink bid concept.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when orders sit in the book, and mentions preview vs live modes and pro status. However, it does not explicitly state when not to use this tool or compare it to alternative order types.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It states the tool scans markets and returns price gap and profit percentage, implying a read-only operation. No contradictory or missing behavioral traits are apparent, though it could mention that no modifications occur.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the core action and condition, followed by a brief output note. No extraneous information is included.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description explains the tool's function and return fields but lacks detail on the output structure (e.g., list of objects, sorting order). Without an output schema, more specificity would improve completeness for agent usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with both parameters described in the schema. The tool description adds context that the min_spread refers to the price gap from $1 and that profit percentage is returned, slightly enhancing understanding beyond the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'scan' and clearly identifies the resource as 'active Polymarket markets' and the condition 'YES + NO prices don't sum to $1.00'. It distinguishes itself from sibling analysis tools like analysis.opportunity by focusing specifically on arbitrage based on price sum discrepancies.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for arbitrage detection but does not explicitly state when to use or avoid this tool, nor does it mention alternatives among the numerous sibling analysis tools. The context is clear only by the tool's name and description, lacking explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It describes a read-only evaluation (no mutation) and mentions return format, but does not explicitly state non-destructiveness, auth requirements, or rate limits. Adequate but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no redundancy. The first covers function and output, the second offers usage guidance and flags 'Pro feature'. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 3 well-documented parameters and no output schema, the description sufficiently explains the return type (pass/fail with reasons) and usage context. It omits edge cases but covers the primary workflow.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% coverage, providing descriptions for all parameters. The description adds context by linking parameters to the checks (spread, depth, price range), reinforcing their purpose beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool evaluates market quality by checking bid/ask spread, order book depth, and price range, returning pass/fail with reasons. This specific verb-resource pairing distinguishes it from siblings like 'analysis.arbitrage' or 'analysis.compare'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly advises using the tool before placing trades to avoid illiquid or wide-spread markets, providing clear context. While it doesn't list exclusions or alternatives, the sibling names implicitly guide when to use other 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, description carries full burden. It states outputs (question, price, volume, end date) but omits details like read-only nature, pagination behavior, or rate limits. Adequate but not exhaustive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, highly efficient: first sentence defines purpose and outputs, second provides actionable usage tip. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 4 simple parameters and no output schema, the description covers core purpose, outputs, and parameter guidance. Missing details like sorting order or 'active' definition, but sufficient for tool selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (baseline 3). Description adds value by explaining the 'ending' enum options with practical examples (e.g., 'today' for fast-resolving) and listing example categories for the 'category' parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states verb 'Find', resource 'active Polymarket prediction markets', and lists returned fields. Distinguishes from siblings like markets.search and markets.featured by its focus on deadline and category filtering.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides specific usage tip for the 'ending' parameter ('use ending='today' for fast-resolving markets'), but does not explicitly compare to alternative tools like markets.search or markets.trending.
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 provided, so description carries burden. Discloses that crossing alert price triggers check_exits. Does not detail idempotency, error handling, or authorization needs. 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no fluff. Front-loaded with purpose and key actions. Highly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, but description provides context for return values indirectly (checkbox in check_exits). Covers basic functionality. Slightly lacking in clarifying defaults (e.g., action defaults to 'list') but schema handles that.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers all parameters with descriptions. Tool description adds context about alert thresholds and ties to check_exits, enhancing meaning beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the verb 'manage' and resource 'market watchlist', specifies actions (add/remove/list) and the key feature of price alerts linked to check_exits. Distinguishes from siblings like watchlist.add/list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Tells when to use: for watchlist management with optional alerts. Implicitly suggests check_exits for alert outcomes. Does not explicitly exclude alternatives but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states the max 10 orders and that results are per-order with success/failure status. It does not disclose atomicity, partial failure behavior, or execution guarantees, which are important for a batch mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, no fluff, front-loaded with the core purpose. Every word adds value, and it is easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description covers return format (per-order results with status). It also specifies the max 10 orders limit. Missing details about error handling or ordering guarantees, but overall sufficient for a batch operation with good schema and sibling context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single parameter 'orders'. The description adds meaning by clarifying that condition_id is a hex string, amount is in USDC, price is a limit price (or omitted for market), and side is BUY/SELL. This enriches the schema's basic descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool executes multiple buy/sell orders in a single call with a max of 10 orders. It uses specific verbs ('Execute') and resource ('buy/sell orders'), and the constraint distinguishes it from single-order siblings like orders.buy and orders.sell.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for batching multiple orders, contrasting with single-order tools (orders.buy, orders.sell). However, it does not explicitly state when not to use it or provide alternatives, leaving some ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description indicates the tool is read-only ('View') and has no parameters. In the absence of annotations, this is adequate. No mention of auth requirements or side effects, but for a simple balance view, the description is sufficiently transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise, consisting of two short sentences that cover purpose, content, and usage guidance. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and the absence of output schema, the description provides enough context for an agent to use it effectively. It could mention that it returns a summary, but current content is mostly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameters, so the description cannot add parameter semantics. Schema description coverage is 100% (trivially). Baseline 3 applies because parameters are absent, and the description does not need to elaborate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: viewing account balance summary including specific metrics (daily budget remaining, total invested, realized/unrealized P&L). It distinguishes from sibling tools by noting that no parameters are needed and provides a specific use case.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit guidance on when to use the tool: 'Use this to check how much budget is left before placing new trades.' While it does not mention when not to use or alternatives, the guidance is clear and sufficient for a simple read-only tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It clearly states the tool assesses risk and returns a score with warnings, implying a read-only operation. However, it does not explicitly confirm no side effects, though 'assess' and 'returns' strongly suggest non-destructive behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loads the key dimensions, and contains no redundant information. Every word adds value, achieving maximum conciseness for the intended functionality.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters and no output schema, the description adequately covers purpose and output. It mentions four dimensions and that a risk score with warnings is returned. Minor missing details like score range or warning types would be nice but are not critical for a no-param tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, and the schema coverage is 100% trivially. The description adds 'No parameters needed', confirming the schema. Per guidelines, baseline for 0 params is 4, and the description matches this expectation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool assesses portfolio risk across four specific dimensions (concentration, diversification, coverage, budget utilization) and returns a risk score with warnings. This clearly distinguishes it from sibling tools like portfolio.get or portfolio.optimize.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is provided on when to use this tool versus alternatives. While the description implies it's for risk assessment, it doesn't contrast with siblings such as portfolio.optimize or portfolio.balance, leaving the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses destructive behavior (closing positions, updating P&L) but omits details like authorization needs, irreversibility, or failure scenarios.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: first explains purpose, second confirms no parameters. No wasted words, front-loaded with key action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, description explains the action but doesn't mention return value (e.g., list of closed positions). Otherwise complete for a zero-parameter tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has zero parameters with 100% coverage. The description adds 'No parameters needed,' confirming no user input. Baseline 4 is appropriate as schema fully covers params.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool scans all open positions for exit conditions (market resolution, stop-loss/take-profit, trader exiting) and updates P&L/closes positions. It distinguishes from siblings like positions.list and positions.close by being a batch check/action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It notes 'No parameters needed,' implying automatic execution. However, it doesn't explicitly contrast with manual tools like positions.close or positions.set_exit_rules, leaving when-not ambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the return value: 'Returns the event with all its sub-markets and their current prices.' No annotations are provided, so the description carries the burden. It implies a read operation but does not explicitly state read-only or discuss 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no fluff: first states the action, second states the output. Perfectly front-loaded and concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple data retrieval tool with 3 optional params and no output schema, the description is sufficient. It explains the action and return value clearly. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the input schema already documents the three parameters with clear descriptions. The description adds overall context but no additional meaning beyond the schema. Hence baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Browse Polymarket event groups to find all markets under a single event' with concrete examples like 'US Election'. It uses specific verbs and distinguishes from sibling tools like markets.search and markets.featured.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool (to find all markets under a single event) but does not explicitly state when not to use it or provide alternatives. However, the context is clear enough for an agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that it runs a market quality check, has preview and live modes, and places a real CLOB order. No annotations were provided, so the description carries the full burden. It does not detail failure behavior or auth needs, but the core behaviors are clear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences, no filler. Front-loaded with purpose, then parameter details, then mode behavior. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and 4 parameters, the description covers key aspects but does not explain return values or error handling. It is adequate but could specify what the tool returns (e.g., order ID, status) for full completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the description adds context about optional limit price and mode behavior (preview vs live). This supplements the schema descriptions with operational meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool buys outcome shares on Polymarket, specifying the action and resource. It includes key parameters (condition_id, amount, price, outcome) and distinguishes from sibling 'orders.sell'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains preview vs live mode and optional limit price, providing context for when to use each. However, it does not explicitly state when not to use this tool or compare to alternatives like market vs limit orders.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but description details behavioral differences between live mode (places sell order on Polymarket) and preview mode (marks closed in DB). Discloses core side effects, though could mention error handling or position state checks.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Description is three sentences with no wasted words. Front-loaded with action, then mode differences, then prerequisite, then access note. Every sentence serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, so description should explain return value. It describes actions but not what the tool returns upon success/failure. Lacks info on preconditions like position must be open. Adequate for a simple close action but missing output behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% description coverage for both parameters. Description reinforces trade_id sourcing from get_positions and mentions default reason. Adds value beyond schema by providing context on how to find trade_id.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool closes a copy trading position by trade ID, distinguishes between live and preview modes, and references get_positions for finding trade_id. This provides specific verb+resource differentiation from siblings like positions.list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly mentions it's manual closing, references get_positions for prerequisite, and states 'Pro feature' indicating access restrictions. Does not explicitly exclude alternatives, but context implies it's for manual closure vs automated exit rules.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the full burden. It discloses the score range, five dimensions, and the 'Pro feature' access restriction. It implies read-only behavior through 'Calculate,' though side effects are 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that conveys purpose, dimensions, output range, and usage context without any redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple scoring tool with one parameter, the description covers purpose, output (score 0-100), dimensions, usage context (copy trading), and access restriction (Pro feature). No output schema is needed given the explicit score range.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single parameter 'address,' which is already well-described in the schema. The description adds no new parameter-level information beyond what is in the schema, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool calculates a conviction score (0-100) for a trader across five dimensions, differentiating it from sibling tools like traders.analyze or traders.discover by specifying a scoring function focused on copy trading reliability.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context for when to use the tool ('Higher scores indicate more reliable traders for copy trading') and notes it's a 'Pro feature,' implicitly guiding usage. However, it lacks explicit exclusions or alternatives among sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full behavioral burden. It describes a safe read operation showing various data, but does not clarify if data is real-time or cached, or any 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences that front-load the purpose and include essential usage hints. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Complete enough for a simple dashboard tool: describes purpose, contents, and usage. Lacks details on output format but acceptable given no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has zero parameters with 100% coverage (empty schema). The description adds value by confirming no parameters needed and explaining the context, exceeding the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get a comprehensive dashboard' and lists specific contents (daily budget usage, total P&L, etc.), distinguishing it from sibling tools which are configuration or monitoring focused.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'No parameters needed' and recommends use for a 'quick overview', but does not mention when to avoid or specify alternatives among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but description discloses it is a read-only view operation returning specific fields, no destructive behavior. Could mention rate limits but sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Single concise sentence that front-loads the action and filter, contains no unnecessary words. Efficient and clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with one parameter and no output schema, the description covers functionality, return fields, and filter options completely.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning to the status parameter beyond the schema by explaining each enum option (open=active, closed=resolved/exited, all=both). Schema coverage is 100% but description adds value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists copy trading positions with filtering by status, differentiating it from sibling tools like positions.check_exits and positions.close.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It explains the filter options (open, closed, all) and implies this is for viewing positions. Lacks explicit when-not-to-use but is adequate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses background loop, continuous polling, automatic copying, and polling interval. However, it doesn't mention risks of automatic trade copying or cost implications, which is a minor gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three short, front-loaded sentences with no redundancy. Each sentence provides distinct value: action, lifecycle, and prerequisites.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers core behavior, lifecycle, prerequisites, and feature level. Lacks details on what 'automatically copies them' entails (e.g., default settings), but is sufficient for a simple start command.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the only parameter (interval_seconds). The description adds value by explaining the parameter's purpose ('Runs continuously at the specified interval'), linking it to the operation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool starts a background loop to poll wallets and copy trades, with a specific verb ('Start') and resource ('background loop'). It distinguishes from sibling 'monitor.stop' by explaining the lifecycle.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit context: runs continuously until stop_monitor is called, requires at least one wallet on watchlist, and is a Pro feature. This gives clear when-to-use and prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so description carries full burden. It discloses the tool is read-only (no mention of side effects) and describes the output as a grouped markdown table. Could be clearer about scope (only open positions) or permissions, but sufficient for a simple get.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, each serving a purpose: main function, usage guidance, and output format. It is concise but not overly terse. Slightly verbose with the detailed list, but all information is valuable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters, no output schema, and a straightforward read operation, the description thoroughly covers what the tool returns (grouped positions, per-wallet subtotals, individual fields, aggregate P&L) and its output format (markdown table). No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters defined, so baseline is 4. Description adds no param information, which is acceptable as there are none.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves a comprehensive portfolio overview of all open copy-trading positions, grouped by source trader, with detailed per-wallet data and aggregate P&L. It distinguishes itself from siblings like portfolio.balance and portfolio.risk by naming them and contrasting their focus.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly provides when to use: 'as a daily status check, before sizing decisions via config.set, or to identify which source wallet is carrying the portfolio.' Also directs to alternatives: portfolio.balance for budget numbers, portfolio.risk for concentration metrics.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that it returns status, filled amount, remaining size, price, and market, implying it is a read-only check. However, it does not explicitly state that it is non-destructive or that it does not modify state, which would further improve transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is four sentences, with the first sentence clearly stating the purpose. Every sentence adds value (usage guidance, return values, input source, constraint) without unnecessary words. It is well-structured and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has one simple parameter, no output schema, and no annotations, the description is complete. It covers purpose, usage guidelines, parameter context, return values, and a constraint. An agent can use this tool correctly without additional information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes the order_id parameter with 100% coverage. The description adds context by explaining how to obtain the order_id ('from the response of the placing tool or from orders.list'), which goes beyond the schema's basic description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the verb 'check' and the resource 'live state of a specific Polymarket limit order by its order_id', and distinguishes itself from siblings like orders.buy or orders.cancel by explaining its use case for tracking fill progress or verifying cancellation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool: after orders.buy, orders.batch, or wta.bid to track fill progress, or to verify an orders.cancel call. It also mentions obtaining the order_id from the placing tool's response or from orders.list, and notes the constraint 'Only works in live mode'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description adequately discloses behavior: it is a read-only operation returning a markdown table. However, it does not explicitly confirm no side effects or mention rate limits, which would be ideal for full transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured: purpose first, then usage context, output format, and alternative tools. Every sentence adds value with no redundant text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no parameters, the description fully captures the tool's functionality, output format, and integration with sibling tools like monitor.start and watchlist.rebalance, making it complete for its simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, and the description correctly states 'No parameters.' Since schema coverage is 100% and no additional param information is needed, this meets the baseline for zero parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: displaying watchlist wallets with alias, date added, and status. It distinguishes itself from siblings like watchlist.add and traders.discover by specifying their different roles.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly provides when to use the tool (e.g., before monitor.start, after rebalance) and refers to alternatives (watchlist.add, traders.discover) for other actions, offering strong workflow guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavior: stops monitoring loop, does not close positions, idempotent, returns short confirmation string, no parameters, Pro feature. No behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Five sentences, each adding distinct value: purpose, usage guidance, exclusions, idempotency, return value, feature classification. No redundant or wasted text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and 0 parameters, the description is fully complete. It covers all necessary information for an agent to use this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has 0 parameters, so no param details needed. Description correctly states 'No parameters'. Baseline for 0 params is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it stops the background wallet monitoring loop started by monitor.start, using a specific verb and resource. It distinguishes itself from sibling tool monitor.start by describing its opposite action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says when to call: to end a copy-trading session, before changing bot configuration, switching between preview and live modes. Also states what it does NOT do (close positions) and suggests alternatives (positions.close, positions.set_exit_rules). Mentions idempotency and safety when not running.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully covers behavior: irreversible, live-mode-only, returns count of cancelled orders, no parameters, pro feature. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Five well-structured sentences; action verb front-loaded. Every sentence adds value: purpose, use cases, constraints, return info, and procedural suggestion. No redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no params, no output schema), the description is complete—covers purpose, usage, side effects, return value, and mode restrictions. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist (schema is empty, coverage 100%). Baseline is 4 for zero parameters. Description explicitly states 'No parameters', which adds clarity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Cancel') and resource ('ALL open/pending limit orders on Polymarket for this account in a single call'). It distinguishes from siblings by naming alternative re-placement tools (orders.buy, wta.bid, orders.batch) and preview suggestion (orders.list). No ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly lists when to use: emergency stop, before strategy change, after price move, unwinding positions. Also states it is not reversible and only works in live mode (no-op in preview). Provides clear guidance and alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description fully covers behavioral traits: indicates it is a read-only list operation, specifies it returns empty in preview mode, mentions it is a Pro feature, and lists the returned fields (ID, market question, side, size, limit price, age). No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each carrying essential information: action and scope, usage context, and behavioral notes. No filler words, front-loaded with the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters and no output schema, the description provides complete context: what the tool lists, when to use it, what it returns, limitations (live mode only), and a pointer to the alternative tool for deeper details. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has zero parameters, so schema coverage is 100%. Description adds value by explaining the output fields and the nature of the returned data, which compensates for the absence of parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description explicitly states 'List all open (pending/unfilled) limit orders currently resting on Polymarket's order book for this account.' The verb 'list' and resource 'orders' are clear. It distinguishes from siblings like orders.status (single order detail) and orders.cancel (preview cancellation targets).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit usage context: 'Use after placing limit orders via orders.buy or wta.bid to confirm acceptance, or before orders.cancel to preview what will be removed.' Also covers when not to use: 'For deeper detail on a single order, call orders.status' and notes the 'Only works in live mode' limitation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
GitHub Badge
Glama performs regular codebase and documentation scans to:
- Confirm that the MCP server is working as expected.
- Confirm that there are no obvious security issues.
- Evaluate tool definition quality.
Our badge communicates server capabilities, safety, and installation instructions.
Card Badge
Copy to your README.md:
Score Badge
Copy to your README.md:
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/demwick/polymarket-agent-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server