Skip to main content
Glama
BK927
by BK927

ow_meta

Read-onlyIdempotent

Compare Overwatch hero aggregate percentages across maps, tiers, or source regions. Note: ASIA is distinct from KR; matchup winrates are not provided.

Instructions

Compare hero aggregate percentages, maps, tiers or source regions; history uses stored retrieval snapshots. ASIA is not KR. No matchup winrates.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
mapNoall-maps
mapsNo
modeNocompetitive
roleNo
tierNo
viewNoheroes
afterNo
limitNo
tiersNo
heroesNo
regionNoASIA
sourceNoauto
regionsNo
order_byNowinrate:desc
platformNopc
allow_region_fallbackNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. First observedv0.1.0

TDQS

B3.2/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and idempotentHint=true, so the description does not need to restate those. It adds valuable context: history uses stored snapshots (implying potentially cached data), ASIA region is not KR (data grouping nuance), and no matchup winrates (scope exclusion). These go beyond the annotations and help the agent understand tool behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise: two sentences plus a brief note. It front-loads the primary purpose and then adds three clarifying qualifiers. There is no fluff or redundant language, and every clause delivers information that is not obvious from the schema or annotations.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With 16 parameters, zero schema descriptions, and an output schema, the description is far too sparse. It does not explain how parameters interact, what the viewing modes (heroes, map_comparison, tier_comparison, region_comparison, history) are, how filtering works, or what the response structure looks like. The agent would struggle to construct a correct request without external knowledge.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must explain parameters. It does not. It mentions maps, tiers, and source regions generically but does not clarify any of the 16 parameters, such as `allow_region_fallback`, `order_by`, `source`, or `view`. Without parameter meaning, the agent can only guess based on names, which is insufficient for a tool this parameter-rich.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states the tool compares hero aggregate percentages, maps, tiers, or source regions, which is a clear verb+resource. It also clarifies what it does not do (no matchup winrates) and a data nuance (ASIA is not KR). However, it does not explicitly distinguish it from sibling tools like ow_status or ow_catalog, so clarity is strong but not fully differentiated.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives no guidance on when to use this tool versus siblings. It mentions 'history uses stored retrieval snapshots' which hints at a usage nuance but does not specify conditions or alternatives. There are no when-to-use or when-not-to-use instructions, leaving the agent to infer from context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.