de en es ja ko ru zh

polymarket-trader-mcp

by demwick

Overview Schema Related Servers Score Discussions

TypeScript

Remote

Server Quality Checklist

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

Disambiguation4/5
Most tools have distinct purposes, though there is minor overlap between analysis tools (analyze_opportunity, detect_arbitrage, compare_markets) and portfolio tools (assess_risk, optimize_portfolio). The distinction between buy, batch_order, and place_stink_bid could confuse agents without careful reading.
Naming Consistency3/5
While most tools follow verb_noun convention (get_price, cancel_orders), there are significant deviations: buy and sell lack nouns (should be buy_shares/sell_position), trending_markets uses an adjective prefix instead of a verb, and find_related omits the object noun. Batch_order is ambiguous as noun or verb.
Tool Count4/5
22 tools is appropriate for a comprehensive trading platform covering market discovery, order execution, portfolio management, and real-time data. The scope justifies the count, though it approaches the upper limit where tool selection might require careful prompting.
Completeness3/5
Trading lifecycle is mostly covered (search, analyze, buy, sell, cancel), but there is a notable gap: sell references get_positions which doesn't exist as a tool, forcing reliance on condition_id. Missing order modification and dedicated position listing tools create friction, though workarounds exist.
Average 3.9/5 across 21 of 22 tools scored. Lowest: 3.2/5.
See the tool scores section below for per-tool breakdowns.
This repository includes a README.md file.
This repository includes a LICENSE file.
Latest release: v1.4.5
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.
View server inspector
This server provides 48 tools. View schema
No known security issues or vulnerabilities reported.
Report a security issue
This server has been verified by its author.
View related servers

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 but only discloses 'Pro feature' (access tier). Missing: whether this is read-only (implied by 'scan' but not stated), caching behavior, rate limits, or what the return structure contains (markets? signals? scores?).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three efficient sentences with zero waste. Action and scope are front-loaded; 'Pro feature' appropriately placed as constraint at end. Could combine sentences 1-2 for perfect flow but acceptable as-is.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for the 3-parameter input complexity, but no output schema exists and description fails to describe return values (signal format, market identifiers, conviction scores). 'Pro feature' partially compensates for missing annotation coverage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, establishing baseline 3. Description adds domain context mapping params to functionality ('top leaderboard traders' aligns with top_traders, 'simultaneously' implies max_age_minutes), but does not explain parameter interactions or why one might adjust defaults.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Excellent specificity with 'scan for smart money convergence signals' and 'identifies markets where multiple top traders are buying the same outcome simultaneously'—clearly distinguishes from generic discover_markets or discover_traders siblings via the convergence mechanism.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Only provides a constraint ('Pro feature') rather than guidance. No mention of when to prefer this over analyze_opportunity, discover_traders, or compare_markets, nor prerequisites like authentication tier.
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 disclosure burden. It successfully explains the ranking algorithm (liquidity-based) which defines 'featured,' but omits read-only safety status, rate limits, or pagination behavior that would be necessary for a complete behavioral picture.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences logically ordered: first defines the operation and parameters, second reinforces the return criteria. Minor redundancy between 'ranked by liquidity' and 'most liquid...markets' costs a point, but otherwise front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a simple read-only listing tool with rich schema coverage. However, lacks description of return value structure (markets as objects vs IDs) which is absent from the output schema, and misses critical sibling differentiation needed to navigate the extensive tool catalog.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, establishing a baseline of 3. The description lists the category enum values explicitly ('politics, sports...'), providing redundant confirmation of the filter options, but does not add semantic depth regarding parameter interactions or the consequence of omitting the optional category filter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clear verb ('List') + resource ('Polymarket markets') + ranking criteria ('ranked by liquidity'). Explicitly defines what 'featured' means via liquidity and active trading metrics. However, it does not explicitly differentiate from siblings like 'trending_markets' or 'search_markets' which likely return similar data with different sort orders.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus the numerous sibling discovery tools (search_markets, trending_markets, discover_markets, compare_markets). Mentions 'optional' filter implying flexibility, but provides no decision framework for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It fails to explain how 'related' is determined (semantic similarity? correlation? tags), what the return structure looks like (since no output schema exists), or any rate limiting/performance characteristics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two well-structured sentences with zero waste. First sentence establishes core function, second provides concrete use cases. Appropriately front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate baseline coverage for a 3-parameter discovery tool, but gaps remain: no output schema means return values should be described, and the mutual exclusivity/composition of inputs needs clarification given both are optional with no required parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 67% (limit lacks description). Description maps the two main parameters (condition_id/query) to the 'condition_id or topic keyword' concept, but doesn't clarify their interaction (XOR vs. AND) or explain the limit parameter's role in pagination.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description provides specific verb (Find) + resource (Polymarket markets) + scope mechanism (condition_id or keyword). The term 'related' distinguishes it somewhat from siblings like 'search_markets' or 'discover_markets', though it could explicitly clarify when to prefer this over general search 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides use case examples ('discovering correlated markets', 'building diversified positions'), but lacks explicit when-not-to-use guidance or comparison with sibling alternatives. The 'or' between condition_id and query hints at parameter relationship but doesn't clarify if they're mutually exclusive.
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 return content (entry price, P&L, market info) and licensing status (Pro), but omits safety characteristics (read-only nature), pagination behavior, or data freshness that would be necessary for a mutation-safe understanding.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with zero waste: first defines the operation, second describes returns, third states access tier. Information is front-loaded and every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Complete given the simple parameter structure and 100% schema coverage. The description compensates for the missing output schema by enumerating return fields. Minor gap: does not note that all parameters are optional despite having zero required fields.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, establishing a baseline of 3. The description mentions the filters exist ('optional filters by trader address or status') but adds no syntax, format, or usage guidance beyond what the schema already provides for limit, trader, and status parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action (retrieve), resource (past copy trades), and scope (from the database). It distinguishes from siblings by specifying 'past' trades versus current positions (get_positions, get_trader_positions) and 'copy trades' as a specific domain.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
While it notes this is a 'Pro feature' indicating access tier, there is no explicit guidance on when to use this versus sibling tools like get_trader_positions or get_open_orders, nor when to apply specific filters.
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 successfully discloses that 'changes persist in the database' and that enforcement applies to future operations. However, it omits critical behavioral details like what happens when limits are violated (error vs. silent block) or whether existing open positions are affected.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three well-structured sentences with zero waste. Front-loaded with specific parameters and behavioral implications. Every sentence earns its place by covering configuration scope, enforcement timing, and persistence.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 6 parameters with full schema coverage and no output schema, the description adequately covers the core functionality. However, with 30+ sibling tools including similar configuration tools, the absence of comparative context and missing details on failure modes leave gaps that prevent a higher score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, establishing a baseline of 3. The description mentions three specific parameters (max order size, exposure cap, spread tolerance) but does not add semantic value beyond the schema (e.g., explaining partial update behavior, the relationship between max_exposure and max_per_market, or that all parameters are optional).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool configures 'trading safety guardrails' with specific parameters (order size, exposure cap, spread tolerance). However, it does not explicitly differentiate from similar sibling tools like 'set_config' or 'set_exit_rules', which would help disambiguate when to use each.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides context that limits are 'enforced on all subsequent buy/sell operations,' indicating when the configuration takes effect. Lacks explicit guidance on when NOT to use this (e.g., vs. set_exit_rules) or prerequisites (e.g., requiring trading authorization).
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 successfully discloses the 10-order limit and partial execution behavior ('Returns per-order results with success/failure status'), but lacks critical execution semantics like atomicity guarantees, rate limiting, or whether failed orders halt subsequent processing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences appropriately sized and front-loaded with the primary purpose. The second sentence lists parameters which is somewhat redundant given 100% schema coverage, but the return value disclosure in the third sentence is valuable given the absence of an output schema. Minimal waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a financial mutation tool with nested parameters, the description adequately covers the batch constraint and return structure (compensating for no output schema). However, it omits execution safety details—such as rollback behavior, idempotency, or balance prerequisites—that are important for a trading tool with no annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, establishing a baseline of 3. The description lists order fields ('condition_id, amount, optional price, and side') but adds no semantic value beyond what the schema already documents (e.g., doesn't explain USDC denomination, hex format requirements, or position opening/closing semantics already in the schema).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Execute multiple buy/sell orders in a single call (max 10 orders)', providing a specific verb, resource, and scope limit. It effectively distinguishes this from the sibling tools 'buy' and 'sell' (which handle single orders) by emphasizing the batch/multiple aspect.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
While the phrase 'in a single call' hints at efficiency benefits, the description lacks explicit guidance on when to choose this over individual buy/sell calls, or prerequisites like sufficient balance requirements. Usage is implied but not stated with explicit when/when-not 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?
Since annotations are absent, description carries the burden. It discloses return fields (market name, entry price, P&L, etc.) which is valuable given no output schema, and 'View' implies read-only. However, lacks details on pagination behavior, rate limits, or data freshness/synchronization status.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tightly constructed sentences. First sentence covers purpose and parameter; second covers return values. No filler words, tautologies, or redundant information. Appropriately front-loaded with action verb.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter read tool with no output schema, the description adequately compensates by listing specific return fields. However, as a positions listing tool, it should mention pagination behavior or result limits to be fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (status parameter fully documented with enum and description). Description mentions 'filtered by status' which aligns with the schema but adds no additional semantic context (syntax examples, default behavior implications) beyond what the structured schema already provides. Baseline 3 appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Uses specific verb 'View' with explicit resource 'your own copy trading positions'. The phrase 'your own' clearly distinguishes this from sibling tool 'get_trader_positions' (which likely queries other traders), and 'copy trading' provides specific domain context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Describes the status filter functionality but provides no guidance on when to use this tool versus alternatives like 'get_portfolio' (aggregate view) or 'get_trader_positions' (social trading). No mention of prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It successfully discloses the live/real-time nature and the branching behavior based on parameter combinations, but omits safety characteristics (read-only), rate limits, error handling, or return structure details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tightly constructed sentences with zero waste. The first sentence front-loads the primary action and resource; the second sentence efficiently covers the conditional alternate behavior.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a 2-parameter tool with complete schema coverage, but gaps remain. The description mentions the return value for the conditional case (all open positions) but does not describe the standard return structure or format, which would be helpful given the lack of output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema coverage, the baseline is 3. The description adds value by explaining the interaction logic between condition_id and show_positions (the 'if no condition_id given and show_positions is true' clause), which clarifies how to trigger the 'all open positions' mode beyond what the individual parameter descriptions convey.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the action (Get), resource (live bid/ask/spread prices), and source (CLOB order book), and identifies the lookup key (condition_id). However, it does not explicitly differentiate from similar market data tools like check_market or get_trade_history.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides implied usage guidance through the conditional logic explaining parameter interaction (omitting condition_id with show_positions=true returns all open positions). However, it lacks explicit when-to-use guidance against sibling alternatives or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Valuably discloses live mode (places order on Polymarket) vs preview mode (database update with P&L calculation). Missing: conflict resolution if both IDs provided, error behavior if position not found, and whether operation is atomic/reversible.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two efficiently structured sentences. First covers action and identifiers; second covers operational modes. No redundant words. Front-loaded with essential selection info (identifiers) before operational details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a 3-parameter tool with full schema coverage. Describes side effects (database updates, order placement). Gaps: mutual exclusivity/priority of identifiers not addressed, and no mention of output/return value despite mutation status.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, baseline 3. Description adds critical context beyond schema: trade_id sourcing from get_positions, and the behavioral impact of live vs preview modes on execution. This semantic context helps agents understand parameter usage implications.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clear verb 'Sell' and resource 'open position'. Specifies two identification methods (trade_id from get_positions, or condition_id). Distinguishes from 'buy' sibling but does not explicitly differentiate from 'close_position' sibling which may confuse agents on which to use.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies usage via parameter references ('from get_positions') and describes the two identification options. However, lacks explicit guidance on when to use trade_id vs condition_id, precedence rules if both provided, or when to prefer close_position over sell.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It successfully discloses the WebSocket/streaming nature and subscription lifecycle, but omits important stateful behavior details like connection persistence, reconnection handling, 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of two efficiently structured sentences. The first establishes the core concept (WebSocket subscriptions), and the second details the action-specific behaviors. Zero wasted words and logically front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple 2-parameter schema with full coverage and the lack of output schema, the description adequately covers the subscription management lifecycle. It implicitly indicates the output (connection status, streaming initiation) but could explicitly describe the return format or side effects of the WebSocket stream initiation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, establishing a baseline of 3. The description reinforces the parameter semantics by mentioning "token_id" and the three action types, but does not add validation rules, format examples, or cross-parameter constraints beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb "Manage" with the resource "live WebSocket price subscriptions", clearly indicating this is a stateful subscription tool. Mentioning "WebSocket", "live", and "streaming" effectively distinguishes it from sibling one-time fetch tools like `get_price`.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use each action (subscribe to start, unsubscribe to stop, status for connection info), but lacks explicit guidance on when to choose this tool over similar monitoring siblings like `start_monitor` or `check_market`.
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. Discloses return structure (grouped positions, P&L details, exit rules) since no output schema exists, but omits rate limits, caching behavior, or real-time vs delayed data indicators.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single dense sentence front-loaded with value. Every clause adds specificity (grouping method, metrics included, rules attached). Zero redundancy or waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, description compensates by detailing the hierarchical return structure (wallet→positions→rules). Adequate for a zero-parameter retrieval tool, though error scenarios could be mentioned.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Zero parameters with baseline score 4. The phrase 'No parameters needed' confirms the empty schema state, preventing confusion about missing required fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clear verb+resource with specific scope: 'comprehensive portfolio overview' distinguished by 'grouped by copied wallet' and inclusion of 'per-wallet P&L' and 'active exit rules'. Effectively differentiates from sibling get_positions by describing unique data organization, though verb 'Get' is generic.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implicit guidance through detailed output description (use when you need copied-wallet grouping with exit rules), but lacks explicit 'use when X, use get_positions when Y' comparison to similar siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the burden and partially compensates by disclosing return value structure ('Shows wallet address, position size, and side'). However, it omits explicit safety confirmation (though 'View' implies read-only), rate limits, or pagination behavior expected when no annotations exist.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three well-structured sentences: purpose first, output preview second, use case third. No redundancy or waste. Could be slightly improved by removing 'Useful for' (which states the obvious), but otherwise efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a simple 2-parameter read tool with 100% schema coverage. The description appropriately compensates for the missing output_schema by previewing the return fields (wallet, size, side), giving the agent sufficient context to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (both condition_id and limit are well-documented in schema), establishing baseline 3. Description mentions 'by condition_id' but adds no semantic value about parameter format or behavior (e.g., that condition_id is a specific market identifier) beyond the schema definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Excellent specificity: verb 'View' + resource 'largest position holders in a Polymarket market' + key identifier 'by condition_id' clearly distinguishes this from siblings like get_positions (personal holdings), analyze_trader (individual analysis), or check_market (general data). The scope is precisely defined.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides implied usage context ('Useful for gauging smart money sentiment') hinting at whale-watching use cases, but lacks explicit guidance on when to prefer this over analyze_trader or discover_traders, and omits any exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It adds value by stating 'Returns a table of watched wallets,' revealing the output format. However, it omits other behavioral aspects like pagination behavior, rate limits, authentication requirements, or what constitutes 'status' in the returned data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of three efficient sentences with zero waste. The first sentence front-loads the core functionality, the second discloses the return format, and the third clarifies the parameter situation. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (zero parameters, read-only list operation) and absence of an output schema, the description adequately covers the essential information by explaining what data is returned (table with wallets, aliases, status). For a simple listing tool, this is sufficiently complete, though mentioning pagination or empty result handling would improve it further.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema contains zero parameters (empty object). According to the scoring rubric, 0 parameters establishes a baseline score of 4. The description confirms this with 'No parameters needed,' adding explicit confirmation beyond what the schema alone conveys.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states what the tool does: 'Show all wallet addresses currently on the copy trading watchlist with their aliases and status.' It uses a specific verb (Show), identifies the resource (wallet addresses on the copy trading watchlist), and specifies scope (all/currently on). However, it does not explicitly distinguish from sibling tools like start_monitor or discover_traders.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states 'No parameters needed,' which provides basic usage instruction regarding the input requirements. However, it lacks explicit guidance on when to use this tool versus alternatives like discover_traders or analyze_trader, and does not mention prerequisites or typical usage contexts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description adequately discloses behavioral traits: it specifies that the tool mutates state by closing positions and updating P&L, and lists the three specific trigger conditions it evaluates. It could be improved by mentioning error handling or atomicity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of three tightly constructed sentences with zero waste. It front-loads the core action (scanning for exit conditions), follows with side effects (updates P&L, closes positions), and ends with parameter information. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool performs a complex batch mutation (scanning and closing) and lacks an output schema, the description should ideally explain what the tool returns (e.g., a summary of closed positions, updated balances, or execution reports). The current description covers the operational logic but leaves the return value undocumented.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema contains zero parameters, which per the rubric establishes a baseline of 4. The description appropriately confirms this with 'No parameters needed', providing sufficient clarity without redundancy.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool scans open positions for specific exit conditions (market resolution, stop-loss/take-profit, trader exiting) and performs closing actions. However, it does not explicitly differentiate from the sibling tool `close_position` (which likely handles manual closes), leaving the distinction operational rather than explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
While the description implies this is a batch automation tool ('Scan all'), it lacks explicit guidance on when to use this versus `close_position` for manual closures or `get_positions` for monitoring. The phrase 'No parameters needed' provides some usage context but does not constitute full usage guidelines.
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 disclosure burden. It adds valuable context that the tool returns 'pass/fail with specific reasons' and notes it's a 'Pro feature,' but omits rate limits, caching behavior, or failure modes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Four tightly constructed sentences with zero waste. Front-loaded with the core action (evaluate market quality), followed by return format, usage context, and feature flag. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 3 parameters with complete schema coverage and no output schema, the description compensates well by disclosing the pass/fail return format and specific use case (pre-trade). 'Pro feature' disclosure adds necessary context. Could mention sibling differentiation for perfect completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear descriptions for token_id, max_spread, and min_depth. The description mentions 'bid/ask spread' and 'depth' which conceptually map to parameters, but does not add syntax details or validation logic beyond the schema. Baseline 3 appropriate given complete schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool evaluates market quality by checking bid/ask spread, order book depth, and price range. However, it does not explicitly differentiate from siblings like analyze_opportunity or compare_markets, which also analyze market data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states to 'Use before placing trades to avoid illiquid or wide-spread markets,' providing clear temporal context for invocation. Lacks explicit 'when not to use' guidance or named 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 provided, so description carries full burden. Discloses return data contents (price, spread, depth, volume, quality score) but omits explicit safety profile (read-only status) and operational constraints like 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three efficient sentences with zero waste: action scope, return values, and use case. Well front-loaded with specific operational details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Compensates well for missing output_schema by listing specific return data points (price, spread, etc.). Adequate for a single-parameter read operation, though structure of comparison format remains unspecified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% documenting '2-5 condition IDs to compare'. Description reinforces the quantity constraint but adds no additional semantic details about ID format or sourcing beyond what schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clear specific verb 'Compare' with resource 'Polymarket markets' and explicit scope '2-5' and 'side by side'. Effectively distinguishes from single-market siblings like check_market or get_price.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides implied usage context ('Useful for choosing the best market among similar options') but lacks explicit when-not-to-use guidance or named alternatives from the crowded sibling set.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full disclosure burden. It successfully explains return structure ('event with all its sub-markets and their current prices'), but omits safety/read-only status, rate limits, pagination behavior, or error cases.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two well-formed sentences with zero waste. Front-loaded with the core action (browse), followed by scope clarification (examples), then return value—optimal information hierarchy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Strong completeness given no output schema: the description specifies return contents (sub-markets and prices). Minor gap: does not clarify behavior when optional parameters are omitted or combined.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 67% (slug and query documented; limit undocumented). The description maps conceptually to the slug/query distinction via examples but does not compensate for the missing limit description or explain parameter interaction rules.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Excellent clarity: 'Browse' is a specific verb, 'Polymarket event groups' identifies the resource, and parenthetical examples ('US Election', 'UFC 300') precisely distinguish this from sibling tools like search_markets or check_market that operate on individual markets rather than event groups.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides implied usage through concrete event examples, but lacks explicit guidance on when to prefer this over search_markets or discover_markets, and does not address parameter precedence (slug vs query) or minimum requirements.
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 successfully discloses return values ('fill status, price, and amount') and a critical runtime constraint ('live mode'). However, it omits error behavior (e.g., invalid order ID), safety profile confirmation, or rate limiting details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three tightly constructed sentences, each earning its place: purpose declaration, return value disclosure, and operational constraint. No redundancy or filler, with purpose front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a single-parameter tool with no output schema; the description compensates by listing return fields. Deducts points only for lacking error condition documentation that would be helpful given the specificity of the query (e.g., 'order not found').
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, establishing a baseline of 3. The description adds domain context ('Polymarket order') that reinforces the parameter's purpose, but does not add syntax details, examples, or validation rules beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description provides a specific verb ('Check'), resource ('status of a specific Polymarket order'), and scope ('by order ID'), clearly distinguishing it from sibling list-query tools like get_open_orders or get_trade_history.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides one explicit constraint ('Only works in live mode'), but lacks explicit when-to-use guidance versus alternatives like get_open_orders or naming prerequisites for the order_id parameter. Usage is implied by the 'specific order' phrasing but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Successfully discloses read-only advisory nature through 'generate recommendations' and 'returns' language (distinguishing from execution tools). However, lacks operational details like rate limits, computational cost, or prerequisites (e.g., requiring open positions to exist).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tightly constructed sentences with zero waste. Front-loaded with core action (analyze/generate), followed by specific outputs (SL/TP, warnings, actions). Every phrase earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Excellent compensation for missing output schema by explicitly listing return values (SL/TP suggestions, concentration warnings, cut/hold/take-profit actions). Complete for a single-parameter analytical tool, though could mention error conditions or empty portfolio behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with complete enum descriptions (conservative=tight SL/TP, etc.). Description mentions the strategy parameter and its values, reinforcing schema semantics, but adds no additional syntax, constraints, or examples beyond what the schema provides. Baseline 3 appropriate for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clear specific verbs (analyze, generate) + resource (open positions, optimization recommendations). Effectively distinguishes from siblings: vs 'get_positions' (this generates actionable recommendations), vs 'rebalance' (this only suggests, doesn't execute), vs 'analyze_opportunity' (this targets existing positions, not new ones).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides implied usage by defining scope (open positions) and outcomes (recommendations), but lacks explicit when-to-use guidance or named alternatives. Does not clarify when to choose this over 'rebalance' or 'assess_risk' despite those siblings existing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full disclosure burden. It successfully explains order persistence ('sit in the order book until filled'), the simulation vs. live distinction, and implies state mutation in live mode. It could improve by mentioning what constitutes successful fulfillment or specific CLOB risks, but covers the critical operational dualism well.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Five sentences with zero redundancy. The structure progresses logically from definition to mechanics to operational modes to access restrictions. Every sentence adds distinct value beyond the name and schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the mutation nature (placing orders) and lack of output schema or annotations, the description adequately covers the domain and operational modes but leaves gaps around return values, error conditions, and parameter-specific constraints (beyond the schema's numeric ranges).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, requiring heavy description compensation. The text references 'at a discount,' which conceptually maps to 'discount_pct,' but provides no information about 'bet_size' units (currency, percentage, shares) or that both parameters are optional with defaults. It fails to fully compensate for the undocumented schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a precise action (Place limit orders), defines the niche term 'stink bids' parenthetically, specifies the domain (WTA tennis match favorites), and indicates the mechanics (at a discount). This clearly distinguishes it from generic siblings like 'buy' or 'batch_order' by specifying the tennis asset class and limit-order strategy.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It distinguishes between 'preview mode' (simulation) and 'live mode' (real CLOB orders), which guides execution behavior. It also notes 'Pro feature,' implying access restrictions. However, it lacks explicit guidance on when to choose this over 'buy' or other order tools, or prerequisites like requiring specific market conditions.
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 compensates for missing output schema by listing return values (profile stats, active positions, win rate, volume, PnL, recent activity). However, it omits operational traits like read-only safety, rate limits, caching behavior, or API cost.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with zero waste: first defines the tool, second lists return values, third provides usage context. Front-loaded with essential information; no redundant phrases.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequately complete for a single-parameter analysis tool. Compensates for missing output schema by enumerating return fields. Mentions platform (Polymarket) and workflow integration (watchlist). Minor gap: could specify if this is a cached vs. real-time analysis or rate limit implications.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with the address parameter fully documented in the schema ('Trader's Ethereum wallet address (0x...)'). Description mentions 'by wallet address' which aligns with but does not extend beyond the schema definition. Baseline 3 appropriate for high-coverage schemas.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Explicitly states the action (Analyze), resource (Polymarket trader), and input method (by wallet address). Distinguishes from siblings like 'discover_traders' or 'get_trader_positions' by specifying comprehensive profile analysis including stats, PnL, and win rate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear positive guidance: 'Use before adding a trader to your watchlist to assess their quality.' Establishes workflow context (pre-watchlist vetting). Lacks explicit 'when not to use' or named alternatives (e.g., vs. 'score_trader'), but the workflow cue is strong.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Discloses return format ('risk score with specific warnings') and parameter requirement ('No parameters needed'), but omits data source (current portfolio?), side effects, auth requirements, or computational cost.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with zero waste. First sentence front-loads action + 4 specific dimensions. Second sentence covers return value and parameter state. Every clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Well-covered for a zero-parameter tool. Mentions return type (risk score with warnings) compensating for missing output schema. Credible completeness given narrow scope, though explicitly stating it reads live portfolio data would strengthen further.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Zero parameters present; baseline 4 applies. Description efficiently confirms 'No parameters needed', validating the empty schema without redundancy.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Specific verb 'Assess' with clear resource 'portfolio risk'. Uniquely distinguishes from siblings (analyze_opportunity, check_exits, optimize_portfolio) by enumerating 4 exact dimensions: position concentration, market diversification, stop-loss/take-profit coverage, and daily budget utilization.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Lists 4 assessed dimensions which implies usage context, but lacks explicit when-to-use guidance or comparison to siblings like 'check_exits' (which overlaps with stop-loss coverage) or 'optimize_portfolio'. No prerequisites or alternatives named.
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 adequately discloses return values ('market question, price, volume, and end date') since no output schema exists, but omits safety classifications, rate limits, caching behavior, and error conditions expected for a data retrieval tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with zero waste: first establishes purpose and return payload, second provides usage guidance. Every clause earns its place. Front-loaded with the core action and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 4 parameters with complete schema coverage and no output schema, the description successfully compensates by listing return fields. Would benefit from mentioning result sorting or pagination behavior, but otherwise complete for a discovery tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema coverage, baseline is 3. The description adds significant semantic value by explaining business logic: 'today' equals 'fast-resolving' and 'all' equals 'browse everything', which guides user intent beyond the schema's mechanical definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Excellent specificity: 'Find active Polymarket prediction markets' clearly identifies the verb (Find), resource (prediction markets), platform (Polymarket), and state (active). It implicitly distinguishes from sibling search_markets by emphasizing filter-based discovery over keyword 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides concrete parameter guidance ('Use ending=today for fast-resolving markets') and implies browsing patterns, but lacks explicit differentiation from sibling discovery tools like trending_markets or featured_markets. Does not specify when to choose this over search_markets.
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 successfully indicates read-only nature via 'View' and discloses the critical live-mode constraint. However, it omits other behavioral details like return format, pagination, or what occurs when not in live mode.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each earning its place: purpose statement, behavioral constraint, and parameter requirement. Front-loaded with the action verb and no redundancy. Excellent information density.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple zero-parameter read tool, the description covers essential-operation, runtime constraints, and invocation requirements. While lacking explicit return value description (no output schema exists), the naming convention and purpose statement make the expected output reasonably clear.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 0 parameters, which per guidelines establishes a baseline of 4. The description appropriately confirms 'No parameters needed' without adding unnecessary embellishment.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific verb 'View' with clear resource 'pending limit orders on Polymarket' and scope 'all...not yet been filled'. This effectively distinguishes from action-oriented siblings (buy, sell, cancel_orders) and specific-query siblings (get_order_status).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit prerequisite 'Only returns results in live mode' which constrains when the tool functions. However, it lacks guidance on when to use this versus alternatives like get_order_status for specific order queries, leaving selection gaps.
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. Discloses return fields (market name, outcome, size, price) and access tier ('Pro feature'), but omits rate limits, data freshness, or permissions required beyond the Pro designation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences, zero waste. Front-loaded with action, followed by output specification, use case, and feature tier. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Appropriate for a 2-parameter read tool with rich schema. Compensates for missing output schema by listing return fields. Would benefit from noting data staleness or API limits, but adequate given simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so description baseline is 3. Mentions 'wallet address' contextually but adds no syntax details beyond schema. No compensation needed given complete schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Excellent specificity with 'View another trader's current open positions' — clear verb, resource, and scope. Explicitly distinguishes from sibling 'get_positions' (which implies self-positions) by specifying 'another trader' and requiring a wallet 'address'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides concrete use case 'due diligence before copy trading' and notes 'Pro feature' restriction. Lacks explicit 'when-not-to-use' or direct sibling alternative naming, though 'another trader' implicitly distinguishes from self-position tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It mentions database persistence and dashboard tracking implicitly, but omits critical behavioral details like idempotency, failure modes, return values, or whether records are immutable. Just meets minimum viability.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with zero waste: sentence 1 defines the action and destination, sentence 2 enumerates key data fields, sentence 3 provides the timing contract. Front-loaded with the most critical information and logically sequenced.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 12 parameters with complete schema documentation and no output schema, the description provides sufficient context for correct invocation. The combination of clear purpose, timing guidance, and schema coverage leaves only minor gaps (return value behavior, idempotency) that don't impede basic usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, establishing a baseline of 3. The description adds semantic grouping value by explicitly listing the metric categories stored (PnL, win rate, positions, budget usage, notes), reinforcing the schema without merely repeating it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Excellent specificity: states the exact action (Record), the target resource (trading cycle metrics to database), and the downstream purpose (dashboard tracking and performance analysis). Distinguishes clearly from sibling tools which focus on executing trades or analysis 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit temporal guidance ('Call this after each automated trading cycle') that establishes the clear contract for when to invoke. Lacks explicit alternatives or exclusions, but the timing instruction is strong enough to prevent misuse with real-time trading 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?
Discloses 'Pro feature' access restriction and filtering logic (conviction/win rate thresholds). No annotations present, so description carries full burden. Missing critical mutation details: whether removal is permanent, soft-delete vs hard-delete behavior, undo mechanisms, or side effects on existing positions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three efficient sentences with zero waste: 1) Action + criteria 2) Intent/purpose 3) Access restriction. Front-loaded with verb and object. No redundancy with structured data.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a watchlist pruning tool given rich schema coverage. Explains business logic (underperformers) and safety mechanism (dry_run). Missing: return value specification (common for this tool class without output schema) and data persistence details for the remove operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% description coverage, establishing baseline 3. Description reinforces parameter concepts by mentioning 'conviction score' and 'win rate' in the action context, but primarily relies on schema for technical specifics (ranges, defaults, dry_run behavior).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clear specific action (analyze and remove underperformers), specific resource (watchlist traders), and scope (based on conviction score/win rate thresholds). Distinguishes from `analyze_trader` (singular analysis) and `optimize_portfolio` (portfolio allocation vs watchlist curation).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear when-to-use context ('Use to keep your watchlist focused on high-quality traders') and implies workflow via threshold logic. The `dry_run` parameter description adds safety guidance. Lacks explicit 'when not to use' or sibling comparisons.
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. Discloses output range (0-100), methodology (5 dimensions), and feature tier (Pro), but lacks operational details such as data source (on-chain vs cached), rate limits, or error behavior for invalid addresses.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three efficiently structured sentences: methodology definition, score interpretation, and feature constraint. No redundancy or wasted words. Information is front-loaded with the core calculation purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool with 100% schema coverage and no output schema, description adequately compensates by detailing the score's meaning, range, and dimensions. Pro feature flag is crucial context. Only minor gap is handling of unfound traders.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (address parameter fully documented). Description focuses on scoring logic rather than parameter semantics, which is appropriate given the schema completeness. Baseline score applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States specific verb (Calculate) and resource (conviction score for trader), with clear scope (0-100 score across 5 dimensions). Distinguishes from sibling 'analyze_trader' by focusing on quantitative scoring for copy trading specifically.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context for when to use (copy trading decisions) and notes 'Pro feature' constraint. Could be enhanced by explicitly contrasting with 'analyze_trader' for general analysis vs scoring, but the copy trading focus provides sufficient contextual guidance.
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. Discloses critical behavioral traits: changes take effect immediately, persist across restarts, and requires Pro access. Could be improved with error behavior or idempotency notes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences cover distinct aspects: purpose, supported parameters, behavioral traits, and access tier. No redundancy, well front-loaded with the action verb.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Appropriately complete for a 2-parameter configuration tool with rich schema. Covers persistence behavior and access restrictions. Lacks output description but none is defined in the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 100% description coverage with detailed enum value descriptions. Description reinforces the two configuration concepts but does not add semantic meaning (syntax, validation rules) beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clear verb 'Update' with specific resource 'bot configuration'. Explicitly names supported config keys (daily_budget, min_conviction) that distinguish it from sibling tools like set_exit_rules and set_safety_limits.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Mentions 'at runtime' and 'Pro feature' implying usage context and access constraints, but lacks explicit when-to-use guidance versus other configuration tools or prerequisites.
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 disclosure burden. It successfully conveys the persistent/polling nature ('background loop', 'Runs continuously') but does not explicitly warn that 'copying trades' involves placing orders and spending funds, nor does it detail error handling or cancellation behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences with zero waste. Front-loaded with core mechanism (background loop/polling), followed by lifecycle, prerequisites, and constraints. Every sentence delivers essential information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (background service, trading mutation) and lack of annotations/output schema, the description adequately covers the service lifecycle, prerequisites, and termination condition. Minor gap: does not indicate the return value (e.g., monitor handle) or explicit mutation risks.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, establishing a baseline of 3. The description adds minimal semantic value beyond the schema ('at the specified interval' links the parameter to the polling behavior) but does not need to compensate for missing schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific verbs ('Start a background loop', 'polls', 'copies') and clearly identifies the resource ('watched wallets'). It distinguishes from sibling tools by explicitly referencing stop_monitor as the lifecycle counterpart and noting the watchlist prerequisite, which connects to list_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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit prerequisites ('Requires at least one wallet on the watchlist') and lifecycle guidance ('until stop_monitor is called'). Notes licensing constraint ('Pro feature'). Lacks explicit 'when-not-to-use' contrast with one-time analysis tools like analyze_trader.
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 disclosure burden. It successfully documents return values (market question, price, volume) compensating for the missing output schema. However, it omits safety characteristics (read-only nature), rate limits, pagination behavior, or error conditions that annotations would typically cover.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two well-structured sentences with zero redundancy. First sentence defines the core operation and ranking logic; second covers filtering and return values. Every clause earns its place with no filler text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a data retrieval tool with good schema coverage, the description is reasonably complete. It compensates for the missing output schema by describing return fields. Could be improved by explicitly stating the read-only nature given the presence of trading siblings (buy, sell, etc.), but adequate for tool selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, establishing a baseline of 3. The description adds semantic value by explaining that category filtering helps 'focus on specific topics' and reinforces the enum values for period. It provides context for why one would use these parameters beyond the schema's type definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the verb (List), resource (trending Polymarket markets), ranking criteria (trading volume), and time scope options. It specifically targets volume-based trending, distinguishing it from sibling discovery tools like search_markets or featured_markets.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains what the tool does (filters by category, configurable time periods) but provides no explicit guidance on when to use this versus siblings like search_markets, discover_markets, or featured_markets. Lacks 'when-not-to-use' or alternative recommendations.
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. Discloses critical behavioral traits: requires specific environment variables (POLY_API_KEY, etc.), uses real money (financial risk), and is a Pro feature (access gating). Missing only minor details like reversibility or specific error states if credentials are missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Four tight sentences with no filler. Leads with the core action, follows with prerequisites, then critical safety warning, finally access tier. 'Pro feature' is slightly peripheral but acceptable business context. Structure respects the gravity of the financial risk involved.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a mode-switching tool with no output schema. Covers action intent, prerequisites, financial risk, and access restrictions. Does not explain return values (likely none or simple status), but this is reasonable given the schema simplicity and the tool's side-effect nature.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single 'confirm' parameter, establishing baseline 3. Description does not add specific syntax/format details beyond schema, though the surrounding safety warnings reinforce the parameter's purpose as a boolean guard. Environment variables mentioned are prerequisites, not parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Exceptionally clear: specifies the verb 'Switch', identifies the resource (trading mode on Polymarket), distinguishes from siblings by clarifying this is a mode toggle (preview→live) rather than a trading action like 'buy' or 'sell', and notes the destination state (live trading with real orders).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context by naming the alternative state ('preview (simulated)') and implies the transition path. However, lacks explicit guidance on when *not* to use (e.g., 'only use when ready to risk real funds') or whether this is reversible (can you switch back to preview?). The prerequisite warning serves as implicit eligibility 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?
No annotations provided, so description carries full burden. It identifies the operation as a simulation (implying read-only safety) and notes 'Pro feature' for access gating. However, missing: execution time expectations, rate limiting, whether results are cached, and specific return format details (no output schema exists to compensate).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Four dense sentences with zero waste. Lead sentence establishes purpose, followed by user-value proposition, usage timing, and access tier. Every sentence earns its place; no redundancy despite descriptive richness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a 2-parameter simulation tool without output schema. Covers input purpose (address + copy_budget), business logic (simulation), and user intent (validation). Minor gap: lacks explicit description of return structure (e.g., 'returns P&L summary and trade log') which would help given no output schema exists.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 50% (address undescribed). Description compensates by identifying address as a 'wallet' via 'copy-traded this wallet.' Reinforces copy_budget semantics by referencing the $5 default implicitly through use case context. Could explicitly state address format expectations (e.g., Ethereum address).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Excellent specificity: verb 'Simulate copying' + resource 'trader's historical trades' + outcome 'hypothetical P&L.' Clearly distinguishes from sibling analyze_trader by focusing on backtesting rather than current analysis, and references 'wallet' clarifying the address parameter target.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit temporal guidance ('Use before adding a trader to your watchlist') and purpose ('validate their performance'). Also notes 'Pro feature' indicating access constraints. Lacks explicit 'when not to use' or direct comparison to alternatives like analyze_trader or score_trader.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full disclosure burden. It effectively communicates critical behavioral traits: runs a market quality check pre-execution, distinguishes preview mode (simulation) from live mode (real CLOB orders), and implicitly warns about financial risk in live mode. This covers the essential safety and operational characteristics needed for a trading tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Four tightly constructed sentences with zero waste: (1) core action, (2) required/optional inputs, (3) pre-execution check, (4) execution modes. Information is front-loaded and logically sequenced from general operation to specific behavioral details. No redundancy or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero annotations and no output schema, the description adequately covers operational safety (preview vs live distinction, quality checks) and expected behavior (CLOB order placement). It lacks detail on error states or return values, but provides sufficient context for an agent to invoke the tool safely and understand the consequences.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, establishing a baseline of 3. The description maps parameters to their roles ('Specify condition_id, USDC amount, and optionally a limit price') but adds minimal semantic depth beyond the schema (e.g., it confirms USDC currency but schema already states 'Amount in USDC'). It successfully identifies the optional nature of price but doesn't elaborate on outcome semantics beyond the schema's enum definition.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Specific verb (Buy) + specific resource (outcome shares) + specific platform (Polymarket market). Clearly distinguishes from sibling 'sell' and differentiates from order management tools like 'batch_order' or 'place_stink_bid' by focusing on direct CLOB market buying.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance on execution modes (preview vs live) which governs when to use simulation versus real trading. However, lacks explicit differentiation from siblings like 'batch_order' (for multi-order) or 'sell' (for closing positions), and does not specify prerequisites like wallet funding or market selection criteria.
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?
Compensates well for absent annotations by disclosing return structure ('Returns trader address, PnL, volume, and win rate') and conditional side effect ('Use auto_watch to add them to your watchlist'). Clarifies that auto_watch triggers a mutation while base operation is read-only fetch.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Perfectly structured: sentence 1 defines action, sentence 2 states purpose, sentence 3 documents returns, sentence 4 gives param guidance. No redundant 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/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Effectively compensates for missing output schema by enumerating return fields (address, PnL, volume, win rate). Addresses all 5 well-documented parameters. Could minimally improve by mentioning pagination behavior (pages param) implications.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% so baseline is 3. Description adds workflow context for auto_watch ('Use auto_watch to...') beyond schema's declarative description, but adds minimal context for pages, period, min_volume, or min_pnl beyond what schema already documents.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Excellent specificity: 'Fetch top traders from the Polymarket leaderboard ranked by PnL, volume, and ROI' provides exact verb, resource, and ranking criteria. Distinguishes clearly from siblings like discover_markets or discover_flow by focusing on trader entities rather than markets or flow.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Strong positive guidance: 'Use this to find profitable traders worth copying' establishes clear value proposition. Mentions 'Use auto_watch to add them to your watchlist directly' which connects parameter to workflow. Lacks explicit 'when not to use' comparisons to analyze_trader or score_trader siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, carries full burden. Describes returned data fields (budget, P&L components) but lacks explicit safety confirmation (read-only, no side effects). 'View' implies safety but critical for trading tools to be 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three efficient sentences: core purpose with data specifics, parameter confirmation, and usage guidance. Front-loaded with the key verb and resource. No waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Appropriate for simple parameterless tool. Compensates for missing output schema by listing specific returned financial metrics. Would be complete with explicit read-only safety statement.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Zero parameters triggers baseline 4. Description adds 'No parameters needed' which confirms the empty schema, ensuring the agent knows no filtering is possible.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Specific verb 'View' with exact resource 'account balance summary' and detailed breakdown of components (daily budget, invested, P&L). The mention of 'daily budget remaining' distinguishes it from sibling portfolio/position tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use: 'check how much budget is left before placing new trades' - providing clear temporal context relative to trading actions. Lacks explicit 'when not to use' or named alternatives (e.g., vs get_portfolio).
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 what data aggregates (budget, P&L, trades, etc.) but lacks behavioral traits like update frequency (real-time vs cached), latency expectations, or whether monitor state retrieval affects monitoring status.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two efficient sentences with zero waste. First sentence defines capability and contents, second provides usage guidance. Information density is high.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite lacking output schema, description enumerates dashboard components (budget, P&L, trades, watchlist, monitor), providing sufficient context for return value expectations. Would benefit from mentioning format (JSON structure) but adequate for tool selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Zero parameters with explicit confirmation ('No parameters needed'). Baseline 4 appropriate for zero-param tools with explicit declaration.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States specific verb (Get) and resource (dashboard) with detailed scope (daily budget usage, total P&L, recent trades, watchlist status, monitor state). Clearly distinguishes from sibling tools like get_balance, get_portfolio, or get_trade_history which fetch specific subsets, whereas this provides a comprehensive overview.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use ('for a quick overview of your trading activity'), providing clear context for selection. Could be strengthened by explicitly contrasting with specific getter tools, but the 'comprehensive' framing implies aggregation vs. detail.
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 successfully discloses the automation trigger (check_exits closure) and access restriction ('Pro feature'). Missing: reversibility/cancellation behavior, partial fill handling, or failure states when position already closed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences with zero waste: purpose (1), mechanism (2), prerequisite (3), restriction (4). Front-loaded with core function. Every clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Strong workflow integration covering prerequisite (get_positions), execution (check_exits), and licensing (Pro feature). Adequate for a 3-parameter automation tool. Minor gap: no mention of how to cancel/modify existing rules or success/failure indicators.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 67% (stop_loss and take_profit described; trade_id bare). Description compensates by specifying trade_id source ('Use get_positions to find trade IDs') and clarifying the optional relationship between SL/TP levels ('and/or'). Adds meaningful context beyond schema constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Specific verb 'Set' with clear resources 'stop-loss and/or take-profit price levels' and scope 'on an open position'. The phrase 'and/or' precisely signals optional combinations, distinguishing this from one-off close operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly references prerequisite workflow 'Use get_positions to find trade IDs' and execution mechanism 'check_exits will automatically close'. Clear context for when to use (automated exit management). Lacks explicit 'when-not' or alternative comparison to manual close_position.
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 zero annotations, carries full disclosure burden effectively. Explicitly states 'Read-only' and 'does not place trades' (safety-critical). Discloses return value ('score with detailed reasoning') and analysis factors. Missing minor details like data latency or caching.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three efficient sentences: methodology/output, safety constraint. Zero redundancy. Critical information front-loaded. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool with no output schema, description adequately compensates by describing return values (score, reasoning) and read-only safety. Sufficient given tool complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single parameter (condition_id). Description mentions 'Polymarket market' which aligns with but does not significantly expand upon the schema's definition. Baseline 3 appropriate when schema documentation is complete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Specific verb 'Generate' + resource 'Polymarket market' + distinct output format 'BUY/SELL/HOLD recommendation'. Methodology (price, spread, trend, liquidity) clearly differentiates from execution siblings (buy, sell) and other analysis tools (check_market, assess_risk).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit exclusion 'does not place trades' clearly distinguishes from execution siblings (buy, sell, batch_order). 'Read-only analysis' clarifies safe, pre-trade usage. Lacks explicit positive guidance (e.g., 'use before trading') or comparison to analyze_trader.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, description carries full behavioral burden. It discloses the return value ('Returns the number of cancelled orders'), environment restriction ('live mode'), and licensing requirement ('Pro feature'). Lacks detail on irreversibility or partial failure modes, but covers the essential behavioral constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Five compact sentences with zero waste. Front-loaded with action and scope. Each sentence earns its place: scope (orders), platform (Polymarket), constraint (live mode), return value (count), parameters (none), and feature tier (Pro).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Appropriately complete for a zero-parameter tool. Documents return value despite missing output schema. Could be improved by noting behavior when no orders exist (returns 0 vs error), but covers the critical operational constraints adequately.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Zero parameters present per schema (empty object). Baseline 4 applies as per instructions. Description adds value by explicitly confirming 'No parameters needed', preventing the agent from hallucinating filter parameters that might exist in sibling tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description provides specific verb (Cancel), clear resource scope (all open/pending limit orders on Polymarket), and distinguishes from siblings like get_open_orders (read-only listing) and close_position (positions vs orders). The 'all' qualifier clearly signals bulk operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit constraints: 'Only works in live mode' establishes when-not to use (avoid in paper trading), and 'Pro feature' indicates access tier. No explicit comparison to hypothetical single-order cancellation alternatives, but 'No parameters needed' signals this is a nuclear option vs surgical 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 provided, the description carries the full disclosure burden effectively. It clearly explains the dual behavior (live mode sells on Polymarket, preview mode updates database) and notes the 'Pro feature' restriction. Missing only minor behavioral details like rate limits, irreversibility warnings, or error states.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Four efficient sentences with zero waste. Front-loaded with the core action ('Manually close...'), followed by mode specifics, prerequisites, and feature tier. Each sentence earns its place with no redundant information or repetition of schema details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple 2-parameter schema with full coverage and no output schema, the description provides appropriate completeness. It covers operational modes, data source prerequisites, and feature restrictions. Could be improved by noting the return value or confirmation behavior, but adequate for tool selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, establishing a baseline of 3. The description adds valuable semantic context by explicitly instructing users to 'Use get_positions to find the trade_id', reinforcing the relationship between these tools beyond what the schema field descriptions provide.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific verbs ('close', 'places a sell order', 'marks as closed') and clearly identifies the resource as a 'copy trading position' operated on by 'trade ID'. It effectively distinguishes this from the sibling 'sell' tool by specifying this is for copy trading positions requiring a trade_id from get_positions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear prerequisite guidance ('Use get_positions to find the trade_id') and distinguishes between live and preview modes. However, it lacks explicit guidance on when to use this versus the sibling 'sell' tool for non-copy trading positions, or when manual closing is preferred over 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?
No annotations provided, so description carries full burden. Discloses idempotent/safe behavior when preconditions aren't met and clarifies this is a background loop. Could further clarify cleanup behavior or return value meaning.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences, 22 words. First sentence establishes purpose and sibling relationship, second confirms parameters, third gives safety guidance. Zero waste, perfectly front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Appropriate for a simple lifecycle tool with no output schema. Covers purpose, sibling relationship, parameters, and safety. Would benefit from brief note on success indication, but adequate for complexity level.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Zero parameters present, establishing baseline 4. Description confirms this with 'No parameters needed', matching the empty schema without adding unnecessary elaboration.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clear specific verb (Stop) + resource (background wallet monitoring loop) and explicitly ties to sibling tool 'start_monitor', distinguishing it from other lifecycle tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies usage context via 'started by start_monitor' and provides explicit safety guidance with 'Safe to call even if monitor is not running', acting as a when-not exception. Lacks explicit alternatives but covers primary safety concern.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

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

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

Card Badge

Copy to your README.md:

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

Score Badge

Copy to your README.md:

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

How to claim the server?

If you are the author of the server, you simply need to authenticate using GitHub.

However, if the MCP server belongs to an organization, you need to first add glama.json to the root of your repository.

{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}

Then, authenticate using GitHub.

Browse examples.

How to make a release?

A "release" on Glama is not the same as a GitHub release. To create a Glama release:

Claim the server if you haven't already.
Go to the Dockerfile admin page, configure the build spec, and click Deploy.
Once the build test succeeds, click Make Release, enter a version, and publish.

This process allows Glama to run security checks on your server and enables users to deploy it.

How to add a LICENSE?

Please follow the instructions in the GitHub documentation.

Once GitHub recognizes the license, the system will automatically detect it within a few hours.

If the license does not appear on the server after some time, you can manually trigger a new scan using the MCP server admin interface.

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.

Latest Blog Posts

Tool Definition Quality Score (TDQS)
By punkpeye on April 3, 2026.
mcp
The Hackers Who Tracked My Sleep Cycle
By punkpeye on March 26, 2026.
security
Open Source Has a Bot Problem
By punkpeye on March 19, 2026.
open source

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-trader-mcp'

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