Skip to main content
Glama

Get hole plan

get_hole_plan
Read-onlyIdempotent

Plan de UN hoyo para estudiarlo ANTES de salir: palo de salida y desvío de apunte (aim_offset_m, + derecha), zona de caída con sus distancias (vuelo, total, p25–p80) y su dispersión lateral, obstáculos (agua, búnker, árboles) con si están en juego y el vuelo para pasarlos, lo que queda al green, tamaño del green y por dónde fallarlo, y trouble_index para elegir los hoyos clave. Las cifras vienen calculadas en metros: nárralas tal cual, sin recalcular ni añadir consejo; notes son hechos que tienes que respetar. distances_source dice de dónde salen: bag (su bolsa medida, distancia total GPS), declared (las que dijo; el resto de palos, estimados) o handicap_prior (estadística de su hándicap; si te dice cuánto vuela su driver, vuelve a llamar con driver_carry_m). approach.club solo viene si ese palo es suyo (medido o dicho): sin él, di la distancia y no nombres palo. Nunca en plena vuelta: con una vuelta en curso responde round_in_progress (Regla 4.3a). Con gender_required pregunta si necesita valoración masculina o femenina; con layout_required o tee_required pregúntale el recorrido o la barra (vienen las opciones) y vuelve a llamar. Con suspicious_orthophoto o no_geometry no hay plan fiable de ese hoyo: dilo, no lo inventes. hole.strokes_received son los golpes que recibe en ese hoyo desde esa barra, con el 100 % de su hándicap de campo (negativo: un jugador plus los da), y su par neto es el par más esos golpes. approach.distance_m se mide en línea recta desde approach.from_m, donde queda su salida con la rodada, no desde el tee. El campo entero hoyo a hoyo es get_course_plan.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "course_id": "<course_id>",
      "hole": "<hole>"
    },
    "name": "get_hole_plan"
  }
}

Input Schema

NameRequiredDescriptionDefault
holeYesNúmero de hoyo.
genderNoValoración masculina/femenina si gender_required; por defecto el perfil del jugador.
layoutNoRecorrido como lo diga el jugador («Arriba», «Sur»); hace falta si el campo tiene varios.
handicapNoHándicap a usar; por defecto el suyo.
course_idYesid del campo (de get_course_info).
tee_colorNoColor de la barra; por defecto la suya habitual.
club_carries_mNoLo que vuela cada palo según él, en metros.
driver_carry_mNoLo que vuela su driver según él, en metros.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • addedInput schema / properties / club_carries_m / items / properties / carry_m / description
      Added value: +"That club's carry in metres, 10-350."
    • addedInput schema / properties / club_carries_m / items / properties / club / description
      Added value: +"Club type: driver, 3-wood, 5-wood, 7-wood, hybrid, 2-iron to 9-iron, pw, gw, sw, lw (and putter where listed)."
  2. First observed

TDQS

A4.8/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 adds substantial behavior beyond them: figures are pre-computed in metres and must be narrated as-is without recalculation, notes are facts to respect, distances_source semantics (bag/declared/handicap_prior), approach.club only present when the club is the player's, and the measurement origin of approach.distance_m. This is rich operational context an agent needs to use results correctly.

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

Conciseness4/5

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

Front-loaded with the return payload, then behavioral rules, then error branches, then the sibling pointer — a logical order. It is dense and delivered as one long block, so a few sentences (e.g. the strokes_received/par neto explanation) could be tightened, but nearly every sentence carries actionable information.

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?

There is no output schema, so the description carries the full burden of explaining return values, and it does so thoroughly: every field group, the distances_source provenance, the approach.from_m measurement origin, and the strokes_received sign convention. Combined with the error-state handling, an agent has everything needed to call and interpret the tool.

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 100%, so the baseline is 3, but the description adds conditional meaning the schema lacks: driver_carry_m should be supplied when the player states driver carry (triggering a re-call), gender/layout/tee_color are prompted only when the corresponding *_required signal fires, and handicap defaults to the player's own. It stops short of explaining club_carries_m structure, but the schema covers that.

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?

States a specific verb+resource (plan for a single hole) and enumerates the exact payload: tee club, aim_offset_m, landing zone with carry/total/p25–p80, lateral dispersion, obstacles, remaining to green, green size, trouble_index. It explicitly distinguishes itself from the sibling get_course_plan (whole course hole by hole), so an agent can route without opening either schema.

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

Usage Guidelines5/5

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

Gives explicit when-to-use (study a hole BEFORE going out), when-not (never mid-round; returns round_in_progress per Rule 4.3a), and the alternative (get_course_plan for the full course). It also routes the agent on conditional branches: gender_required, layout_required, tee_required, suspicious_orthophoto, no_geometry, and re-calling with driver_carry_m.

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.