Morris Golf

Get swing practice

get_swing_practice

Read-onlyIdempotent

Elige UN ejercicio y UNA sensación distintos de los anteriores para la prioridad de swing vigente. Úsala antes de recetar otro ejercicio o ante «no me funciona/no lo entiendo». Sin fault usa la última prioridad diagnosticada; no cambies de prioridad solo por variar. Devuelve repeticiones propuestas, material, lugar, señal y fuentes públicas. hook, toe_contact y low_iron_flight son objetivos declarados por el jugador o medidos, nunca diagnósticos deducidos de una foto. No equipares slice con over_the_top sin evidencia del camino. Nunca lo uses para inventar un diagnóstico. history es memoria técnica de Morris; no se muestra al jugador.

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_swing_practice"
  }
}

Input Schema

Name	Required	Description
`fault`	No	The swing priority to work on, as a fault code. Leave it out to use the latest diagnosed priority; hook, toe_contact and low_iron_flight only when the player said so or it was measured.
`history`	No	Drills and feels Morris already gave for this priority, so the new one differs. Leave it out if you have none.
`feedback`	No	What the player said about the last drill: «it does not work», «I do not get it».
`location`	No	Where they will practise: home, range or course.
`equipment`	No	What they have at hand (alignment sticks, a towel, a net…), so the drill fits it.

Schema Changelog

Changes observed during successful MCP inspections.

Changed11 schema fields changedNov 6, 2026

addedInput schema / properties / equipment / description

Added value: +"What they have at hand (alignment sticks, a towel, a net…), so the drill fits it."

addedInput schema / properties / fault / description

Added value: +"The swing priority to work on, as a fault code. Leave it out to use the latest diagnosed priority; hook, toe_contact and low_iron_flight only when the player said so or it was measured."

addedInput schema / properties / feedback / description

Added value: +"What the player said about the last drill: «it does not work», «I do not get it»."

addedInput schema / properties / history / description

Added value: +"Drills and feels Morris already gave for this priority, so the new one differs. Leave it out if you have none."

addedInput schema / properties / history / items / properties / approach / description

Added value: +"The cue type used: internal, external, constraint, rhythm or sport."

addedInput schema / properties / history / items / properties / at / description
```
Added value: +"When it was given, ISO 8601 date-time."
```
addedInput schema / properties / history / items / properties / drillId / description
```
Added value: +"The drill's id from an earlier answer."
```
addedInput schema / properties / history / items / properties / fault / description
```
Added value: +"The fault that drill was for."
```
addedInput schema / properties / history / items / properties / feelId / description
```
Added value: +"The feel's id from an earlier answer."
```
addedInput schema / properties / history / items / properties / wording / description
```
Added value: +"Index of the cue wording that was used, 0-10."
```

addedInput schema / properties / location / description

Added value: +"Where they will practise: home, range or course."

First observedNov 6, 2026

TDQS

A4.5/5.0

Behavior5/5

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

Annotations already declare this is a safe, idempotent read, and the description goes well beyond them: it previews the output contents (reps, material, location, cue, public sources), states domain validity constraints (hook/toe_contact/low_iron_flight must be player-declared or measured, never inferred from a photo; don't equate slice with over_the_top without path evidence), and discloses that the `history` array is internal technical memory not shown to the player.

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?

The selection rule and its trigger are front-loaded, and almost every clause carries a distinct constraint. It is dense to the point of being a run-on, packing output description, fault-evidence rules and a privacy note into one paragraph, which slightly hurts scannability.

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 5 optional parameters, no output schema and no required fields, the description still tells the agent what the returned practice contains and where the drill/fault data may come from. Nothing needed to call it correctly is missing, and the language switch to Spanish matches a Spanish-speaking coaching context.

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 baseline is 3, but the description adds real meaning on top: what omitting `fault` does, the evidence required for the three subjective fault codes, and the privacy framing of `history`. `feedback` and `location`/`equipment` are left to the schema, which already documents them well.

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 opening sentence names a concrete verb and resource: pick ONE drill and ONE feel, distinct from previous ones, for the current swing priority. That is far more specific than the generic drill-listing siblings (get_drills, get_drill_digest), but no sibling is named, so an agent must infer the boundary from the tool name alone.

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?

Explicit triggering conditions are given: use it before prescribing another drill, or when the player says «no me funciona/no lo entiendo». Omission behaviour is spelled out (without `fault`, the last diagnosed priority is used) along with an exclusion — don't change priority just for variety — and a hard when-not: never use it to invent a diagnosis.

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

All Morris Golf tools Inspect

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.