Skip to main content
Glama
Sign In

Morris Golf

by golf.morris
OverviewDiscussionsAdmin

Get course plan

get_course_plan
Read-onlyIdempotent

Plan de ataque de un campo hoyo a hoyo con las distancias REALES del jugador: obstáculos en juego y cuáles alcanza, dónde cae cada palo, palo de salida recomendado, green (delante/centro/fondo) y su propio historial en cada hoyo. Un hoyo sin geometría sale degraded=true (solo tarjeta): dilo, no inventes. Con layout_required el campo tiene varios recorridos y la barra no dice cuál: pregúntaselo (vienen las opciones) y vuelve a llamar con layout. text es el resumen listo para narrar. strokes_received y net_par usan el 100 % de su hándicap de campo desde esa barra, sin allowance de competición. media indica mapas y enlaces 3D realmente disponibles; app_links lleva al campo y a las tiendas. Un enlace 3D es un visor, no una imagen. Nunca durante una vuelta en curso: round_in_progress.

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>"
    },
    "name": "get_course_plan"
  }
}

Input Schema

NameRequiredDescriptionDefault
holesNoSolo estos hoyos; por defecto todos.
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.
handicapNoÍndice de hándicap; por defecto el suyo. Golpes al 100 % del hándicap de campo, no incluye allowance de competición.
course_idYesid del campo (de get_course_info).
tee_colorNoColor de la barra; por defecto la suya habitual.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.1/5.0
Behavior5/5

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

Annotations only declare read-only/idempotent/local; the description adds real behavioral context: degraded=true for holes without geometry (only the card, do not invent), layout_required meaning multiple routings exist and the bar does not disambiguate, handicap math at 100% of course handicap with no competition allowance, and that media/app_links report actual availability with 3D links being a viewer rather than an image.

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-loads the core output in the first sentence and then attaches short caveats, each of which carries distinct operational value (degraded, layout_required, handicap math, media/app_links, round_in_progress). It is dense rather than bloated, though the media/app_links sentence sits late and reads as an afterthought.

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

Completeness4/5

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

For a six-parameter read tool with no output schema, it covers the failure modes an agent would otherwise get wrong: degraded holes, ambiguous layouts, handicap allowance, and in-round usage. Minor gaps remain around how hole subsets and gender/tee fallbacks behave, but nothing essential to a correct call is missing.

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

Parameters3/5

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

Schema coverage is 100%, so baseline applies; the description reinforces the handicap semantics (100% of course handicap, no allowance) and the layout round-trip but adds little for holes, gender, or tee_color beyond what the schema already states.

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?

Opens with a specific verb+resource: hole-by-hole attack plan using the player's REAL distances, listing exactly what is produced (obstacles in play, club landing spots, recommended tee club, green front/center/back, own history). It never names the closely related siblings (get_hole_plan, get_course_intel, get_green_reads), so the boundary with those tools has to be inferred.

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 an explicit exclusion ("Nunca durante una vuelta en curso: round_in_progress") and a concrete re-call procedure when layout_required appears in the response. It stops short of naming alternative tools for those situations, so the agent knows when not to call but not what to call instead.

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

All Morris Golf toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources