telekash-mcp-server

Server Quality Checklist

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

Latest release: v0.8.0
Disambiguation5/5
Each tool has a clearly distinct purpose with no overlap: generate_api_key handles authentication, get_history provides historical trends, get_market_stats gives aggregate data, get_probability offers real-time odds, get_sentiment analyzes market psychology, get_trending identifies momentum, get_usage checks API limits, list_markets browses categories, and search_markets performs keyword searches. The descriptions clearly differentiate their functions, making misselection unlikely.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern using snake_case, such as generate_api_key, get_history, list_markets, and search_markets. This uniformity makes the toolset predictable and easy to navigate, with no deviations in naming conventions.
Tool Count5/5
With 9 tools, the count is well-scoped for a prediction market intelligence server, covering core functionalities like data retrieval, analysis, and management without being overwhelming. Each tool serves a specific, necessary role in the domain, making the set appropriately sized.
Completeness4/5
The toolset provides comprehensive coverage for accessing and analyzing prediction market data, including real-time probabilities, historical trends, sentiment, and market discovery. A minor gap exists in lacking tools for direct market interaction (e.g., placing bets or managing positions), but the described tools support core intelligence workflows effectively.
Average 4.1/5 across 9 of 9 tools scored. Lowest: 3.4/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
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

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 describes the return content (calls made today, calls remaining, tier, upgrade options) which is helpful, but lacks details on rate limits, authentication requirements, error conditions, or whether this counts against API usage itself. It adds some value but leaves significant gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured in two sentences: the first states the purpose, the second details the return values. Every word contributes meaning with zero waste, making it easy to parse and understand quickly.
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 no annotations and no output schema, the description provides basic completeness by explaining what the tool does and what it returns. However, for a tool that reports on API usage and limits, more detail on behavioral aspects (like whether calling it consumes API calls) would be beneficial. It's adequate but has clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters with 100% schema description coverage, so the schema fully documents the input requirements. The description appropriately doesn't discuss parameters, focusing instead on the tool's purpose and output. This meets the baseline expectation 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 states the tool's purpose with specific verbs ('Check', 'Returns') and resources ('API usage, rate limits, and tier status'). It distinguishes from siblings by focusing on API usage metrics rather than market data or key generation. However, it doesn't explicitly differentiate from 'get_history' which might also involve usage tracking.
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 doesn't mention prerequisites, frequency recommendations, or contrast with sibling tools like 'get_history' that might overlap in functionality. Usage context is implied but not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It describes what the tool returns ('probability snapshots showing how odds, sentiment, and market consensus have shifted') and the timeframe options, but doesn't mention important behavioral aspects like rate limits, authentication requirements, error conditions, or pagination for potentially large datasets.
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 three focused paragraphs: purpose, return values, and usage scenarios. Each sentence adds value, though the third paragraph could be slightly more concise by combining some of the use case examples.
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 tool with 2 parameters, 100% schema coverage, but no annotations or output schema, the description provides adequate context about what the tool does and when to use it. However, it lacks details about the return format structure, error handling, and operational constraints that would be important for an agent to use this tool effectively.
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?
With 100% schema description coverage, the schema already documents both parameters thoroughly. The description adds marginal value by mentioning the timeframe options in context ('over 1h, 24h, 7d, or 30d') but doesn't provide additional semantic context beyond what's in the schema descriptions for market_id and timeframe.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verbs ('Get historical probability changes and trend data') and resource ('for a prediction market over time'). It distinguishes from siblings like get_market_stats, get_probability, and get_sentiment by focusing on historical trends rather than current state or aggregated statistics.
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 usage context ('Use for trend analysis, momentum detection, volatility assessment...') and mentions specific applications like backtesting and identifying market-moving events. However, it doesn't explicitly state when NOT to use this tool or name specific alternatives among the sibling tools for different use cases.
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 behavioral traits like returning sentiment score (-1 to 1), actionable recommendation, and AI confidence level, which helps understand output. However, it lacks details on rate limits, error handling, or performance characteristics that would be useful for an agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded, starting with the core functionality. Each sentence adds value, such as explaining the return values and use cases, with no redundant or wasted 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 complexity (sentiment analysis with AI) and no output schema, the description does a good job explaining return values (sentiment score, recommendation, confidence). However, it could be more complete by detailing error cases or limitations, especially since annotations are absent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents the market_id parameter. The description does not add any specific meaning or usage details about the parameter beyond what the schema provides, such as examples or constraints, resulting in a baseline score.
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 performs 'AI-powered sentiment analysis, recommendation, and confidence score for any prediction market,' specifying both the action (get analysis) and resource (prediction market). It distinguishes from siblings like get_probability by emphasizing it 'goes beyond raw probability' to analyze psychology and crowd wisdom.
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 it: 'for trade signals, contrarian analysis, or augmenting your own prediction models with market sentiment data.' However, it does not explicitly state when not to use it or name alternatives among siblings, such as get_probability for raw probability data.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It mentions '500+ markets available' (scale), 'active betting markets' (scope), and data sources, but lacks details on rate limits, authentication needs, pagination, error handling, or response format. It adequately describes what the tool does but misses operational constraints.
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 and front-loaded with core functionality, followed by usage guidance and examples. It's appropriately sized but could be slightly more concise by integrating the category list into the first sentence. The example queries are helpful but add length.
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 tool with 5 parameters, no annotations, and no output schema, the description is moderately complete. It covers purpose, usage, and high-level behavior but lacks details on response format, error cases, and operational limits. Given the complexity, it should provide more behavioral context to compensate for missing structured data.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all 5 parameters thoroughly. The description adds minimal value by listing categories and mentioning filtering/sorting in general terms, but doesn't provide additional syntax, format, or interaction details beyond what the schema provides. Baseline 3 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 states the tool's purpose with specific verbs ('browse', 'discover', 'lists') and resources ('prediction markets'), and distinguishes it from siblings like 'search_markets' by emphasizing exploration rather than targeted searching. It explicitly mentions the three data sources and 7 categories.
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?
The description provides explicit usage guidance with 'Use when exploring what predictions are available, finding trending markets, or discovering betting opportunities,' which clearly differentiates it from siblings like 'search_markets' (likely for targeted queries) and 'get_trending' (likely for a curated list). The example queries further illustrate appropriate use cases.
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 effectively describes key behaviors: the API key is returned only once (ephemeral nature), requires immediate saving, and outlines rate limits and tier differences (free vs. paid). It misses details like error handling or authentication requirements, but covers critical operational aspects.
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 and front-loaded with the core purpose. However, the tier details (free, calibration, edge) could be more concise, as they occupy multiple lines without adding critical guidance for tool invocation. Most sentences earn their place, but some trimming would improve efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description does a good job covering key aspects: purpose, behavioral traits (key generation, one-time return, tier limits), and usage context. It lacks details on output format or error cases, but for a tool with simple parameters and clear intent, it is largely 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 100%, so the schema already documents both parameters (owner_id and owner_email). The description does not add any parameter-specific semantics beyond what the schema provides (e.g., it doesn't clarify format or usage examples). Baseline score of 3 is appropriate as the schema handles parameter documentation adequately.
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: 'Generate a free TeleKash API key for rate-limited access to prediction market intelligence.' It specifies the verb ('Generate'), resource ('API key'), and distinguishes it from sibling tools (which are data retrieval tools, not key generation tools).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on when to use this tool: to obtain API access for using other tools. It implicitly suggests alternatives (upgrading tiers for more features) but does not explicitly name when NOT to use it or compare to specific sibling tools. The guidance is practical but lacks explicit 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes the tool's function and data sources (Kalshi and Polymarket), but lacks details on rate limits, authentication requirements, error handling, or response format specifics. It provides basic context but misses deeper behavioral traits.
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 and front-loaded with core functionality, followed by usage guidelines and examples. While slightly longer due to examples, every sentence adds value by clarifying scope and application, avoiding redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (2 parameters, no output schema, no annotations), the description provides good contextual completeness. It covers purpose, usage, data sources, and examples, though it could benefit from more detail on response structure or error cases to fully compensate for the lack of output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters (market_id and query). The description doesn't add specific parameter semantics beyond implying that 'query' can be a natural language search, which is already covered in the schema. This meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verbs ('Get real-time probability, odds, and likelihood') and resources ('prediction market outcome'), distinguishing it from siblings like get_history or get_sentiment by focusing on current probability data rather than historical trends or sentiment analysis.
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?
The description provides explicit guidance on when to use this tool ('when asked about chances, odds, likelihood, forecasts, or predictions for any event') and includes specific examples across domains (elections, crypto, sports, etc.), clearly differentiating it from alternative tools like list_markets or search_markets that might handle broader market discovery.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It describes what data is returned but doesn't mention behavioral aspects like whether this is a read-only operation (implied but not stated), potential rate limits, authentication requirements, or data freshness. The description adds value by specifying the scope ('across all prediction markets') but lacks operational context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly structured and concise. The first sentence states the core purpose, the second enumerates specific statistics returned, and the third provides usage guidance. Every sentence earns its place with no redundant information, and it's front-loaded with the most important information first.
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 zero parameters and lack of annotations/output schema, the description provides good contextual completeness. It explains what statistics are returned and when to use the tool. However, without an output schema, it could benefit from more detail about the return format (e.g., whether it's a single object with nested fields). The description is complete enough for basic understanding but has minor gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters (schema coverage 100%), so the description doesn't need to explain parameters. The baseline for zero parameters is 4, and the description appropriately focuses on what the tool does rather than parameter semantics. It mentions the scope ('across all prediction markets') which helps understand the implicit parameterization.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verbs ('Get aggregate statistics') and resources ('across all prediction markets'), listing the exact types of statistics returned. It distinguishes from siblings like 'list_markets' (which likely lists individual markets) and 'get_trending' (which focuses on trending markets rather than aggregate statistics).
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?
The description explicitly states when to use this tool: 'Use for market overview, portfolio allocation decisions, or understanding the prediction market landscape.' This provides clear guidance on appropriate use cases, distinguishing it from siblings that serve different purposes like getting specific market probabilities or searching/filtering markets.
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 effectively describes key behaviors: it finds markets based on odds movement over specified timeframes, surfaces breaking events and sentiment shifts, and returns ranked markets with direction and current odds. However, it lacks details on rate limits, error handling, or authentication needs, which could be important for a tool accessing market data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and concise, with three sentences that each serve a distinct purpose: stating the tool's purpose, detailing its functionality and use cases, and explaining the return format. There is no wasted text, and it is front-loaded with the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (2 parameters, no output schema, no annotations), the description is mostly complete. It covers purpose, usage, and return values adequately. However, without annotations or an output schema, it could benefit from more details on behavioral aspects like error cases or data freshness, but it still provides sufficient context for effective use.
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 input schema has 100% description coverage, providing clear details for both parameters. The description adds minimal semantic context beyond the schema, mentioning 'Finds markets where odds moved most in the last 1h, 24h, 7d, or 30d,' which aligns with the 'timeframe' parameter but doesn't elaborate further. Since the schema is well-documented, a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get prediction markets with the biggest probability swings — momentum detection for trending events.' It specifies the verb ('Get'), resource ('prediction markets'), and scope ('biggest probability swings'), and distinguishes it from siblings like 'list_markets' or 'get_market_stats' by focusing on momentum detection rather than listing or general statistics.
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?
The description provides explicit guidance on when to use this tool: 'Use when looking for actionable opportunities, volatile markets, or events where consensus is rapidly changing.' It also implies alternatives by differentiating its purpose from siblings, such as using 'list_markets' for general listing or 'get_market_stats' for detailed statistics, without needing to name them directly.
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 and does well by disclosing key behaviors: it searches across three specific platforms, returns active markets sorted by relevance and trading volume, and handles natural language queries. It doesn't mention rate limits, authentication needs, or error conditions, but provides substantial operational context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured: first sentence states core function, second expands scope, third explains sorting, fourth gives usage guidance, followed by helpful examples. Every sentence adds value with zero wasted words, and key information 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?
For a search tool with 2 parameters, 100% schema coverage, and no output schema, the description is quite complete. It explains what platforms are searched, what types of content are covered, how results are sorted, and when to use it. The main gap is lack of output format details, but given the tool's relative simplicity, this is acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds minimal parameter semantics beyond the schema—it provides example queries that illustrate the 'query' parameter usage but doesn't explain 'limit' beyond what's in the schema. This meets but doesn't exceed baseline expectations.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verbs ('search', 'finds', 'returns') and resources ('500+ prediction markets', 'Kalshi, Polymarket, and Metaculus'). It distinguishes from sibling tools like 'list_markets' by specifying full-text search across multiple platforms rather than simple listing.
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?
Explicit guidance is provided: 'Use when looking for specific predictions, events, or outcomes to bet on.' This clearly indicates when to use this tool versus alternatives like 'list_markets' or 'get_trending', which likely serve different purposes.
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:

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

Score Badge

Copy to your README.md:

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

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/TeleKashOracle/mcp-server'

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