rankedtoday-mcp

by RyanKramer

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation4/5
Most tools have clearly distinct purposes: KDA, MMR estimation, climb calculation, hours played, latency, and countdown are all separate concerns. However, 'rankedtoday_tools' is vague and could be confused with 'readiness_reference' since both are informational rather than computational.
Naming Consistency3/5
Tool names mix patterns: some are verb_noun (estimate_mmr, climb_calculator), some are plain nouns (kda, season_countdown), and some are adjective_noun (readiness_reference, hardware_latency_budget). The style is mostly snake_case but lacks a consistent verb_noun or noun convention, making naming somewhat inconsistent.
Tool Count5/5
The server has 8 tools, which is a well-scoped number for a gaming analytics and utility server. Each tool earns its place by covering a distinct calculation or reference need, without bloating the set.
Completeness4/5
The tools cover core player needs: KDA, MMR, climb, hours, latency, and season countdown. Minor gaps exist, such as a direct rank conversion or winrate calculator, but these are not obvious dead ends and the overall domain of ranked gaming analytics is well covered.
Average 3.3/5 across 8 of 8 tools scored. Lowest: 2.1/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 2 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

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states what the tool 'is' (free tools and tests) rather than what it does, any side effects, or limitations. There is no transparency about operations, data handling, or interactions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, so it is concise in length. However it is under-specified to the point of being unhelpful, and the sole sentence does not meaningfully earn its place beyond stating an obvious category.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema (which is not described), the tool has no parameter schema and no behavioral context. The description fails to explain what the tool actually does, what results it returns, or how it integrates with sibling tools. For a zero-parameter tool, the complete lack of specificity leaves the agent without enough information to invoke it correctly or interpret its output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline for this dimension is 4. The description adds no parameter-level detail, but since there are no parameters to document, this is acceptable.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Free tools and cognitive tests on the web' is vague and does not specify a concrete action or resource. It reads as a category label rather than a tool purpose, and does not differentiate from sibling tools like kda or climb_calculator.
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 gives no context for selection, and the tool's relationship to its siblings is entirely unexplained.
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 disclose behavioral traits. It mentions 'honest, role-aware read,' hinting at role-based interpretation, but does not explain what this means for the calculation or output. There is no mention of edge cases, error handling, or how the tool handles invalid inputs.
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 very concise, front-loaded with the core action 'Calculate KDA.' The extra phrase 'honest, role-aware read' is brief but vague, reducing clarity slightly. Despite that, it remains appropriately sized for a simple calculator tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has an output schema, so return values are likely covered elsewhere. However, the description fails to explain the 'role-aware' behavior, which appears central to the tool's design. With no annotations and minimal parameter details, the description is not sufficient to fully understand the tool's semantics.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description should compensate. It implicitly conveys that kills, deaths, and assists are inputs (from the name) and that 'role' affects the calculation via 'role-aware.' However, it does not explain the role parameter's possible values or effect, leaving significant ambiguity for a non-obvious parameter.
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 calculates KDA, providing a specific verb and resource. It does not explicitly differentiate from sibling tools, but the name and context make the purpose unambiguous. However, the phrase 'honest, role-aware read' adds ambiguity rather than resolving it.
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?
There is no guidance on when to use this tool versus alternatives, nor are there exclusions or prerequisites. The only implied usage is 'when you need to calculate KDA,' which is minimal and does not clarify how the 'role-aware' aspect should influence tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility for behavioral disclosure. It only hints that the tool provides research findings, but it does not disclose whether the tool is static, how results are presented, or any limitations. This is a notable gap for a reference tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—two sentences, no filler. The first sentence states the topic, and the second explains the rationale for inclusion. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no parameters and an existing output schema, the description does not need to detail return values. However, it gives only a high-level summary of content coverage and does not specify what research areas or statistics are included, leaving some ambiguity about the tool's full scope.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the description is not required to explain parameter details. It still communicates the general domain of content, which adds a bit of semantic context beyond the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the topic ('What the research actually supports about cognition and gaming performance') but lacks a direct verb like 'provides' or 'returns.' It is not a tautology, but it doesn't explicitly define the tool's action or output format, making it only somewhat clear.
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 second sentence ('Included because these numbers get misquoted constantly') implies the tool is for retrieving accurate, research-backed figures. However, it does not explicitly state when to use this tool versus alternatives among the sibling tools, nor does it provide 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 burden of disclosing behavior. It adds useful context about LP totals being cumulative and gives an example (Gold IV to Plat IV = 400 LP), which clarifies the calculation basis. However, it does not explain edge cases like winrate extremes or what 'runs backward' means precisely, so transparency is only partial.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, both of which add value. The first states the core purpose, and the second provides a clarifying example. There is no redundancy or unnecessary detail, making it appropriately sized and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple calculator with an output schema, the description provides a reasonable overview of the calculation and a concrete LP example. However, the lack of annotation coverage and the 0% schema description coverage mean the agent must infer several parameter semantics. The description is adequate for selection but not fully complete for confident invocation without further reasoning.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for parameter explanations. The LP cumulative example helps interpret current_lp_total and target_lp_total, but it does not explain winrate_pct, lp_per_win, or lp_per_loss. These are left to the schema's basic type/default info, which is insufficient for an agent to correctly set values without additional domain knowledge.
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 states the tool calculates how many games a climb takes at a given winrate, or if it runs backward. This clearly identifies the tool's function as a climb calculator, distinguishing it from sibling tools like estimate_mmr or kda. However, the phrasing is indirect ('How many games... takes') rather than an explicit verb like 'calculates,' so it is not perfectly crisp.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the first sentence: use this tool when you need to know the number of games a climb requires at a given winrate. There is no explicit guidance on when not to use it or how it compares to alternatives such as estimate_mmr. The LP context helps but does not provide exclusions or direct alternatives.
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 explains the conceptual basis (asymmetry in LP flow) but does not disclose what the tool returns, the role of current_rank, or any limitations/caveats. This leaves significant behavioral unknowns 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 concise (three sentences) and front-loaded with the purpose. The following sentences explain the underlying signal, adding useful context without wasted words. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Even with an output schema, the description fails to explain key interface details: how current_rank influences the estimate, what the output format is, and whether there are prerequisites beyond LP gain/loss. Combined with absent annotations, the description is incomplete for confident invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions cover 0% of parameters, so the description must compensate. It offers partial context: 'LP flow' and 'wins and losses' suggest lp_gain and lp_loss are LP changes on win/loss, but it never explicitly defines them, and current_rank is not mentioned at all. This is insufficient for the agent to understand all parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb and resource: 'Estimate where your MMR sits relative to your rank, from LP flow.' This distinguishes it from sibling tools like climb_calculator or readiness_reference, which address different questions.
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 the tool: whenever you need to estimate MMR from LP gain/loss patterns. It does not explicitly mention alternatives or exclusions, but the context is unambiguous about its intended use case, which aligns with a score of 4.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but does not disclose any behavioral traits beyond the general purpose. It doesn't mention that this is a read-only estimation, what inputs are needed, or any limitations. The description only provides conceptual background, not behavioral 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 three sentences, front-loaded with the main purpose, and the subsequent sentences add valuable context without excess. It is concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description gives a clear conceptual overview but lacks practical guidance on parameter usage. With an output schema present, return values are covered, but the description does not explain how the parameters affect the result or what the expected inputs are.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameter descriptions, and the tool description does not mention any of the three parameters (refresh_hz, is_touchscreen, mouse_polling_hz). It provides only implicit context about hardware, which is insufficient to understand parameter meanings.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Estimate' and identifies the exact object: the hardware contribution to a reaction-test score. It clearly distinguishes from siblings like kda or hours_played.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the context of a reaction test and the role of hardware, indicating the tool is for isolating equipment effects. It does not explicitly exclude alternatives or mention when not to use, but the context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of disclosing behavioral traits. It adds valuable context by stating 'Expect about 20% error' and explaining the underlying rationale. However, it does not detail the calculation method or potential limitations beyond the error rate, leaving some transparency 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 two sentences, front-loaded with the main purpose and followed by concise explanatory context. Every sentence earns its place without redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (2 params, no nested objects), and the description provides the core purpose and error margin. However, the missing parameter semantics and lack of explicit usage boundaries leave gaps. The presence of an output schema reduces the need to explain return values, but the description still under-explains the minutes_per_game input.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has no parameter descriptions (0% coverage), and the description only touches on account_level by explaining its significance. It completely omits minutes_per_game, despite the schema showing a default of 35. The description fails to clarify what minutes_per_game modifies or how it affects the estimate, leaving a critical parameter unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Estimate lifetime hours from account level, with the math shown.' This uses a specific verb ('estimate') and resource ('lifetime hours'), and specifies the input signal (account level). It distinguishes itself from sibling tools like estimate_mmr by focusing on hours rather than MMR.
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 gives context for when to use the tool by explaining that level is the only signal reflecting whole account history, but it does not explicitly state when not to use it or mention alternatives. The phrase 'Levels are earned almost entirely by finishing games' implies its use case, but no direct comparison to sibling tools is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the burden. It discloses that from_date is optional and defaults to today, which is a key behavior. However, it does not mention handling of past dates, timezone, or inclusivity, leaving some gaps for a simple read-only tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, front-loaded with the core function, and every word serves a purpose. It avoids repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple countdown tool with an output schema, the description covers the essential usage and parameter behavior, though it could mention edge cases like past dates. It is largely complete for its complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must explain parameters. It explains from_date with format (YYYY-MM-DD) and its role, but it does not explicitly name or describe target_date, even though it's required. Context implies target_date is the countdown target, but it's not spelled out.
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 computes days remaining until a ranked season boundary or any other date, using a specific verb 'compute' and a clear resource (date countdown). This distinguishes it from sibling tools like kda or climb_calculator, which deal with different metrics.
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 gives clear context: use for countdown to a date, with optional from_date to set a fixed reference. It does not explicitly mention alternatives or when not to use, but the use case is clear given the sibling tool names.
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:

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

Score Badge

Copy to your README.md:

[![rankedtoday-mcp MCP server](https://glama.ai/mcp/servers/RyanKramer/rankedtoday-mcp/badges/score.svg)](https://glama.ai/mcp/servers/RyanKramer/rankedtoday-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/RyanKramer/rankedtoday-mcp'

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