OP.GG MCP Server
OfficialServer Quality Checklist
Latest release: v1.0.0
- Disambiguation4/5
Most tools have distinct purposes, but some overlap exists within game-specific categories. For example, 'lol-champion-analysis' and 'lol-champion-positions-data' both provide champion performance insights, which could cause confusion. However, descriptions clarify their focuses—detailed builds vs. positional analytics—helping agents differentiate.
Naming Consistency4/5Tools follow a consistent prefix-suffix pattern (e.g., 'lol-', 'tft-', 'valorant-') with descriptive names, but there are minor deviations like 'esports-lol-schedules' vs. 'lol-summoner-game-history' where 'esports-' and 'summoner-' prefixes vary. Overall, naming is readable and mostly predictable across the set.
Tool Count3/5With 24 tools, the count is borderline high for a single server covering multiple games (LoL, TFT, Valorant). While each game domain is well-represented, the total feels heavy and could overwhelm agents, suggesting the server might benefit from being split into more focused components.
Completeness5/5The tool set provides comprehensive coverage for each game domain, including data retrieval, analysis, and meta information. For LoL, it covers champions, summoners, and esports; for TFT, augments, builds, and decks; for Valorant, agents, maps, and player stats. No obvious gaps are present, enabling agents to handle varied queries effectively.
Average 3.4/5 across 24 of 24 tools scored. Lowest: 2.3/5.
See the Tool Scores section below for per-tool breakdowns.
- 1 of 1 community issues answered or closed in the last 6 months
- 0 commits in the last 12 weeks
- Last stable release on
- 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.
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.jsonto 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?
The description doesn't add meaningful behavioral context beyond what annotations already provide. Annotations clearly indicate this is a read-only, non-destructive, non-idempotent, closed-world operation. The description doesn't elaborate on what 'meta data' includes, potential rate limits, authentication requirements, or response format. However, it doesn't contradict the annotations, so it meets the lower bar with annotations present.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
While technically concise with just three words, the description is under-specified rather than efficiently informative. It fails to front-load essential information about the tool's function and lacks any structure that would help an AI agent understand what the tool actually does.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema and no parameters, the description is incomplete. It doesn't explain what 'meta data' encompasses, what format the response takes, or what specific information about Valorant maps is provided. The annotations cover safety aspects, but the description fails to address the core informational purpose of the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With zero parameters and 100% schema description coverage, the description doesn't need to explain parameters. The baseline for zero parameters is 4, as there's no parameter information to provide beyond what the empty schema already indicates.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Valorant map meta data' is a tautology that essentially restates the tool name 'valorant-meta-maps' without specifying what action the tool performs. It doesn't indicate whether this tool retrieves, analyzes, or provides metadata about Valorant maps, nor does it differentiate from sibling tools like 'valorant-meta-characters' or 'valorant-agents-composition-with-map'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does 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. There are multiple Valorant-related sibling tools (e.g., 'valorant-meta-characters', 'valorant-player-match-history'), but the description offers no context about when this specific map metadata tool is appropriate or what distinguishes it from other Valorant tools.
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?
Annotations indicate this is a read-only, non-destructive, non-idempotent, and closed-world operation. The description doesn't contradict these annotations, but it also adds no behavioral context beyond them. It doesn't explain what 'meta data' includes (e.g., character abilities, roles, patch updates), rate limits, or authentication needs, leaving gaps despite the annotations covering basic safety.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise ('Valorant character meta data'), which is efficient but under-specified. It's front-loaded with the core topic but lacks necessary elaboration to be helpful. While brevity is good, this description sacrifices clarity for conciseness, making it less effective for agent understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of an output schema and the tool's domain complexity (gaming meta data), the description is incomplete. It doesn't explain what data is returned (e.g., character lists, stats, patch notes) or how it's structured. With annotations covering only basic hints and no output schema, the description should provide more context about the tool's behavior and results, which it fails to do.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0 parameters and 100% schema description coverage, the schema fully documents the input requirements (none). The description doesn't need to compensate for any parameter gaps, as there are none. It appropriately avoids redundant parameter details, though it could hint at implicit inputs like filtering options if applicable, which it doesn't.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Valorant character meta data' is a tautology that essentially restates the tool name 'valorant-meta-characters'. It lacks a specific verb and doesn't clearly distinguish what operation is performed (e.g., retrieve, list, analyze). While it identifies the resource domain (Valorant characters), it doesn't specify what 'meta data' entails or how it differs from sibling tools like 'valorant-characters-statistics'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention any context, prerequisites, or exclusions, and fails to differentiate it from sibling tools such as 'valorant-characters-statistics' or 'valorant-agents-composition-with-map'. This leaves the agent with no basis for selecting this tool over others in the same domain.
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?
Annotations already declare readOnlyHint=true and other safety hints, so the agent knows this is a safe read operation. The description adds useful context about tier_data interpretation and recommendation use cases, which goes beyond annotations. However, it doesn't mention rate limits, data freshness, or other behavioral traits that would be helpful 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.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences but contains some redundancy (listing multiple metrics could be streamlined) and includes parenthetical commentary that could be integrated more cleanly. It's reasonably concise but not optimally structured, with the recommendation use case appended rather than front-loaded with core functionality.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (analytics retrieval with multiple metrics), good annotations, and 100% schema coverage, the description is adequate but has gaps. It explains what data is returned and includes a tier_data interpretation, but lacks output format details (no output schema) and doesn't address data scope (e.g., time period, patch version). The recommendation use case adds value but doesn't fully compensate for missing contextual elements.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already fully documents both parameters (format and lang). The description adds no parameter-specific information beyond what's in the schema. The baseline score of 3 is appropriate when the schema does all the parameter documentation work.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'Retrieves the analytics of champions by each positions' with specific examples of metrics like winrate, banrate, plays, and tier_data. It distinguishes from siblings by focusing on champion position analytics rather than schedules, standings, or other champion data types. However, it doesn't explicitly differentiate from 'lol-champion-analysis' which might overlap.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 'lol-champion-analysis' or 'lol-champion-leader-board'. It mentions recommending champions based on tier_data, but this is usage advice rather than tool selection guidance. No explicit when/when-not statements or sibling comparisons are included.
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?
Annotations indicate readOnlyHint=true, destructiveHint=false, openWorldHint=false, and idempotentHint=false, covering safety and idempotency. The description adds context by specifying it's for 'retrieving information,' which aligns with read-only behavior, and mentions 'TFT' (likely Teamfight Tactics), providing domain context not in annotations. It doesn't contradict annotations, and adds mild value beyond them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that states the tool's purpose without unnecessary words. It's appropriately sized for a simple retrieval tool, though it could be slightly more informative (e.g., clarifying 'TFT'). There's no wasted text, making it front-loaded and clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 1 parameter with full schema coverage and annotations covering safety, the description is minimally adequate. However, it lacks output schema, doesn't explain return values or format, and doesn't address complexity like pagination or error handling. For a retrieval tool, more context on what information is returned would improve completeness, but annotations provide some coverage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 1 parameter with 100% description coverage, detailing 'language' as champion names in League of Legends with an enum list. The description doesn't add any parameter semantics beyond the schema, such as default behavior or usage tips. With high schema coverage, the baseline score of 3 is appropriate as the description doesn't compensate but doesn't need to.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool 'retrieves information about item combinations and recipes' which provides a clear verb ('retrieving') and resource ('item combinations and recipes'), but it doesn't specify what 'TFT' means or differentiate from sibling tools like 'tft-champion-item-build' or 'tft-recommend-champion-for-item' that might handle similar TFT-related data. The purpose is understandable but lacks specificity about scope and distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention any prerequisites, context, or exclusions, and doesn't reference sibling tools like 'tft-champion-item-build' that might be related. Usage is implied only by the tool name and description, with no explicit instructions.
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?
Annotations indicate read-only, non-destructive, non-idempotent, and closed-world behavior, which the description does not contradict. The description adds value by specifying the tool provides 'comments,' implying analysis or insights, which goes beyond the annotations. However, it lacks details on rate limits, authentication needs, or output format, leaving some behavioral aspects unclear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that directly states the tool's purpose without unnecessary words. It is front-loaded and efficiently communicates the core function, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has annotations covering safety (read-only, non-destructive) and a well-documented input schema, the description provides basic purpose but lacks output details (no output schema) and deeper context like what 'comments' include or how they are generated. For a tool with two parameters and no output schema, more completeness would be beneficial, but annotations help mitigate gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with clear descriptions for 'puuid' and 'region' (including an enum for region). The description does not add meaning beyond the schema, as it does not explain how these parameters affect the comments (e.g., if puuid identifies a player for personalized analysis). Baseline score of 3 is appropriate since the schema adequately documents parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool 'provides comments on the playstyle of TFT champions,' which clearly indicates its function. However, it lacks specificity about what 'comments' entail (e.g., analysis, tips, summaries) and does not differentiate from sibling tools like 'tft-champion-item-build' or 'tft-recommend-champion-for-item,' which are related but distinct. The purpose is understandable but vague in scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 does not mention prerequisites, context (e.g., for a specific player or champion), or how it differs from sibling tools such as 'tft-champion-item-build' or 'tft-meta-trend-deck-list.' This leaves the agent without clear usage instructions.
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?
Annotations cover key behavioral traits (read-only, non-destructive, non-idempotent, closed-world), so the description does not need to repeat these. It adds no additional context beyond the basic purpose, such as rate limits or response format, but does not contradict the annotations, earning a baseline score for minimal added value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It is front-loaded and wastes no space, making it highly concise and well-structured for quick understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple input schema (one parameter with full coverage), annotations covering safety and scope, and no output schema, the description is adequate but minimal. It lacks details on return values or behavioral nuances, making it complete enough for basic use but not rich in context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the parameter 'shortName' fully documented in the schema, including an enum list. The description does not add any meaning beyond this, such as explaining league selection nuances, so it meets the baseline for high schema coverage without extra compensation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and resource ('team standings for a LoL league'), making the purpose immediately understandable. However, it does not explicitly differentiate from sibling tools like 'esports-lol-schedules' or 'lol-champion-leader-board', which might also involve league data but serve different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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, such as how it differs from 'lol-champion-leader-board' or other sibling tools. It lacks explicit context, prerequisites, or exclusions, leaving usage unclear beyond the basic purpose.
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?
Annotations provide key behavioral hints: readOnlyHint=true, openWorldHint=false, idempotentHint=false, destructiveHint=false. The description doesn't contradict these but adds minimal context beyond them—it only states the retrieval action without detailing aspects like rate limits, authentication needs, or data freshness. With annotations covering safety and idempotency, the description adds some value but lacks rich behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose without unnecessary words. It directly states what the tool does ('retrieves champion tier ranking list in brawl mode'), making it easy to parse and understand quickly. There's no wasted verbiage or structural fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (1 parameter, no output schema) and rich annotations (covering read-only, non-destructive behavior), the description is minimally adequate. It specifies the resource and mode but lacks details on return format, data scope, or error handling. For a retrieval tool with good annotations, it meets basic needs but could be more informative.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the 'lang' parameter fully documented via its enum and description. The tool description doesn't add any semantic details beyond what the schema provides (e.g., it doesn't explain default behavior or parameter implications). Given the high schema coverage, a baseline score of 3 is appropriate, as the description doesn't compensate but also doesn't detract.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Retrieves champion tier ranking list in brawl mode.' It specifies the verb ('retrieves'), resource ('champion tier ranking list'), and context ('brawl mode'), which is specific and unambiguous. However, it doesn't explicitly distinguish this tool from its siblings (e.g., 'lol-champion-leader-board'), which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'lol-champion-leader-board' or 'lol-champion-analysis', nor does it specify any prerequisites, exclusions, or contextual cues for usage. This lack of comparative context leaves the agent without clear direction.
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?
Annotations indicate readOnlyHint=true and destructiveHint=false, which the description aligns with by using 'retrieves' (implying a read operation). The description adds value by specifying the type of data returned ('statistics and performance metrics'), but does not provide additional behavioral context like rate limits, authentication needs, or data freshness, which are not covered by annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It is front-loaded with the core action ('retrieves meta data') and includes key details ('statistics and performance metrics'), making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (2 parameters, no output schema) and rich annotations, the description is minimally adequate. It covers the basic purpose but lacks details on output format, error handling, or differentiation from siblings. For a read-only tool with full schema coverage, it meets the minimum viable standard but could be more informative.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with clear enum lists and descriptions for both parameters. The description does not add any semantic details beyond what the schema provides, such as explaining the format of 'champion' names or the impact of 'lang' on localization. With high schema coverage, 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.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Retrieves meta data for a specific champion, including statistics and performance metrics.' It specifies the verb ('retrieves'), resource ('meta data for a specific champion'), and scope ('statistics and performance metrics'), but does not explicitly differentiate it from sibling tools like 'lol-champion-analysis' or 'lol-champion-positions-data', which may have overlapping purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention sibling tools like 'lol-champion-analysis' or 'lol-champion-positions-data', nor does it specify prerequisites or contexts for usage, such as needing a specific champion name from the provided enum list.
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?
Annotations already provide readOnlyHint=true and destructiveHint=false, so the agent knows this is a safe read operation. The description adds context about retrieving 'currently on sale' information, which implies real-time or frequently updated data, but doesn't specify update frequency, rate limits, or authentication requirements. It doesn't contradict annotations, but adds minimal behavioral context beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that clearly states the tool's purpose without unnecessary words. It's appropriately sized for a simple retrieval tool and front-loads the essential information. Every word earns its place in communicating the core functionality.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read operation with good annotations (readOnlyHint, destructiveHint) and a well-documented single parameter, the description is adequate but has gaps. Without an output schema, the description doesn't indicate what information is returned about the sale skins (prices, discounts, availability, etc.). Given the tool's simplicity and good annotation coverage, the description meets minimum requirements but could better explain the return format.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the single parameter 'lang' fully documented in the schema including its purpose, enum values, and requirement. The description doesn't add any parameter information beyond what's in the schema. With high schema coverage and only one parameter, the baseline score of 3 is appropriate as the schema carries the full parameter documentation burden.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does 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 ('Retrieves information') and resource ('champion skins that are currently on sale'). It distinguishes itself from siblings by focusing specifically on sale information rather than general champion data, analysis, or other game aspects. However, it doesn't explicitly differentiate from all possible siblings in the list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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. With many sibling tools available (like lol-champion-meta-data, lol-champion-analysis, etc.), there's no indication of when sale information is needed versus other champion data. The description only states what it does, not when it should be selected.
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?
Annotations indicate read-only, non-destructive, non-idempotent, and closed-world behavior, which the description doesn't contradict. The description adds minimal context beyond this, as it doesn't specify rate limits, authentication needs, or what 'retrieving' entails (e.g., real-time data or cached info). With annotations covering basic safety, a 3 is appropriate for the limited added value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It's front-loaded and appropriately sized for a simple retrieval tool, making it easy to parse quickly. Every part of the sentence serves a clear function, earning a high score for conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (one parameter, no output schema) and rich annotations, the description is minimally adequate. It covers the basic purpose but lacks details on usage context, output format, or how it fits with sibling tools. For a retrieval tool in a crowded domain, more completeness would be beneficial, but it meets the minimum viable threshold.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with 'championId' clearly documented. The description doesn't add any parameter details beyond what the schema provides, such as format examples or valid champion IDs. Since the schema does the heavy lifting, the baseline score of 3 is justified, as no extra semantic value is contributed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: retrieving champion item build information for TFT. It specifies the verb 'retrieving' and the resource 'champion item build information', making it understandable. However, it doesn't differentiate from sibling tools like 'tft-meta-item-combinations' or 'tft-recommend-champion-for-item', which might have overlapping functionality, so it's not a perfect 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention any prerequisites, context, or exclusions, such as whether it's for current meta builds or general information. With many sibling tools in the TFT and League of Legends domains, this lack of differentiation is a significant gap.
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?
Annotations provide readOnlyHint=true and destructiveHint=false, indicating a safe read operation. The description adds that it 'retrieves' recommendations, which aligns with annotations, but doesn't disclose additional behavioral traits like rate limits, authentication needs, or what the output looks like. With annotations covering safety, the description adds minimal context, meeting the lower bar.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It's front-loaded and wastes no space, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has annotations covering safety (read-only, non-destructive) and a simple input schema with full coverage, the description is adequate for a basic retrieval tool. However, with no output schema and no details on return values or behavior, it leaves gaps in understanding what the tool actually provides, making it minimally complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the parameter 'itemId' well-documented in the schema as 'TFT item ID to get champion recommendations for'. The description doesn't add any extra meaning or examples beyond this, so it relies on the schema. With high coverage, the baseline score of 3 is appropriate as the description doesn't compensate but doesn't need to.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose as 'retrieving champion recommendations for a specific item' with a specific verb ('retrieving') and resource ('champion recommendations'), making it understandable. However, it doesn't distinguish this from sibling tools like 'tft-champion-item-build' or 'tft-meta-item-combinations', which might have overlapping functionality in the TFT context, so it lacks explicit differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, context, or exclusions, and with sibling tools like 'tft-champion-item-build' and 'tft-meta-item-combinations' that could be related, the absence of usage guidelines leaves the agent without direction on tool selection.
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?
Annotations already declare readOnlyHint=true and destructiveHint=false, indicating a safe read operation. The description adds no behavioral context beyond this, such as rate limits, authentication needs, or data format details. Since annotations cover the safety profile, a baseline score is appropriate, but no additional value is provided.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It is front-loaded and appropriately sized, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (1 parameter, no output schema) and rich annotations (read-only, non-destructive), the description is minimally adequate. However, it lacks details on return values or how the data is structured, which could be helpful since there is no output schema. It meets basic needs but has gaps in completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the parameter 'mapId' fully documented in the schema. The description does not add any meaning beyond what the schema provides, such as examples or constraints on map IDs. Baseline score is justified 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.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'retrieve' and the resource 'agent composition data for a Valorant map', making the purpose specific and understandable. However, it does not explicitly differentiate from sibling tools like 'valorant-meta-maps' or 'valorant-meta-characters', which might offer related but distinct data, so it falls short of a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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, such as how it differs from sibling tools like 'valorant-meta-maps' or 'valorant-meta-characters'. It lacks explicit context, prerequisites, or exclusions, leaving usage unclear beyond the basic purpose.
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?
Annotations already declare readOnlyHint=true and destructiveHint=false, indicating a safe read operation. The description adds no behavioral context beyond this, such as rate limits, authentication needs, or response format details. It doesn't contradict annotations, so it meets the baseline for having annotations but adds minimal extra value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It's front-loaded with the core action and resource, making it highly concise and well-structured for quick understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple parameter schema and annotations covering safety, the description is minimally adequate. However, with no output schema and multiple sibling tools, it lacks details on return values or differentiation, making it incomplete for optimal agent use in a crowded context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage with a clear enum for 'region', so the schema fully documents the parameter. The description mentions 'by region' but adds no semantic details beyond what the schema provides, such as explaining region codes or default behaviors, resulting in a baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'fetch' and the resource 'Valorant leaderboard by region', making the purpose specific and understandable. However, it doesn't explicitly differentiate from sibling tools like 'valorant-player-match-history' or 'valorant-meta-characters', which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, exclusions, or compare it to related sibling tools like 'valorant-player-match-history' or 'valorant-meta-maps', leaving usage context unclear.
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?
Annotations already indicate read-only, non-destructive, non-idempotent, and closed-world behavior, so the description doesn't need to repeat these. It adds context by specifying the resource ('match history') and required inputs, but doesn't disclose additional traits like rate limits, error handling, or data format, which could be useful given the lack of an output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core action ('Retrieve match history') and specifies the required inputs. There is no wasted wording, making it highly concise and well-structured for quick understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple input schema with full coverage and annotations covering safety, the description is adequate for a read-only tool. However, without an output schema, it doesn't explain return values (e.g., match details, timestamps), which could leave gaps in understanding the tool's full behavior for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with clear descriptions for both parameters in the input schema. The description mentions 'game name and tag line' but doesn't add meaning beyond what the schema provides, such as format examples or validation rules, so it 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.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Retrieve') and resource ('match history for a Valorant player'), making the purpose specific and understandable. However, it doesn't explicitly differentiate from sibling tools like 'valorant-leaderboard' or 'valorant-characters-statistics', which might also involve player data but serve different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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, such as other Valorant-related tools in the sibling list. It lacks context on prerequisites (e.g., needing a valid game name and tag line) or exclusions, leaving usage unclear beyond the basic action.
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?
Annotations already declare readOnlyHint=true, destructiveHint=false, openWorldHint=false, and idempotentHint=false, covering safety and idempotency. The description adds no behavioral context beyond what annotations provide, such as rate limits, data freshness, or response format. However, it doesn't contradict annotations, so it meets the lower bar with annotations present.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without any fluff or unnecessary details. It's front-loaded and appropriately sized for a simple tool, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 parameters, no output schema) and rich annotations, the description is adequate but minimal. It covers the basic purpose but lacks context on usage guidelines or behavioral nuances, which could help in a crowded sibling toolset. It meets minimum viability but has clear gaps in completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0 parameters and 100% schema description coverage, the schema fully documents the lack of inputs. The description doesn't need to add parameter details, so it appropriately avoids redundancy. A baseline of 4 is justified as it doesn't mislead or omit necessary information about parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get') and resource ('upcoming LoL match schedules'), making the purpose specific and understandable. However, it doesn't explicitly differentiate from siblings like 'lol-summoner-game-history' or 'valorant-player-match-history', which might also involve schedules or match data, so it doesn't fully achieve sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention context, prerequisites, or exclusions, leaving the agent to infer usage from the name alone. This is a significant gap given the many sibling tools that could overlap in functionality.
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?
Annotations indicate read-only, non-destructive, non-idempotent, and closed-world behavior, which the description doesn't contradict. The description adds valuable context beyond annotations by explaining the tool's purpose for teaching champion playstyles and suggesting follow-up actions (e.g., retrieving champion performance or match history), enhancing behavioral understanding without repeating structured data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is somewhat verbose and could be more front-loaded; it mixes the core purpose with usage suggestions in a single run-on sentence. While not excessively long, it lacks tight structure, with the second part about teaching champion playstyles feeling tacked on rather than integrated efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (2 required parameters, no output schema), the description covers the basic purpose and usage intent. However, it doesn't detail return values (e.g., leaderboard format or data fields) or error handling, leaving gaps that could hinder an agent's ability to use the tool effectively without additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage with clear enums for 'champion' and 'region', so the schema already documents parameters thoroughly. The description doesn't add significant meaning beyond what the schema provides, such as explaining parameter interactions or constraints, resulting in a baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves a leaderboard of master players for a specific champion, which is a specific verb+resource combination. However, it doesn't explicitly differentiate from sibling tools like 'lol-champion-analysis' or 'valorant-leaderboard' that might have overlapping purposes, preventing a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by mentioning looking up high-ranked players for teaching purposes, but it doesn't provide explicit guidance on when to use this tool versus alternatives like 'lol-champion-analysis' or 'lol-summoner-search'. The context is somewhat clear but lacks specific exclusions or comparisons.
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?
Annotations indicate this is a read-only, non-destructive, non-idempotent, closed-world tool. The description adds minimal behavioral context beyond this, as it doesn't specify what 'current meta decks' entails (e.g., update frequency, data source, or format). However, it doesn't contradict the annotations, so it meets the baseline with some added value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's function without any fluff or redundancy. It's front-loaded and appropriately sized for its purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (simple retrieval with no parameters), annotations cover safety aspects, and no output schema exists, the description is adequate but incomplete. It lacks details on what 'meta decks' includes (e.g., deck lists, win rates, tiers) or return format, which could help an agent use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description doesn't add parameter information, which is appropriate here, earning a baseline score of 4 for not requiring compensation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose as 'retrieving current meta decks' for TFT, which is a specific verb+resource combination. However, it doesn't distinguish itself from sibling tools like 'tft-champion-item-build' or 'tft-meta-item-combinations' that might also relate to TFT meta information, so it lacks sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention any context, prerequisites, or exclusions, such as whether it's for competitive play or casual use, or how it differs from other TFT-related tools in the sibling list.
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?
Annotations cover read-only, non-destructive, non-idempotent, and closed-world hints. The description adds context about optional map filtering, which is useful but doesn't disclose additional behavioral traits like rate limits, data freshness, or response format. With annotations providing safety profile, this meets baseline expectations without contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose and includes the optional parameter. There is no wasted verbiage, and it directly communicates the tool's functionality without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and annotations covering basic hints, the description adequately explains what the tool does but lacks details on return values (e.g., statistics format) or error conditions. For a read-only tool with one optional parameter, this is minimally viable but leaves gaps in full context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single parameter (mapId), so the schema already documents it fully. The description mentions optional filtering by map but adds no extra meaning beyond what the schema provides, such as example map IDs or filtering effects. Baseline 3 is appropriate given high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Retrieve' and resource 'character statistics data for Valorant', with optional filtering by map. It distinguishes from some siblings (e.g., valorant-leaderboard, valorant-player-match-history) but not all (e.g., valorant-meta-characters might overlap). The purpose is specific but sibling differentiation could be more explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when needing character statistics with optional map filtering, but provides no explicit guidance on when to use this tool versus alternatives like valorant-meta-characters or valorant-agents-composition-with-map. It mentions the optional parameter but lacks context on typical use cases or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true and destructiveHint=false, so the agent knows this is a safe read operation. The description adds context about what data is retrieved ('recent match history') and implies it's for improvement/advice purposes, which adds some behavioral context beyond the annotations. However, it doesn't mention rate limits, authentication needs, or what 'recent' means in terms of timeframe.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately concise with two sentences. The first sentence states the purpose clearly, and the second provides usage guidelines. There's no wasted language, though the second sentence could be slightly more structured. The information is front-loaded with the core purpose first.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that annotations cover the safety profile (read-only, non-destructive) and the schema has 100% coverage for parameters, the description provides good contextual completeness. It explains when to use the tool and what it returns. The main gap is the lack of output schema, but the description mentions what data is retrieved ('recent match history'), which helps compensate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with all parameters well-documented. The description doesn't add any additional parameter semantics beyond what's already in the schema. It mentions 'specific summoner' which aligns with the game_name/tag_line parameters, but provides no new information about parameter usage or relationships.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Retrieves the recent match history of a specific summoner.' This is a specific verb+resource combination that tells exactly what the tool does. However, it doesn't explicitly differentiate from sibling tools like 'lol-summoner-search' or 'valorant-player-match-history' which might have overlapping functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidelines: 'If a user mentions a specific summoner, wants to know about their recent matches, wants to know how to improve or wants to get an advice, you *must* always call this function.' This gives clear triggers for when to use the tool, including specific user intents and scenarios.
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?
Annotations indicate this is a read-only, non-destructive, non-idempotent, and closed-world operation. The description adds context by specifying it's for 'renewing' data via RiotAPI, which suggests it might fetch fresh data or update a cache, aligning with the non-idempotent hint. However, it doesn't detail rate limits, authentication needs, or what 'renew' entails beyond the annotations, leaving some behavioral aspects unclear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences that directly state the purpose and usage guidelines. It's front-loaded with the main action and avoids unnecessary details, though the second sentence could be slightly more specific about 'next functions' to improve clarity without adding bulk.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (3 required parameters, no output schema) and rich annotations, the description is mostly complete. It covers purpose and critical usage order, but lacks details on what 'renew' means operationally (e.g., caching behavior, response format) and doesn't reference sibling tools explicitly, which could enhance context for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, clearly documenting all three parameters (game_name, tag_line, region) with examples and enum values. The description doesn't add any parameter-specific information beyond what the schema provides, so it meets the baseline of 3 for high schema coverage without extra value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Renew the summoner's data') and resource ('OP.GG through RiotAPI'), making the purpose understandable. However, it doesn't explicitly differentiate from sibling tools like 'lol-summoner-search' or 'lol-summoner-game-history', which likely handle related summoner data operations, leaving some ambiguity about unique scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance: 'When you retrieve summoner data, you *must* always call this function first, and then call the next functions.' This clearly indicates a prerequisite order and implies alternatives (the 'next functions'), though it doesn't name specific sibling tools, it strongly guides when to use this tool versus others.
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?
Annotations already indicate this is a read-only, non-destructive, idempotent operation with a closed world. The description adds valuable context by specifying the CSV output format and the specific fields returned (champion_id, key, name), which goes beyond what annotations provide. However, it doesn't mention potential rate limits, data freshness, or error handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences that efficiently convey the tool's purpose, output format, and parameter effect. Every word serves a purpose with no redundancy or unnecessary elaboration, 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.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (single parameter, read-only operation) and rich annotations, the description is reasonably complete. It specifies the output format (CSV) and fields returned, which compensates for the lack of output schema. However, it could benefit from mentioning whether this returns all champions or has limitations, and how the CSV is structured.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the 'lang' parameter fully documented in the schema including enum values and purpose. The description mentions that language determines champion names, which aligns with but doesn't add significant meaning beyond the schema. Baseline 3 is appropriate since the schema carries the full parameter documentation burden.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Retrieves metadata'), resource ('all League of Legends champions'), and output format ('CSV format with champion_id, key, and name'). It distinguishes from siblings like 'lol-champion-meta-data' by specifying the CSV format and limited fields, making the purpose unambiguous and differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for obtaining localized champion metadata in CSV format, but provides no explicit guidance on when to use this tool versus alternatives like 'lol-champion-meta-data' or other champion-related tools. It mentions the language parameter but doesn't clarify scenarios where this specific output format is preferred.
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?
Annotations already declare readOnlyHint=true and destructiveHint=false, indicating a safe read operation. The description adds valuable context about the data scope (detailed champion info, high winrate champions, counter picks in weakCounters field) and behavioral expectation ('assume the position user want to know'), which goes beyond annotations. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose but becomes verbose with repetitive usage instructions ('you must always call', 'should also occasionally call', 'also you need to call'). Some sentences could be consolidated for better efficiency, though all content is relevant.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (4 required parameters) and lack of output schema, the description provides good context on data returned (win rates, builds, skill orders, items, counter picks) and usage scenarios. However, it doesn't detail response format or potential limitations, leaving some gaps for a tool with no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with clear enum descriptions for all parameters. The description adds minimal parameter semantics beyond the schema, mentioning 'position' assumption and 'high winrate champions' but not elaborating on parameter interactions or effects. Baseline 3 is appropriate given the comprehensive schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Retrieves very detailed information about a specific champion' and lists specific data types (win rate, pick rate, recommended builds, etc.). It distinguishes itself from siblings by focusing on champion-specific analysis rather than schedules, standings, or other game aspects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage rules: 'must always call this function' when a champion is mentioned, 'should also occasionally call' for gameplay tips, and specifies scenarios like 'what items should I buy?' or 'which skill should I level up?'. It also references the 'weakCounters' field for counter picks, though it doesn't explicitly name alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds valuable behavioral context beyond annotations by specifying the output format (CSV) and listing the exact fields returned (apiName, desc, name, tier, imageUrl). While annotations already indicate it's read-only, non-destructive, and idempotent, the description provides concrete implementation details about the response structure that aren't covered by structured fields.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly front-loaded in a single, efficient sentence that contains all essential information: action, resource, format, fields, and parameter context. Every word earns its place with zero redundancy or unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with excellent annotations and full parameter documentation, the description provides nearly complete context. It specifies the output format and exact fields, though without an output schema, it doesn't detail CSV structure (headers, ordering, etc.). The combination of description and structured data leaves only minor gaps about output formatting specifics.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the input schema already fully documents the single 'lang' parameter with its enum values and purpose. The description mentions 'specified language' but doesn't add meaningful semantic information beyond what's already in the schema's comprehensive description field.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Retrieves'), resource ('metadata for all Teamfight Tactics augments'), and specific output format ('CSV format') with explicit fields returned. It distinguishes itself from sibling tools by focusing on TFT augments metadata rather than champion data, esports, or other game modes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context about when to use this tool ('for all augments in the specified language') and implies it's for retrieving comprehensive augment metadata. However, it doesn't explicitly state when NOT to use it or name specific alternatives among the sibling tools for similar data needs.
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?
The description adds valuable behavioral context beyond the annotations. While annotations indicate read-only and non-destructive operations, the description specifies that this is a search/retrieval tool that may fail if the summoner isn't found, and provides guidance on how to handle such failures (asking about region). This enhances the agent's understanding of real-world usage patterns.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured in three sentences: purpose statement, mandatory usage rule, and error handling guidance. Each sentence serves a distinct function with minimal redundancy. The only minor improvement would be slightly more polished phrasing in the error handling sentence.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only lookup tool with comprehensive annotations and full parameter documentation, the description provides excellent contextual guidance about when and how to use it. The main gap is the lack of output schema, but the description compensates by indicating what information will be returned (rank, win rate, match history). The error handling guidance is particularly valuable for agent decision-making.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the input schema already fully documents all four parameters. The description doesn't add any parameter-specific information beyond what's in the schema, so it meets the baseline expectation but doesn't provide additional value regarding parameter usage or relationships.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Retrieves information') and resource ('about a specific summoner'), with concrete examples of what information is retrieved ('rank, win rate, and recent match history'). It effectively distinguishes itself from siblings like 'lol-summoner-game-history' by focusing on summoner profile data rather than detailed match history.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage instructions: 'If a user mentions a specific summoner or wants to know about themselves, you *must* always call this function.' It also specifies an alternative action for failure cases: 'If you can't find the summoner, ask to the user which region do they play.' This gives clear when-to-use and fallback guidance.
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:
Score Badge
Copy to your README.md:
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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/opgginc/opgg-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server