Polymarket Autonomous Trader

by vulcan-sport

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation5/5
Each tool has a clearly distinct purpose. Market exploration tools (search, details, trending, orderbook) are separated by scope, while analysis, trading, portfolio, approval, autonomous loop, and risk tools are each uniquely defined with no meaningful overlap.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern using lowercase with underscores (search_markets, get_market_details, place_order, update_risk_limits). No mixed conventions or camelCase, making the set predictable and easy to navigate.
Tool Count3/5
22 tools is in the 16-25 range, which feels heavy even though the domain of autonomous trading justifies a larger surface. While many tools are necessary (market, order, risk, loop management), the count is above the typical 3-15 sweet spot and could potentially be consolidated.
Completeness4/5
The tool set covers the full lifecycle of trading: market discovery, analysis, order placement/cancellation, portfolio tracking, risk management, approval modes, and autonomous loop control. Minor gaps like a dedicated trade history tool or explicit sell position are absent, but agents can work around them via existing functionality.
Average 3.8/5 across 22 of 22 tools scored. Lowest: 3/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only states that the action does not execute the trade, but fails to explain side effects such as whether the decision is permanently discarded, whether it is reversible, or how the 'reason' parameter is used. This is minimal transparency for a state-changing operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no fluff or repetition. It efficiently captures the primary action, but lacks necessary context. While concise in structure, its brevity leads to under-specification, preventing a perfect score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (two parameters, no annotations, unknown output schema), the description is insufficiently complete. It omits details about the lifecycle of the decision, any state changes, potential errors, or prerequisites. The tool appears part of a trade-decision workflow, but the description does not situate it within that workflow or explain its effects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has two parameters (reason and decision_id) with zero description coverage, and the description provides no additional meaning for either. It doesn't clarify what 'decision_id' refers to, whether 'reason' is required, or how these parameters affect the rejection process. The description completely fails to compensate for the schema's lack of detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Reject' and the resource 'pending trade decision', and adds the qualifier 'without executing it' which distinguishes it from approval or execution tools. It effectively communicates the tool's core function and differentiates it from siblings like approve_trade.
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 phrase 'without executing it' implies this is the non-executing counterpart to an approval, suggesting when it should be used. However, it does not explicitly mention alternatives, state when not to use it, or reference sibling tools, leaving usage guidance implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states that the tool asks Claude to estimate probability, without revealing whether this is a read-only operation, how the estimation works, what the output contains, or any side effects or limitations. This is a significant gap for an unannotated tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, front-loaded with the core purpose. There is no redundant or filler content, and every phrase contributes to the tool's understanding. This is appropriately concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a simple parameter set (2 parameters) and an output schema, so the description doesn't need to detail return values. However, it omits context on what a condition_id refers to and when to use this tool, which would be valuable for correct invocation. The description is minimally complete but leaves gaps in usage and parameter identification.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description explicitly mentions 'additional context' as optional, which provides some meaning for the context parameter. However, it does not explain the required condition_id parameter beyond what the schema title ('Condition Id') implies. Since schema description coverage is 0%, the description partially compensates by hinting at the role of context, but it leaves condition_id's purpose ambiguous.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: to estimate the true probability of a market's YES outcome. It uses a specific verb ('estimate') and identifies the resource ('market's YES outcome'). However, it does not explicitly distinguish itself from sibling tools like analyze_thesis, though the focus on probability estimation is fairly distinctive.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention scenarios, prerequisites, or exclusions. The only usage hint is that context can optionally be provided, but there is no explanation of when providing context is beneficial or when this tool would be preferred over others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden for behavioral disclosure. It implies a read-only operation via 'List', but does not mention side effects, data scope, authentication requirements, or return format specifics. This is a minimal disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, short, clear sentence with no filler. It is appropriately sized for a simple parameterless tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple listing tool with no parameters and an output schema, the description is minimally sufficient. However, it lacks behavioral context (e.g., what 'live' means, whether orders are scoped to a user or market) and does not mention any alternatives or limitations, leaving some room for ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the input schema covers everything vacuuously. Per the baseline for 0 params, the description does not need to add parameter details, and none are provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a clear verb ('List') and a specific resource ('all live (unfilled) orders'), unambiguously stating what the tool does. However, it does not explicitly distinguish itself from sibling order-related tools like get_orderbook or get_portfolio, relying on the tool name for differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description merely restates the function without any context about use cases, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must carry the full burden of disclosing behavior. Saying it is 'live' and includes 'bids and asks' gives basic content, but it does not state read-only semantics, depth limits, ordering, or potential errors.
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?
One concise, grammatically correct sentence that front-loads the core action and resource. It is efficient, though the lack of supporting detail suggests it is slightly under-specified rather than optimally concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has only one parameter and an output schema, so complexity is low, but the description leaves gaps in parameter meaning and usage guidance. It is not enough for an agent to confidently invoke the tool without additional assumptions.
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 coverage is 0% and token_id has no description. The description only restates that the tool operates on an outcome token, giving no help on token_id format or how to retrieve it, so it fails to compensate for the missing schema 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?
The description uses a specific verb ('Get') and clearly identifies the resource ('live orderbook') and scope ('for a specific outcome token'). This distinguishes it from sibling tools like get_market_details or get_open_orders.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when the tool is used (when an orderbook for a specific outcome token is needed) but provides no explicit guidance on when to prefer it over alternatives or any exclusions. No prerequisites or search steps for finding the token are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It adds the useful trait that the orderbook snapshot is 'live', but does not mention permissions, error conditions, or data freshness beyond that. Minimal but not misleading.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that directly states the tool's purpose and a key feature. There is no wasted language or irrelevant detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a simple interface with one required parameter and an output schema, so the description doesn't need to list return fields. However, the lack of parameter semantics and explicit usage comparisons to sibling tools leaves some gaps in contextual completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description does not explain the 'condition_id' parameter. The agent must rely on the parameter name alone, which may be insufficient for a new user. No additional meaning is provided beyond the schema 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?
The description clearly states the tool retrieves full details for a specific market, including a live orderbook snapshot. It uses a specific verb and resource, but it doesn't explicitly differentiate from sibling tool 'get_orderbook', which also deals with orderbooks.
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 phrase 'for a specific market' implies it is intended for lookups by market identifier, not for searching or listing. However, no explicit guidance is given about when to use this tool over get_orderbook or other alternatives, and no exclusions are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility for disclosing behaviors. It mentions return fields (prices, volume, liquidity), but omits important semantics like default filtering (active_only defaults to true), limit behavior, sorting, or error handling. This is a minimal disclosure that does not sufficiently warn the agent about side effects or operational nuances.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exceptionally concise, containing two short sentences that immediately convey the primary action and return content. Every word is purposeful, with no filler or redundancy. This is an ideal structure for a simple search tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema (which may document return values), the description leaves major gaps: no explanation of limit/active_only defaults or behavior, no indication of result ordering or pagination, and no guidance on edge cases. For a tool with 3 parameters and zero schema description, this completeness is insufficient for reliable invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for all parameters. It only explains 'query' as a keyword, leaving 'limit' and 'active_only' completely unexplained. The description adds marginal value over the raw schema (which only shows types, titles, and defaults) but fails to provide crucial meaning for the majority of parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb ('Search') and resource ('Polymarket markets'), plus a keyword filter. This distinguishes it from siblings like 'get_trending_markets' (trending vs. keyword search) and 'get_market_details' (single market vs. list).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for keyword-based searches, which contrasts with siblings like get_trending_markets, but it does not explicitly state when to use this versus alternatives or provide exclusion criteria. Clear context but no direct alternative comparison.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the core check logic but does not describe return format, edge cases, or that it is a read-only operation. This is insufficient for a tool with no structured safety hints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that immediately conveys the tool's action and purpose. No filler or redundancy, making it 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?
Given the simple one-parameter tool and the existence of an output schema, the description is mostly adequate. However, it lacks details about prerequisites (e.g., market data availability) and does not address potential error cases, making it minimally complete.
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 coverage is 0% and the description does not explicitly explain the condition_id parameter. While the parameter name is self-explanatory and the description references YES+NO prices, it doesn't add meaningful context beyond the schema's title, leaving parameter semantics under-specified.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: to check if YES + NO prices sum to something other than 1.0, indicating a potential arbitrage. This is a specific verb+resource pair that distinguishes it from sibling tools like estimate_market_probability or get_orderbook.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for arbitrage detection but does not explicitly state when to use this tool versus alternatives or mention any prerequisites. It lacks clear context about required data or conditions, such as needing orderbook data first.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only says 'gracefully stop', without explaining what 'graceful' entails or side effects (e.g., order cancellation, loop state). This leaves the agent without critical behavioral information.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. It is appropriately concise for a zero-parameter tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the tool is simple, the description lacks necessary context about operational behavior, loop state changes, or when it's appropriate to call. The output schema is present but doesn't compensate for missing behavioral transparency.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes no parameters, so the description has no parameter-specific burden. The schema covers 100% of the (empty) parameter list. Baseline 4 is 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?
The description clearly identifies the action ('stop') and the target ('autonomous trading loop'), and it distinguishes itself from sibling tools like start_autonomous_loop and get_loop_status.
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 alternatives, nor any conditions or prerequisites. The name implies its purpose, but there is no stated context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only states 'open order' as a condition but does not mention consequences (e.g., irreversibility), error behavior if the order is not open, permissions, or idempotency. This is a minimal disclosure for a mutating operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence with no filler. It conveys the essential action and scope in five words, earning full marks for conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one parameter and an output schema present, so return values are covered. However, the absence of annotations and the lack of details about error handling or preconditions mean the description is only minimally complete. It works for a straightforward cancellation but leaves the agent without guidance on edge cases.
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% for the single parameter order_id. The description adds no explanation of what order_id is or how to obtain it beyond the schema's own title 'Order Id.' The description says 'specific open order' but does not connect that to the parameter, so it fails to compensate for the lack of 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 the specific verb 'Cancel' with a clear resource: 'a specific open order.' It explicitly distinguishes from the sibling tool cancel_all_orders by emphasizing 'specific,' making the scope unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly indicates this is for cancelling a single open order, which provides clear context for use. However, it does not explicitly mention alternatives or when-not-to-use, such as 'use cancel_all_orders to cancel multiple orders.' Therefore it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden of behavioral disclosure. The verb 'Return' indicates a read-only operation, which is helpful, but the description does not disclose any additional behavioral traits such as pagination, output format, or any authorization requirements. It is adequate but minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no wasted words. It front-loads the core purpose and is perfectly concise for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description adequately conveys the main purpose, and the output schema exists to handle return value details. However, it lacks guidance on the optional 'limit' parameter and does not explain how 'top' is defined beyond volume. Given the tool's simplicity, it is mostly complete but not fully self-sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one parameter 'limit' with a default of 10 and no description. The tool description does not mention the parameter at all, leaving the agent to infer its meaning from the name alone. Since schema description coverage is 0%, the description was expected to compensate but does not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Return top Polymarket markets by 24-hour volume.' It uses a specific verb ('Return'), identifies the resource ('Polymarket markets'), and defines the scope ('top by 24-hour volume'), which distinguishes it from sibling tools like search_markets and get_market_details.
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?
Usage is implied: the tool is for retrieving trending markets based on volume. However, there is no explicit guidance on when to use it versus alternatives, nor any exclusions or prerequisites. The description does not mention that this is for discovering top markets, and no sibling tool comparison is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It implies a read-only operation via 'Show' and states the scope as 'all current positions,' adding context that the agent receives the full portfolio without filters. However, it does not disclose potential latency, data freshness, or whether any side effects occur (though 'show' strongly implies no mutation).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, tightly worded sentence that front-loads the main action ('Show all current positions') and then adds the key detail ('with unrealized P&L and current prices'). No wasted words or 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?
The tool is simple with no parameters and an output schema provides return structure. The description covers the essential scope ('all current positions') and the key data fields. It is complete enough for an agent to select and invoke the tool correctly, though it does not mention data freshness or any filtering limitations beyond 'all'.
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 zero parameters, the input schema is trivial and the description correctly does not attempt to describe parameter behavior. The baseline of 4 is appropriate because there is nothing for the description to add beyond what is already obvious from 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 uses the specific verb 'Show' and clearly identifies the resource as 'all current positions' while adding distinguishing details ('unrealized P&L and current prices'). This distinguishes it from siblings like get_balance (cash) and get_open_orders (orders), and get_pnl_summary (P&L summary without full positions).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives. It does not mention any prerequisites or scenarios where other tools like get_pnl_summary would be more appropriate, leaving the agent to infer usage solely from the tool name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden for behavioral disclosure. It mentions 'current' values, implying a real-time snapshot, but it does not disclose any side effects, auth requirements, or potential state changes. The description is too terse to convey behavior beyond the basic return action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, compact sentence that states the action and the returned data. It is front-loaded with the verb 'Return' and wastes no words.
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 parameterless read-only tool with an output schema, the description covers the essential purpose and return contents. However, it lacks any context about when to use it (e.g., before placing trades) or how it relates to other tools. The output schema likely handles the return format, so the description is mostly sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so there are no parameter semantics to explain. The baseline for zero parameters is 4, and the description appropriately focuses on the output rather than inputs.
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 'Return' as a specific verb and clearly lists the exact data points it provides (risk limits, daily loss consumed, exposure, limit utilization). This distinguishes it from siblings like update_risk_limits, which modifies rather than reads.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies a read-only usage for checking current risk status, but it does not explicitly state when to use this tool versus alternatives such as update_risk_limits or get_portfolio. No exclusions or alternative references are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure. It communicates that updates occur at runtime without a restart and describes the consequence of daily_loss_limit_usdc (halt trading), but it omits important traits like persistence across restarts, permission requirements, immediate effect validation, or reversibility. This leaves significant gaps for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: one introductory sentence plus a structured list of arguments. Every sentence carries value, and the information is front-loaded with the core action and benefit. No fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and presence of an output schema, the description covers the main parameter semantics but omits key contextual details: all parameters are optional (per schema), allowing partial updates where unspecified limits remain unchanged, and there is no mention of value validation or error conditions. These gaps could mislead an agent into thinking full parameter set is required.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It does so thoroughly, explaining each of the four parameters in plain language: max_position_usdc (per-position size), daily_loss_limit_usdc (halt trading threshold), max_exposure_usdc (total open exposure), and min_edge (with a concrete example '0.03 = 3%'). This adds meaningful semantics beyond the schema's type-only 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?
The description clearly states the tool's purpose: 'Update runtime risk limits without restarting the server.' It uses a specific verb (update) and resource (runtime risk limits), and distinguishes itself from siblings like get_risk_status by emphasizing runtime modification and no-restart behavior.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by context (updating risk limits) but does not explicitly state when to use this tool versus alternatives such as get_risk_status for reading limits. No exclusions or alternative tools are mentioned, though the sibling list makes the distinction inferable.
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 for behavioral disclosure. It does disclose that approval 'executes immediately', which is a key behavioral trait, and notes it is only relevant in confirm mode. However, it does not elaborate on side effects, irreversibility, or required permissions for this potentially consequential action.
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 short sentences, front-loaded with the core purpose and followed by the key usage constraint. Every word earns its place with no redundancy or filler.
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 tool with a single parameter and an output schema, the description provides the essential purpose and the conditional context (confirm mode). It does not explain what happens after execution or prerequisites, but given the tool's simplicity and sibling context, it is reasonably 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 description coverage is 0% and there is one required parameter. The description indirectly explains that decision_id refers to a 'pending trade decision', providing some meaning beyond the parameter name. But it stops short of giving format, origin, or how to obtain the ID, so it only partially compensates for the missing schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'approve' and the resource 'pending trade decision', and adds that it executes immediately. This distinguishes it from sibling tools like reject_trade and place_order, as it specifically handles pending trade decisions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when this tool is needed ('Only needed in confirm mode'), and implies it is not needed outside that mode. However, it does not mention alternative tools (e.g., reject_trade) or provide explicit when-not guidance, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It clearly communicates a destructive action (cancel all open orders) and the scope, but does not disclose any additional behavioral traits such as irreversibility, confirmation requirements, or impact on specific order types.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no superfluous information. It is highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters and a simple destructive action, the description is largely sufficient. An output schema exists, so return values need not be described, but mentioning that all open orders are affected across every market adds completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so the description does not need to explain parameter meaning. Per the rubric, no parameters earns a baseline score of 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (cancel) and the resource scope (all open orders across all markets). It distinguishes itself from sibling tools like cancel_order by specifying 'all' and 'across all 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 scope 'across all markets' implies it is for bulk cancellation rather than individual orders, but it does not explicitly state when to use this tool versus cancel_order, nor does it mention any prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. The word 'Return' implies a read-only operation, but it does not explicitly state that no state is modified or mention any permissions or side effects. It is adequate but minimal for a simple balance query.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single concise sentence that is front-loaded with the verb and resource. Every word carries meaning, with no filler or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, the description is sufficient to understand its function. An output schema exists, so return values don't need explanation. The only gap is a lack of explicit usage guidance, but this is a minor omission for a straightforward balance checker.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema already provides full coverage. The description correctly scopes the balance to 'available for trading,' adding semantic meaning beyond the empty schema. This aligns with the baseline for no parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Return') and resource ('USDC balance available for trading'), making the tool's purpose immediately clear. It distinguishes itself from sibling tools like get_portfolio by focusing specifically on the USDC trading balance.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool (to check available trading balance) but does not explicitly mention alternatives or exclusions. It lacks guidance on choosing this over get_portfolio or get_pnl_summary, but the context is reasonably clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of explaining behavior. It discloses the multi-step workflow (extract keywords, search, score, return recommendations), giving the agent a clear picture of what will happen. It doesn't reveal potential side effects like whether it places trades, but the described process is clearly analytical.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured, with a clear main sentence followed by a numbered list of steps and an example. Every part adds value, and there is no 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?
For a tool with an output schema and two parameters, the description covers the overall purpose and workflow but omits details about max_markets and potential edge cases. It's mostly complete, but the missing max_markets explanation leaves a gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has no parameter descriptions (0% coverage). The description gives an example thesis but doesn't explain the max_markets parameter or its effect on results. It adds some meaning for 'thesis' but leaves max_markets completely undocumented.
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 states a clear purpose: 'Analyze an investment thesis and find the best Polymarket markets to trade.' It clearly distinguishes from sibling tools like search_markets by focusing on thesis-driven analysis and ranked recommendations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool—when a user has an investment thesis—and offers an example thesis. However, it doesn't explicitly contrast with alternatives like search_markets, nor does it state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. The verb 'Return' implies a read-only operation and the description lists what is returned, but it does not explicitly confirm the absence of side effects, permissions, or other behavior beyond retrieval.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the core purpose. Every word contributes meaning, with no extraneous content.
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 parameterless tool with an output schema, the description is complete. It names all key outputs and clearly signals the tool's role among siblings, making it fully understandable without additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, making schema coverage vacuous. The description adds value by enumerating the specific outputs (loop state, active thesis, pending decisions, iteration count), which helps the agent understand what to expect despite having no inputs to configure.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Return' and the resource 'loop state', listing specific outputs (active thesis, pending decisions, iteration count). It distinguishes itself from sibling tools like start_autonomous_loop and get_risk_status by focusing solely on loop status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for checking loop status but provides no explicit guidance on when to use it versus alternatives, nor does it mention exclusions or prerequisites. The tool name and description make the intended use obvious, but there is no direct comparison to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of disclosing behavior. The verb 'return' implies a read-only operation, and the specific output fields are listed, which is helpful. However, it does not explicitly state that no data is modified or mention any potential side effects, rate limits, or authentication requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the action and lists the key return values. Every word contributes to understanding the tool's purpose.
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 simple, parameterless tool with an output schema, this description is complete. It tells the agent exactly what data to expect, and no additional context is needed for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and schema coverage is trivially 100%, so the description need not add parameter details. The baseline for no-parameter tools is 4, which is appropriate here.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns daily realized P&L, unrealized P&L, and portfolio value, specifying both the action and the resource. It distinguishes this from siblings by focusing on P&L summary rather than broader portfolio/balance information.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool is used to retrieve P&L and portfolio value, but it does not explicitly state when to prefer it over related tools like get_portfolio or get_balance. No exclusions or alternative references are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It discloses that confirm mode returns a pending decision for approval and that autonomous mode executes immediately if within risk limits. It does not detail failure outcomes or order lifecycle beyond these key points.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-structured: two sentences on behavior followed by a clean argument list. Every sentence adds value, and the main purpose is 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 5 parameters and an output schema, the description provides sufficient coverage of place order behavior, modes, and parameter semantics. It is slightly incomplete in not referencing how to obtain a condition_id (e.g., via search_markets), but overall it enables correct tool invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has zero description coverage, so the tool description fully compensates by explaining each parameter: condition_id, side (YES/NO), price (0.01–0.99), size_usdc, and order_type (GTC/FOK). This adds significant meaning beyond the bare schema field names.
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 starts with a clear, specific action: 'Place a limit order on a market.' This identifies the verb and resource precisely, and it is distinct from sibling tools like cancel_order or approve_trade.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the two execution modes (confirm and autonomous) and their differing behaviors, providing useful context on when the tool will place an order vs. request approval. However, it does not explicitly mention alternatives or exclusions, which would push it to a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full transparency burden. It discloses the key behavioral difference: confirm requires approval per trade, autonomous executes within risk limits without asking. This gives the agent enough insight into the operational impact, though it does not cover details like permission requirements or scope.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact, with a clear opening sentence followed by a structured listing of the two modes. Every line contributes information, and the safe default is called out, ensuring the agent quickly grasps the tool's behavior.
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 setter with one parameter and an output schema, the description covers the core functionality and mode semantics. It could be improved by noting how it relates to start_autonomous_loop, but it remains sufficiently complete for selecting and invoking this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds critical meaning for the single 'mode' parameter by defining the two possible values ('confirm' and 'autonomous'). The schema provides no enum or description, making this definition essential for correct invocation.
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 the specific verb 'toggle' and identifies the resource 'trading approval mode', clearly distinguishing this from sibling tools like start_autonomous_loop. It details the two possible modes, making the tool's function unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear context for each mode, noting that 'confirm' is the 'safe default' and 'autonomous' executes without asking, which implies when each should be used. However, it does not explicitly mention exclusions or contrast with sibling tools such as start_autonomous_loop.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description takes on the safety burden and discloses key behaviors: periodic scanning, trade proposing, and possible automatic execution. However, it does not clarify how 'confirm mode' vs 'autonomous mode' is selected (e.g., via set_approval_mode), leaving a meaningful ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only two sentences, front-loaded with the action, and every clause adds distinct value: the monitoring action, the interval, and the two behavioral modes. No filler.
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?
The tool is relatively simple and has an output schema, so return values need no explanation. The description covers the core behavior and parameters, but the mode-selection ambiguity and the absence of a pointer to stop_autonomous_loop are minor completeness gaps for an autonomous trading tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, but the description fully explains both parameters: 'thesis' is the investment thesis being monitored, and 'poll_interval_seconds' is the frequency between scans. This fully compensates for the bare 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 specific verb and resource: 'Start continuous market monitoring for a given investment thesis.' It clearly distinguishes the tool from siblings like stop_autonomous_loop and get_loop_status by defining its start action and scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies when to use the tool: when a user has an investment thesis and wants continuous monitoring. It does not explicitly contrast with one-off analysis tools or name alternatives, so it misses the top score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

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

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

Card Badge

Copy to your README.md:

[![Polymarket MCP server](https://glama.ai/mcp/servers/vulcan-sport/Polymarket/badges/card.svg)](https://glama.ai/mcp/servers/vulcan-sport/Polymarket)

Score Badge

Copy to your README.md:

[![Polymarket MCP server](https://glama.ai/mcp/servers/vulcan-sport/Polymarket/badges/score.svg)](https://glama.ai/mcp/servers/vulcan-sport/Polymarket)

Latest Blog Posts

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

MCP directory API

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

curl -X GET 'https://glama.ai/api/mcp/v1/servers/vulcan-sport/Polymarket'

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