Loading ToolBench
League of Legends math (MMR estimation from LP flow, climb projections, KDA, hours played) and cognitive-readiness reference data. Use these when the user asks about their rank, LP gains, how long a climb takes, or how sleep and fatigue affect gaming performance. Every estimate shows its arithmetic and its error bars.
RankedToday provides 5 well-intentioned tools with clear domain focus (League of Legends math). All tools have descriptions and input schemas are visible. However, several critical gaps limit production readiness: (1) Tool names lack action verbs, 'estimate_mmr', 'hours_played', 'climb_calculator', 'kda', 'readiness_reference' are noun-heavy or ambiguous; (2) Parameter descriptions are minimal (1-3 words each) and lack format/range guidance; (3) Output schemas are not formally documented, responses are inferred from code; (4) Error handling is present but minimal (only input validation, no recovery guidance); (5) No tool annotations (readOnlyHint, etc.) despite all being read-only operations. Descriptions are adequate (100-200 chars) but parameter-level documentation is weak.
How many games a climb takes at a given winrate, or whether it runs backward. LP totals are cumulative: one division is 100 LP, one tier is 400 LP. So Gold IV 0 LP to Plat IV 0 LP is 400.
Estimate where your MMR sits relative to your rank, from LP flow. Riot does not expose MMR and no site can read it. What MMR does leak is the exchange rate: when MMR matches rank, wins and losses move you roughly symmetrically. Asymmetry is the signal.
Estimate lifetime hours from account level, with the math shown. Levels are earned almost entirely by finishing games, so level is the only signal that reflects a whole account history. Expect about 20% error.
Calculate KDA with an honest, role-aware read.
What the research actually supports about cognition and gaming performance. Included because these numbers get misquoted constantly in both directions.
Tool names lack action verbs. 'estimate_mmr' and 'hours_played' are noun-based; 'readiness_reference' is purely nominal. LLMs infer intent from verb-first names (get_, calculate_, estimate_). Rename to 'estimate_mmr_from_lp', 'calculate_hours_played', 'get_readiness_reference'.
Parameter descriptions are too brief (1-3 words: 'LP gained per win', 'Account level'). Missing format constraints, ranges, and usage context. E.g., 'lp_gain' should be 'LP gained per win (positive integer, typically 15-30; higher at lower MMR)'. Baseline: 72 chars per param description.
Output schemas are not formally documented. Responses are inferred from code (e.g., estimate_mmr returns dict with 'mmr_vs_rank', 'estimated_drift_divisions'). LLMs need explicit schema docs to plan downstream calls. Add JSON Schema definitions or structured docstrings.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 56 | <=2025-11-25 | v2 |
No tool annotations despite all tools being read-only. FastMCP supports readOnlyHint. Add @mcp.tool(readOnlyHint=True) to all 5 tools to signal safety and enable agent optimizations.
Error handling is minimal. Only input validation (e.g., 'lp_gain and lp_loss must both be positive'). No recovery guidance. When climb_calculator rejects winrate_pct, return 'winrate_pct must be 0 - 100 (exclusive). Did you mean 50.5%?' to guide LLM self-correction.