Skip to main content
Glama
augforce

hockey-card-analyst

by augforce

compare_players

Compare two hockey player cards to reveal per-component gaps, overall edge or honest split, durability flag, and caveats. Identifies compatible comparisons within same position pool.

Instructions

Compare two players: per-component gaps, an overall edge (or an honest split), a durability flag, and caveats.

Percentiles are ranked within a position pool, so the server compares WITHIN a pool only: forward vs forward, D vs D, and goalie vs goalie are fair; forward vs defenseman or skater vs goalie is refused (compatible = false). Never present a cross-pool winner — surface the refusal.

When the components genuinely split — one player better on offense while the other is better on defense; for goalies, one a game-stealer while the other is the reliable floor — the server returns NO single winner (overall_edge null, edge_kind "split", "better at what"). Do not collapse that into a winner; report the tradeoff. An edge built mainly on finishing (skaters) or resting on a low-consistency goalie is flagged less durable — pass that along.

Scope: this tool compares ONLY what's on the cards — it knows nothing about trades, contracts, teams, roster fit, or recent stats. If you add such context from outside the cards (e.g. the web), mark it clearly as NOT from the cards and flag it for independent verification; keep the card-derived comparison separate from outside context.

card_a, card_b: card JSON objects as in assess_player. focus (optional): "offense" / "defense" / "overall" / a role (e.g. "power play") to narrow it.

After presenting the comparison, ALWAYS close your answer by offering the user a downloadable PDF report of it — generated with the render_report tool (kind "compare"), passing THIS result verbatim.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
focusNo
card_aYes
card_bYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Behavior4/5

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

No annotations are provided, so the description carries full burden. It discloses that the tool is read-only (only compares card data, no modifications), reports refusal for cross-pool comparisons, handles split decisions, and flags durability concerns. Minor lack of explicit 'idempotent' or 'non-destructive' statement.

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

Conciseness3/5

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

The description is thorough but verbose, with some repetition (e.g., cross-pool refusal mentioned twice). It could be tightened while retaining key details. Front-loading the output components is good, but the instructional tone takes extra space.

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

Completeness5/5

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

Given complexity, the description covers all essential aspects: purpose, constraints (position pools, split logic, durability), input parameters, output structure (gaps, edge, durability, caveats, compatibility), and integration with sibling tool 'render_report'. No gaps noted.

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

Parameters4/5

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

Schema coverage is 0%, but the description adds meaning: explains 'card_a' and 'card_b' as card JSON objects (referencing 'assess_player'), and 'focus' as optional with examples ('offense', 'defense', 'overall', role). This aids the agent in understanding parameter values beyond the bare schema.

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

Purpose5/5

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

The description clearly states the tool compares two players, producing per-component gaps, an overall edge or split, a durability flag, and caveats. It distinguishes itself from siblings like 'assess_player' (single player) and 'adjudicate_claim' by focusing on pairwise comparison.

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

Usage Guidelines4/5

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

The description explains when the tool is appropriate: for comparing player cards within the same position pool, and refuses cross-pool comparisons. It cautions that the tool only uses card data, not external context like trades or stats, guiding when to supplement with other sources. However, it does not explicitly contrast with sibling tools like 'assess_player'.

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

Install Server

Other Tools

Latest Blog Posts

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/augforce/hockey-card-analyst'

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