Rekko MCP

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation3/5
Most tools have distinct purposes, but there is notable overlap between analyze_market/get_strategy and get_arbitrage/get_arbitrage_live, which could confuse agents. Descriptions help clarify differences, but the boundaries are not always sharp.
Naming Consistency5/5
Tool names follow a highly consistent verb_noun pattern throughout, such as analyze_market, check_analysis_status, get_analysis, and list_markets. There are no deviations in naming conventions, making the set predictable and readable.
Tool Count2/5
With 27 tools, the count feels excessive for a prediction market analysis server, leading to potential complexity and overlap. A more focused set of 10-15 tools could better serve the domain without overwhelming agents.
Completeness5/5
The tool surface comprehensively covers the prediction market domain, including analysis, trading, portfolio management, data retrieval, and webhooks. There are no obvious gaps, supporting full CRUD/lifecycle operations and agent workflows effectively.
Average 3.7/5 across 27 of 27 tools scored. Lowest: 3.1/5.
See the Tool Scores section below for per-tool breakdowns.
- 0 of 1 community issues answered or closed in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
This repository includes a glama.json configuration file.
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 provided, the description carries the full burden of behavioral disclosure but offers minimal safety or operational context. It does not indicate whether this is a read-only operation (though implied by 'Get'), mention rate limits, caching behavior, data freshness, or error conditions for invalid market_ids.
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 appropriately sized with zero wasted words. It is front-loaded with the core purpose statement, followed by a structured Args block that efficiently conveys parameter details. The format is slightly unconventional for MCP (using an 'Args:' section) but remains clear and scannable.
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 existence of an output schema, the description appropriately avoids duplicating return value documentation. However, it lacks any mention of the output structure (e.g., that it returns time-series data points) or error handling patterns, leaving gaps for a tool with four parameters and complex data retrieval behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema description coverage, the description compensates effectively by documenting all four parameters in the Args block. It adds crucial semantic constraints not present in the schema, specifically enumerating valid values for 'platform' ('kalshi'/'polymarket') and 'period' ('48h'/'7d'/'30d'), and clarifies the purpose of 'market_id' and 'max_points'.
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 'price history for a prediction market' with a 'configurable period,' providing a specific verb and resource. However, it does not explicitly differentiate from sibling 'get_market' (which likely fetches current state), leaving implicit the distinction that this tool is for historical time-series data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'get_market' (current snapshot) or 'search_markets' (discovery). There are no prerequisites, exclusions, or 'see also' references to help the agent select the correct tool for historical analysis tasks.
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 full burden but fails to disclose behavioral traits. It doesn't confirm this is read-only (implied by 'Get' but not stated), doesn't explain what 'aggregate' encompasses (time periods? metrics?), and omits that results may vary based on trade history availability.
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?
Appropriately concise with clear structure. The one-sentence purpose statement followed by the Args block is efficient, though the docstring-style formatting ('Args:') is slightly programmatic compared to natural language descriptions.
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 single-parameter tool with an output schema (which excuses return value documentation). However, it should mention the default value ('shadow') in the description for visibility, and could clarify the relationship between 'performance' and the 'shadow'/'live' distinction given the existence of 'place_shadow_trade' and 'report_trade' siblings.
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?
Excellent compensation for 0% schema description coverage. The Args section clearly explains the 'mode' parameter semantics: 'shadow' for paper trades vs 'live' for real trades. It successfully documents the business meaning of the parameter values that the schema fails to describe.
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 'aggregate trading performance statistics' using the specific verb 'Get'. However, it doesn't fully distinguish from siblings like 'get_portfolio' or 'get_strategy'—it mentions 'aggregate' but doesn't clarify if this returns metrics like P&L vs. current holdings.
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 provided on when to use this tool versus alternatives like 'get_portfolio', 'report_trade', or 'get_strategy'. The Args section only documents the parameter syntax, not usage scenarios or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, yet description lacks safety disclosures (read-only status, idempotency), rate limits, or caching behavior. 'Get' implies read access but doesn't confirm whether credentials are required or what happens if portfolio is empty.
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?
Front-loaded with clear purpose statement. Args section is compact and functional despite unconventional docstring formatting. No redundant text.
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 single-parameter tool with output schema present. Missing behavioral context expected when annotations are absent. Does not mention default value in description text (though present in 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?
Excellent compensation for 0% schema coverage: explicitly defines 'mode' parameter values ('shadow' for paper trades, 'live' for real trades). Could improve by noting the default value or that the parameter is 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?
Clear verb ('Get') and resource ('portfolio positions and performance summary'). Implicitly distinguishes from sibling 'get_performance' by mentioning positions specifically, and from 'get_portfolio_strategy' by focusing on current holdings rather than strategy.
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 on when to use this tool versus siblings like 'get_performance' or 'get_portfolio_strategy'. No explanation of when to prefer 'shadow' versus 'live' mode or prerequisites for accessing live data.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry full behavioral disclosure. It mentions 'recent' and 'summary information' but fails to define the time window for 'recent', the sorting order, or what fields are excluded in the summary. No mention of pagination behavior beyond the limit parameter.
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 appropriately brief with no wasted words. The Args section is structured clearly, though the docstring format is slightly informal compared to natural prose. Information is front-loaded effectively.
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 single-parameter list tool with an output schema, the description is minimally adequate. However, given the presence of sibling tools like get_analysis and analyze_market, it lacks crucial context about the return format (summary vs. full details) and the temporal scope of 'recent' that would help an agent select the correct 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 0% schema description coverage, the description compensates by documenting the limit parameter as 'Maximum number of analyses to return.' However, it omits that the parameter is optional and has a default value of 20, which the schema shows but the description does not explain.
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 verb (List) and resource (analyses), and specifies the scope (recent with summary information). It implicitly distinguishes from analyze_market (creation) but does not explicitly differentiate from get_analysis (retrieval of specific record).
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 provided on when to use this tool versus alternatives like get_analysis (which presumably retrieves a specific analysis by ID). No mention of prerequisites, permissions, or typical workflows.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of disclosure, yet it reveals nothing about permissions required, rate limits, pagination behavior, or what constitutes a 'registered' webhook. It only implies a read-only operation through the verb 'List'.
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 extremely concise at only three words, with no redundant information. While efficient, it borders on underspecification given the lack of annotations and behavioral context, preventing a perfect score.
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 existence of an output schema and zero input parameters, the description meets minimum viable completeness for a simple listing operation. However, it fails to leverage the available description space to clarify scope (e.g., all webhooks vs. user-specific) or safety properties in the absence of annotations.
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 establishes a baseline score of 4 according to the evaluation rubric. There are no parameters requiring semantic elaboration beyond the schema structure.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and resource ('registered webhooks') clearly identifying the tool's function. However, it lacks explicit differentiation from sibling tools like create_webhook or delete_webhook, relying only on implicit verb contrast.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, nor does it mention prerequisites such as needing to list webhooks before deleting them or how it relates to webhook management workflows.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states 'Remove' but does not specify whether this is permanent, what happens to pending webhook deliveries, error conditions (e.g., if ID doesn't exist), or required permissions. It adds no behavioral context beyond what the tool name already implies.
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 extremely concise with zero redundant text. The purpose is front-loaded in the first sentence, followed immediately by the Args documentation. Every line serves a distinct function without filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has only one simple parameter and an output schema (relieving the description of needing to document return values), the description meets minimum viability by covering the action and parameter semantics. However, gaps remain regarding error handling, permanence of deletion, and side effects, which are unaddressed due to missing annotations.
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 0% schema description coverage, the description effectively compensates by documenting the webhook_id parameter in the Args section, specifying both its semantic meaning ('Webhook identifier') and its provenance ('returned by create_webhook'), which aids the agent in understanding the parameter's lifecycle context.
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 removes a registered webhook using a specific action verb and resource. While it distinguishes implicitly from siblings like create_webhook through the 'Remove' verb, it does not explicitly contrast usage with list_webhooks or create_webhook in the text.
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 lacks explicit guidance on when to use this tool (e.g., 'use when webhook is no longer needed') or when not to use it. The only contextual clue is the parameter description noting the ID comes from create_webhook, implying a lifecycle relationship, but this is insufficient for explicit usage guidelines.
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 mentions 'current' markets but lacks disclosure on caching, rate limits, authentication requirements, or what happens when no markets match the filter. With output schema present, it correctly omits return structure details, but other behavioral traits 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?
Front-loaded with a clear purpose statement followed by a structured Args section. No redundant or wasted sentences, though the docstring-style formatting is slightly verbose compared to inline prose.
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 listing tool with 2 parameters and an output schema (which handles return documentation). However, gaps in behavioral transparency and sibling differentiation leave it incomplete given the rich ecosystem of 20+ related tools.
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 description coverage is 0%, but the Args section excellently compensates by documenting both parameters: it specifies valid string values for 'source' ('kalshi', 'polymarket', or empty for all) and the valid range for 'limit' (1-100), adding crucial semantic meaning absent from the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
States specific verb (List) + resource (prediction markets) + scope (Kalshi and Polymarket platforms). However, it does not differentiate from siblings like 'search_markets' or 'screen_markets' which likely overlap in functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides no guidance on when to use this tool versus alternatives such as 'search_markets', 'get_market', or 'screen_markets'. No prerequisites or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. While 'Get' implies read-only, description does not confirm idempotency, safety guarantees, rate limits, or the format/scale of the returned probability (e.g., 0-1 vs percentage).
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?
Extremely concise with zero waste. Uses structured Args format that clearly maps to schema parameters. Front-loaded purpose statement followed by parameter 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?
Given output schema exists and parameters are well-documented in description, basic completeness is met. However, with zero annotations and schema coverage, the description should disclose behavioral traits (read-only nature, error conditions) which are absent.
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?
With 0% schema description coverage, the description fully compensates by documenting all three parameters in the Args section, including valid value enumerations for 'platform' (kalshi/polymarket) and 'period' (48h/7d/30d).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
States specific action ('Get') and resource ('consensus probability from aggregated agent trades'), clearly distinguishing from siblings like get_market or get_analysis. However, lacks explicit contrast with similar data-retrieval siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides no guidance on when to use this versus get_analysis or get_market, nor any prerequisites or conditions. Only states what the tool does, not when to choose it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It successfully signals state mutation via 'update P&L', indicating this is not a read-only operation. However, it omits idempotency guarantees, side effects on portfolio state, rate limits, or whether this triggers notifications/webhooks.
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?
Extremely efficient at 11 words in a single sentence. Front-loaded with the action ('Check') and scope ('all open trades'). No redundant phrases 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?
Adequate for a parameterless batch operation where an output schema exists to define return values. The description establishes the core function (resolution checking and P&L calculation) sufficiently for selection, though additional context about execution timing would be beneficial.
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 with 100% schema coverage (trivially satisfied). The description implies no filtering is possible ('all open trades'), which aligns with the empty schema. Baseline 4 applies as expected for parameterless tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool checks 'all open trades for market resolution' and performs P&L updates. The scope ('all open trades') implicitly distinguishes it from sibling get_resolution which likely handles single markets. However, 'Check' is slightly weak as a verb and could be more specific (e.g., 'resolve', 'settle').
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides no guidance on when to invoke this tool versus alternatives like get_resolution or report_trade. Does not indicate if this should be run periodically, on-demand, or after specific market events. No prerequisites or conditions 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 must carry the full burden. It successfully explains what 'resolution intelligence' encompasses (time urgency, mechanism, theta), adding context beyond the schema. However, it omits operational details like caching behavior, rate limits, or whether this requires specific permissions.
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 efficiently structured with the purpose front-loaded in the first sentence, followed by a clear Args section. Every sentence earns its place; there is no redundancy or verbose explanation of return values (appropriately deferred to the output schema).
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 only 2 primitive parameters and an output schema exists, the description is appropriately complete. It documents both parameters (compensating for schema deficiencies) and previews the key intelligence concepts returned. For this complexity level, no further elaboration is necessary.
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 0% description coverage, but the description compensates fully via the Args section. It documents both parameters: specifying valid platform values ('kalshi' or 'polymarket') and clarifying that market_id is platform-specific. This provides essential semantic context missing from the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves 'resolution intelligence' and specifies what that entails (time urgency, mechanism, theta estimate). It uses a specific verb-resource pair that distinguishes it from generic market tools like get_market. However, it lacks explicit differentiation from similar sibling 'check_resolutions'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like check_resolutions or get_analysis. There are no prerequisites, conditions, or workflow contexts 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?
No annotations provided, so description carries full burden. It discloses the caching behavior (data staleness), which is critical for arbitrage tools. However, it omits other behavioral details like cache duration, rate limits, or what constitutes an 'opportunity' in the output.
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?
Efficient two-part structure: single sentence for purpose, Args block for parameter details. No redundant text; every element 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?
Adequate for a single-parameter retrieval tool that has an output schema. The description covers the essential domain context (Kalshi/Polymarket), data freshness (cached), and parameter documentation. Missing minor details like cache TTL or error conditions.
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 0% schema description coverage, the description fully compensates by documenting the min_spread parameter with semantics (threshold), valid range (0.0-1.0), and default value (0.02/2%). Minor gap: doesn't explain what 'spread' measures (price difference between platforms?).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
States specific action (Get) and resource (cross-platform arbitrage opportunities) with clear scope (Kalshi and Polymarket). The '(cached)' notation implicitly distinguishes it from sibling 'get_arbitrage_live', though it could explicitly name the alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides implied usage guidance through the '(cached)' label, suggesting when to use this versus a live data source. However, it lacks explicit when-to-use/when-not-to-use rules or explicit mention of the 'get_arbitrage_live' alternative.
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 burden. It successfully discloses what metrics are returned (Brier score, hit rates, total signals), but omits operational details like read-only safety, rate limits, or caching behavior that would help an agent understand invocation 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?
Efficiently structured with the purpose front-loaded in the first sentence, followed by a clear Args section. No redundant text; 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 presence of an output schema, the description appropriately omits detailed return value explanations. All parameters are documented. Minor gap: doesn't explicitly state this is a safe read-only operation, though implied by the verb 'Get'.
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?
Despite 0% schema description coverage, the Args section comprehensively documents all 3 parameters with examples (e.g., 'crypto', 'politics') and valid values (e.g., '7d', '30d', 'shadow', 'live'), fully compensating for the schema deficiency.
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 it retrieves 'signal accuracy and calibration metrics' with specific examples (Brier score, hit rates). The mention of Brier score helps distinguish it from sibling tools like get_performance or get_analysis, though it doesn't explicitly contrast with them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides no guidance on when to use this versus get_performance or get_analysis, nor when to prefer 'shadow' vs 'live' mode. No prerequisites or exclusion criteria 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?
No annotations provided, so description carries full burden. It explains the 'why' (consensus aggregation) but omits safety-critical details: whether the report is permanent, if it triggers notifications, rate limits, or required permissions. 'Report' implies recording but doesn't specify side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Efficiently structured with purpose front-loaded in the first sentence, followed by a dense Args block. No redundant text; every line provides essential parameter constraints or purpose definition.
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 5 parameters with zero schema coverage, the Args block achieves complete parameter documentation. Since an output schema exists (per context signals), the description appropriately omits return value details. Only missing behavioral context prevents a 5.
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?
With 0% schema description coverage, the description fully compensates via the Args block, providing semantic meaning for all 5 parameters including valid value enumerations ('kalshi'/'polymarket', 'yes'/'no') and range constraints (0.0-1.0 for price) that the schema lacks.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
States specific action ('Report a trade') and distinct purpose ('consensus probability aggregation'), which differentiates it from read-only tools like get_consensus. However, it doesn't clarify the distinction from sibling place_shadow_trade, which sounds functionally similar.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides no explicit when-to-use guidance or alternative selection criteria. Given the sibling place_shadow_trade exists, the description fails to clarify whether this tool is for real executed trades versus simulated ones, or when to prefer one over the other.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the computational nature ('Compute') and the constraint that market_ids requires 'minimum 2' IDs. However, it lacks other behavioral traits like whether results are cached, idempotency, computational cost, or specific correlation methodology used.
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 efficiently structured with the action and purpose front-loaded in the first sentence, followed by a compact Args block. Every element serves a purpose—either establishing the tool's function or documenting parameters. Minor improvement possible by integrating the 'minimum 2' constraint into the main narrative.
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 presence of an output schema (covering return values) and the Args block (covering parameters), the description provides sufficient information for invocation. It appropriately omits return value details (handled by output schema) but could enhance completeness by mentioning the correlation calculation method (e.g., Pearson) or data freshness.
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?
Excellent compensation for 0% schema description coverage. The Args block documents all three parameters: market_ids (with minimum constraint), platform (explicitly listing valid values 'kalshi' or 'polymarket'), and period (listing valid values '48h', '7d', or '30d'). This provides critical semantic information entirely missing from the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'Compute[s] cross-market correlation graph' with the specific use case of 'portfolio diversification analysis.' The 'cross-market' qualifier effectively distinguishes it from siblings like analyze_market (single-market focus) and get_arbitrage (price disparity focus), though it doesn't explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context through 'for portfolio diversification analysis,' suggesting when the tool is valuable. However, it lacks explicit guidance on when NOT to use it or which siblings to prefer for other tasks (e.g., 'use get_arbitrage for price differences instead').
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 conveys that this is a simulated ('paper') trade rather than a real market execution, which is critical behavioral context. However, it omits other key traits like whether the operation creates persistent state, idempotency, or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured with a single purpose sentence followed by a standard Args docstring block. There is no redundant or filler text; every line provides essential information about the tool's function or its parameters.
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 3-parameter schema and existence of an output schema (which handles return value documentation), the description adequately covers inputs and basic purpose. However, it lacks safety/mutation context (e.g., destructive hints, idempotency) that would normally appear in annotations or a more detailed description.
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, requiring the description to compensate fully. The Args section excellently documents all three parameters: it provides a concrete example for 'ticker', enumerates valid values ('yes'/'no') for 'side' which the schema omits, and clarifies the currency unit for 'size_usd'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (Place), resource (paper/shadow trade), and context (prediction market, tracking purposes). However, it does not explicitly differentiate from the sibling tool `report_trade`, which could lead to confusion about when to use simulation versus reporting actual trades.
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 tracking purposes' provides implied guidance on when to use the tool (simulated tracking scenarios). However, it lacks explicit when-not guidance or mentions of alternatives like `report_trade` for real trades.
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 fails to disclose critical scraper-specific behaviors: whether this writes to a database (destructive), how long 'fresh' takes to fetch, rate limits, or failure modes if the external platform is down. 'Fetch' implies a network call but lacks operational specifics.
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 appropriately compact with a clear purpose statement followed by a structured Args section. Every sentence earns its place; there is no redundancy or unnecessary elaboration.
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 single-parameter schema and existence of an output schema (covering return values), the description adequately covers inputs. However, for a tool involving external API scraping, the absence of behavioral annotations or safety disclosures (read-only vs. write) leaves a significant gap in operational context.
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?
With 0% schema description coverage, the description fully compensates by documenting the 'source' parameter in the Args section, explicitly listing the valid enum values ('kalshi', 'polymarket', 'arbitrage') that the schema fails to constrain or describe.
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 ('Fetch fresh market data') and clearly identifies the resource (platform scraper). The term 'fresh' effectively distinguishes this from sibling 'get_' tools which likely return cached data, establishing its unique role in the toolset.
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 'fresh' implies real-time fetching versus cached alternatives, the description lacks explicit guidance on when to prefer this over siblings like 'get_market' or 'list_markets'. It does not mention prerequisites (e.g., API keys) or rate limiting concerns inherent to scrapers.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It effectively discloses the tool's behavioral output by specifying that it returns 'scored markets with an action recommendation' and explicitly lists the three possible recommendation values ('analyze', 'watch', 'skip'). This is crucial behavioral context for agent decision-making, though operational details like rate limits or caching are absent.
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 well-structured with a clear purpose statement, return value description, and a dedicated Args section. Information is front-loaded with the core function and output type. The Args section is efficiently formatted without redundancy, though it occupies more space than a high-schema-coverage tool would require.
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 presence of an output schema, the description appropriately focuses on parameter documentation and high-level behavioral output rather than detailed return structure. With 5 parameters and complex filtering logic, the description provides sufficient context for invocation by documenting all filters and the recommendation system, though it could note whether the operation is read-only.
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 0% description coverage, requiring the description to compensate fully. The Args section successfully documents all 5 parameters (market_ids, platform, min_volume_24h, min_score, limit) with sufficient semantics, including valid enum values for platform ('kalshi', 'polymarket', or ''). This fully compensates for the schema deficiency.
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 performs 'batch screening' of markets using score, volume, or specific IDs as criteria. It further distinguishes itself from sibling tools by specifying that it returns markets with action recommendations ('analyze', 'watch', or 'skip'), which implies a filtering/validation function distinct from simple listing or deep analysis.
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 term 'Batch screen' implies the tool is for bulk filtering operations, and the parameter descriptions suggest when to use specific filters (e.g., min_volume_24h). However, it lacks explicit guidance on when to choose this over siblings like search_markets, list_markets, or analyze_market, leaving the selection criteria somewhat implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It adds valuable context by listing specific output fields (probability estimate, edge assessment, scenarios, etc.) beyond what the output schema provides. However, missing safety disclosure (read-only vs destructive), error conditions (invalid ID, not-completed errors), or rate limiting behavior.
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?
Well-structured with clear separation: purpose statement, content enumeration, and parameter definition. No wasted words. Minor deduction for slightly formal 'Args:' docstring style which is necessary given poor schema coverage but slightly redundant in conversational context.
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 single-parameter retrieval tool with an output schema. The description covers the retrieval purpose, parameter meaning, and preview of returned data structure without needing to fully document the return format (handled by output schema). Lacks only error handling documentation for full 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?
Schema has 0% description coverage for the single parameter. The Args section effectively compensates by defining 'analysis_id' as 'Analysis identifier for a completed analysis,' adding the critical constraint that the analysis must be completed. Could improve by indicating where to obtain this ID (e.g., from list_analyses).
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 ('Retrieve') + specific resource ('full structured analysis result') and explicit scope ('completed analysis'). Effectively distinguishes from sibling 'check_analysis_status' (which only checks status) and 'analyze_market' (which creates analyses).
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 prerequisite via 'completed analysis' constraint, signaling not to use while analysis is running. However, lacks explicit guidance to use 'check_analysis_status' first for incomplete analyses and doesn't state when to prefer 'list_analyses' versus this specific retrieval.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses critical behavioral traits: the scan is 'fresh' (real-time calculation) and has high latency (10-30 seconds). However, it omits other behavioral details like error handling, rate limits, or whether this operation consumes API credits/quotas.
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 efficiently structured with the primary action in the first sentence, followed by a clear Args section. Every sentence earns its place—there is no redundancy or unnecessary elaboration. The timing warning is appropriately 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 single-parameter simplicity and existence of an output schema (which covers return values), the description is appropriately complete. It covers the action, performance characteristics, and parameter details. A minor gap is the lack of explicit differentiation from 'get_arbitrage,' but this is sufficient for tool selection.
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?
Despite 0% schema description coverage, the description fully compensates via the Args section. It provides the parameter's semantics (minimum spread threshold), valid range (0.0-1.0), and default value (0.02/2%), giving complete context that the schema fails to document.
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 performs a 'fresh cross-platform arbitrage scan' with specific verb (run/scan) and resource (arbitrage opportunities). The term 'fresh' effectively distinguishes it from sibling tool 'get_arbitrage' (implying cached vs. live data), though it doesn't explicitly name the alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides implicit usage guidance by warning that the operation 'may take 10-30 seconds,' hinting it shouldn't be used when immediate results are needed. However, it fails to explicitly direct users to 'get_arbitrage' as the faster/cached alternative or clarify when live vs. cached data is preferable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the full behavioral burden. It successfully clarifies the nature of the 'guidance' (spread/slippage estimates), distinguishing it from actual order placement. However, it lacks operational transparency: it does not state whether this is a read-only operation, if it incurs API costs, or whether the guidance is real-time versus cached.
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 efficiently structured with a clear first sentence summarizing purpose, followed by an Args section documenting parameters. Every sentence earns its place; there is no repetition of the tool name or tautological statements. The Args section is necessary given the lack of schema descriptions.
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 an output schema (not shown but indicated in context signals), the description appropriately focuses on input parameters and high-level purpose rather than return value structure. It adequately covers the two parameters. A minor gap remains: it does not clarify operational characteristics (rate limits, real-time vs. cached data) that would help an agent decide when to invoke it.
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, leaving both parameters undocumented. The description fully compensates by documenting both: platform specifies valid enum values ('kalshi' or 'polymarket') and market_id clarifies it is 'Platform-specific.' This completely addresses the schema deficiency.
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 ('Get') and resource ('execution guidance'), then clarifies the scope with concrete outputs ('spread analysis, slippage estimate, order recommendation'). This distinguishes it clearly from siblings like analyze_market or get_market by focusing specifically on trade execution parameters rather than general market data or analysis.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like analyze_market or get_arbitrage. It does not indicate prerequisites (e.g., whether market analysis should be run first) or when not to use it (e.g., for illiquid markets).
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. While it discloses the analytical components (correlation analysis), it fails to mention critical behavioral traits: whether it executes trades (vs. shadow/analysis only), rate limits, caching behavior, or idempotency. The 'Get' prefix suggests read-only but this is not confirmed.
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?
Uses efficient Python-docstring style with clear separation between purpose statement and Args documentation. No redundant text; every line serves either functional description or parameter clarification given the lack of schema metadata.
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?
Comprehensive for inputs given the parameter documentation and presence of output schema (which removes need to describe returns). Would benefit from explicit statement that this is an analytical/read-only operation (does not modify positions), but otherwise complete for a 4-parameter strategy 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?
With 0% schema description coverage, the Args section provides essential documentation for all 4 parameters. It clarifies semantics (e.g., 'market_query' is for 'bet or market question', 'portfolio' contains dicts with specific keys) and units (USD for bankroll, fraction for max_position_pct), fully compensating 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?
Description provides specific verb ('Get') + resource ('portfolio-aware strategy signal') + key differentiators ('position context and correlation analysis'). Clearly distinguishes from sibling 'get_strategy' by emphasizing portfolio-awareness and from 'get_correlation' by combining correlation with strategy generation.
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 'portfolio-aware' and mention of 'position context' implies usage when existing positions are held, but lacks explicit when-to-use/when-not-to-use guidance. Does not explicitly contrast with sibling 'get_strategy' to clarify selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It adds valuable constraint that search matches against 'market title' specifically (not descriptions or tags), but omits other behavioral traits like result ordering, case sensitivity, rate limits, or read-only safety.
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?
Description is efficiently structured with a single purpose sentence followed by a clear Args section. No redundant or wasted text; 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 presence of an output schema (covering return values) and the Args section documenting parameters, the description is nearly complete. Minor gap: lacks explicit read-only indication (since no annotations present) or mention of default limit=20 behavior.
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?
With 0% schema description coverage, the Args section fully compensates by clearly defining both parameters: query as the 'Search query string to match against market titles' and limit as 'Maximum number of results to return', including implied default 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?
Description provides specific verb ('Search'), resource ('prediction markets'), and scope ('by keyword in market title'), clearly distinguishing it from siblings like list_markets (browse all) and get_market (specific ID lookup).
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 versus alternatives like list_markets or screen_markets. While 'by keyword' implies filtering intent, the description does not state prerequisites or exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Mentions applicability to both 'running or completed' states, implying it's safe to call repeatedly. However, lacks disclosure of polling patterns, typical latency, rate limits, or cache behavior expected for status-checking tools.
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?
Front-loaded purpose statement followed by Args documentation. Efficient with no wasted words, though the Args format is slightly redundant with the schema structure (necessary given 0% schema coverage).
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 single-parameter status tool with output schema. Covers core workflow relationship to analyze_market. Gap: should mention typical async polling pattern since it explicitly handles 'running' analyses, and possible status values returned.
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 0% (no property descriptions), but the description compensates effectively by documenting the parameter inline: 'Analysis identifier returned by analyze_market.' This provides both semantic meaning (ID type) and provenance (source tool), though format constraints could be added.
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 ('Check') + specific resource ('status of a running or completed analysis'). The focus on 'status' effectively distinguishes this from sibling 'analyze_market' (which initiates) and 'get_analysis' (which likely retrieves results 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?
Establishes clear workflow context by stating the analysis_id is 'returned by analyze_market', indicating when to use the tool. However, lacks explicit guidance on when to prefer this over 'get_analysis' or polling best practices for long-running analyses.
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. Adds valuable behavioral details: POST method for notifications and HMAC signature verification mechanism. However, lacks operational context like retry behavior, idempotency concerns, or delivery guarantees.
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?
Efficiently structured with clear purpose statement followed by Args block. Every line adds value. No redundant or filler text. Front-loaded with the core action.
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 output schema exists (covering return values), the description adequately covers the 3 parameters and security model. Minor gap: doesn't mention error conditions, webhook lifecycle, or validation behavior that might be expected for a registration operation.
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 description coverage is 0%, but the Args section fully compensates by documenting all 3 parameters with specific semantics: url (HTTPS requirement, POST recipient), events (enumerated valid values), and secret (HMAC purpose). Exceeds baseline expectations for schema-free 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?
Clear specific verb (Register) + resource (webhook) + purpose (real-time event notifications). Distinguishes from sibling 'delete_webhook' and 'list_webhooks' through the specific action verb.
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 (use when needing real-time notifications) but lacks explicit guidance on when to choose this over list_webhooks/delete_webhooks, and doesn't mention prerequisites like URL validation 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?
With no annotations provided, the description carries full disclosure burden. It indicates a read operation via 'Get' and mentions 'detailed information,' but omits other behavioral traits like caching, rate limits, or error conditions (e.g., market not found). It meets minimum disclosure but doesn't enrich significantly beyond the operation type.
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 efficiently structured with the purpose front-loaded in the first sentence, followed by a compact Args section. Every line provides essential information without 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 the tool's moderate complexity (2 parameters) and the presence of an output schema, the description is nearly complete. It successfully documents all parameters despite poor schema coverage. A perfect score would require explicit read-only clarification (since annotations are absent) or explicit sibling differentiation guidance.
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?
Despite 0% schema description coverage, the Args section fully compensates by documenting both parameters with concrete examples (Kalshi ticker/Polymarket slug) and valid values ('kalshi', 'polymarket', or empty string). It adds critical semantic meaning entirely missing from the structured 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 ('Get') + resource ('prediction market') + scope ('detailed information'), clearly indicating this retrieves comprehensive data about a single market. The word 'specific' effectively distinguishes it from siblings like list_markets and search_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?
While 'specific' implies singular lookup versus browsing (list_markets) or searching (search_markets), the description lacks explicit guidance on when to choose this over alternatives. No prerequisites or 'when not to use' guidance is 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, description carries full burden and successfully discloses critical async behavior (immediate return, polling required, completion state). Lacks details on rate limits, concurrency constraints, or error conditions, but covers the essential lifecycle.
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?
Well-structured with clear sections for purpose, return behavior, workflow, and parameters. No wasted sentences. Minor deduction for slightly informal 'Args:' formatting, but remains highly readable and appropriately sized.
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 async complexity and 0% schema coverage, description successfully documents parameters and explains the polling workflow. Output schema exists (per context signals), so detailed return value explanation isn't required; mentioning analysis_id is sufficient.
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 has 0% description coverage. Description fully compensates by documenting both parameters: bet_text is defined as the 'Description of the bet or market question' and platform as a 'Source platform hint' with specific valid values ('kalshi', 'polymarket', or empty string).
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 action ('Start a deep research analysis pipeline') and resource ('prediction market bet'). Clearly distinguishes from siblings like get_analysis or check_analysis_status by emphasizing this initiates the pipeline rather than retrieving results.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit workflow guidance: returns immediately with analysis_id, poll with check_analysis_status every 5 seconds, then retrieve with get_analysis. Names specific sibling tools to use in sequence, making the async pattern unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It successfully discloses critical behavioral traits: blocking execution model and latency (30-90 seconds). It also clarifies the return type ('strategy signal with causal decomposition'). Minor gap: does not mention potential side effects, error states, or if the analysis is persisted.
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?
Front-loaded with purpose, followed by critical timing warning, alternative suggestion, and parameter docs. Every sentence serves a distinct function. No redundant or filler text despite covering multiple dimensions (purpose, timing, alternatives, parameters).
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?
Given existence of output schema (not shown but indicated), description appropriately focuses on invocation behavior rather than return value details. With only 2 parameters and 0% schema coverage, the description successfully compensates by documenting both. The blocking latency warning is essential for a long-running operation and is included.
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 description coverage is 0%, requiring description to compensate fully. It documents both parameters: 'market_query' is clearly defined as the bet/market question, and 'risk_limit' is identified for position sizing constraints. Slight deduction because 'Reserved for position sizing constraints' lacks units or value semantics (currency vs percentage).
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 opens with specific verb ('Run a full analysis') and resource ('strategy signal with causal decomposition'), clearly stating what the tool produces. Explicitly distinguishes from sibling async workflow ('analyze_market + check_analysis_status + get_analysis'), clarifying scope relative to alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use alternative: 'For async control, use analyze_market + check_analysis_status + get_analysis instead.' The blocking nature (30-90 seconds) implicitly guides when to use this versus the async flow.
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:

[![rekko-mcp MCP server](https://glama.ai/mcp/servers/Rekko-AI/rekko-mcp/badges/card.svg)](https://glama.ai/mcp/servers/Rekko-AI/rekko-mcp)

Score Badge

Copy to your README.md:

[![rekko-mcp MCP server](https://glama.ai/mcp/servers/Rekko-AI/rekko-mcp/badges/score.svg)](https://glama.ai/mcp/servers/Rekko-AI/rekko-mcp)

Latest Blog Posts

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

MCP directory API

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

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Rekko-AI/rekko-mcp'

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