Skip to main content
Glama

Get player insights

get_player_insights
Read-onlyIdempotent

Comparativa del jugador FRENTE A JUGADORES DE SU HÁNDICAP en 8 categorías (resultado sobre par, calles, approach, greens en regulación, pares o mejor, scrambling, putts y penalizaciones) y sus cruces (par o mejor con green cogido o sin cogerlo; % de 1, 2 y 3 putts), calculada en código sobre sus últimas 20 tarjetas (Badgie terminadas + oficiales RFEG con capa PRO): su valor, la referencia de su franja, la diferencia, la muestra de hoyos, las 2 mayores fugas en golpes por vuelta y vs_level: juego largo y putt frente a un jugador de su hándicap exacto, medidos en su tarjeta. ÚSALA para '¿dónde pierdo golpes?', '¿en qué fallo?', '¿qué entreno?', '¿cómo estoy para mi hándicap?', '¿qué me separa de bajar?'. Cita las cifras tal cual con su muestra («en 41 hoyos con dato»), nunca las recalcules ni las mezcles con otras tools; cada categoría se mide SOLO sobre los hoyos que tienen ese dato. Tras nombrar la mayor fuga, enlázala con un ejercicio: llama a get_drills con el drill_category de esa fuga. Sin hándicap (handicap.index null) no hay referencias: da sus valores y ofrécete a enlazar su licencia. Si low_sample es true, dilo y no lo presentes como una fuga firme.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "get_player_insights"
  }
}

Input Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.2/5.0
Behavior5/5

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

Annotations already declare readOnly/idempotent/non-destructive, and the description still adds substantial behavior: figures are computed in code over a 20-card window, each category is measured only on holes that have that datum, samples must be quoted verbatim with their hole count and never recalculated or merged with other tools, and the null-handicap and low_sample degradations are spelled out. It also states that vs_level is measured on the player's own card against an exact-handicap peer. This is well beyond what the annotations convey.

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?

Content is largely load-bearing, but it is delivered as one enormous opening sentence with nested parentheses and comma-spliced clauses, making it hard to parse. The output-field inventory (value, band reference, difference, hole sample, two biggest leaks, vs_level) is packed into that same sentence rather than separated from the usage instructions. Front-loading is present but the structural clarity is poor.

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?

With no parameters, no output schema, and minimal annotation burden, the description still covers what is returned (8 categories plus cross-tabs, vs_level, low_sample), how the sample is derived, and the two failure modes. An agent can call this correctly and knows the follow-up chain into get_drills using the leak's drill_category.

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

Parameters4/5

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

The tool takes zero parameters, so the baseline of 4 applies; there is nothing for the description to disambiguate at call time. The description instead spends its detail on what the call returns, which is the right allocation for a no-arg tool.

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?

States a specific verb+resource: a comparison of the player against players of their exact handicap across 8 named categories (result vs par, fairways, approach, GIR, pars or better, scrambling, putts, penalties) plus cross-tabs, computed over the last 20 scorecards. The scope (Badgie + RFEG official with PRO layer, last 20 cards) is unusually precise. It stops short of naming a sibling to prefer, so an agent must still infer how this differs from get_round_insights or get_strokes_gained_by_area.

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?

Gives explicit trigger questions ('¿dónde pierdo golpes?', '¿qué entreno?', '¿cómo estoy para mi hándicap?') which map cleanly onto agent intents, plus two edge-case branches: no handicap means no references (offer to link license), and low_sample=true means present it as provisional. No when-not-to-use or sibling alternative is named, so the boundary with other stats tools is left implicit.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.