Morris Golf

Get round history

get_round_history

Read-onlyIdempotent

Todas las vueltas del jugador, vengan de donde vengan, la más reciente primero, cada una con su origen (origin): app (apuntada en Morris Golf), scan (tarjeta de papel escaneada), garmin (de su reloj, con shots_complete), nextcaddy, rfeg (vuelta oficial de la federación, con differential) y trackman (vuelta de simulador, sin tarjeta guardada: gross y to_par vienen vacíos). to_par solo sale cuando todos los hoyos tienen golpes: con una raya viene null. counts dice cuántas vueltas hay de cada origen. Úsala para ver su historial, comparar fuentes o decir de dónde viene una vuelta; di siempre el origen. Una vuelta de la app y la oficial del mismo día salen las dos. Garmin no marca putts. Las sesiones de práctica de TrackMan no son vueltas: están en list_trackman_sessions. Para buscar la vuelta que va a corregir, cerrar o rescatar usa list_rounds.

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

Input Schema

Name	Required	Description
`limit`	No	How many rounds, 1-200, newest first.
`since`	No	Solo vueltas desde este día (YYYY-MM-DD).
`origins`	No	Only these origins: app, scan, garmin, nextcaddy, rfeg (official) or trackman (simulator).
`with_cards`	No	Añade cards: los golpes y el par hoyo a hoyo de cada vuelta. Solo cuando vayas a comparar hoyos entre vueltas.

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedNov 6, 2026

addedInput schema / properties / limit / description

Added value: +"How many rounds, 1-200, newest first."

addedInput schema / properties / origins / description

Added value: +"Only these origins: app, scan, garmin, nextcaddy, rfeg (official) or trackman (simulator)."

First observedNov 6, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations only cover the safe-read profile; the description adds real behavioral context: result ordering, per-origin field availability (garmin carries shots_complete, rfeg carries differential, trackman returns empty gross and to_par with no stored card), the rule that to_par is null when any hole lacks strokes, the presence of a counts breakdown, that Garmin does not record putts, and that an app round and the official round on the same day are both returned rather than merged.

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 core statement and every clause carries information (ordering, origin meanings, nullability, exclusions). It is, however, one dense run-on paragraph where bullets or sentence breaks would make the origin taxonomy and the two exclusions easier to scan.

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 must carry return-value semantics, and it does: origin, counts, to_par nullability, and empty gross/to_par for trackman rounds. Combined with the routing notes, nothing an agent needs to call this correctly and interpret the result is missing.

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 3 is the floor, and the description exceeds it by explaining what each origin value actually means in the returned data (app vs scan vs garmin vs rfeg vs trackman), which the enum gloss only sketches. It does not discuss limit or since, leaving those entirely to the 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 opening clause states a specific verb and resource plus a scope qualifier: all of the player's rounds 'vengan de donde vengan', newest first. It immediately distinguishes itself from list_rounds (used to find a round to correct/close/rescue) and from list_trackman_sessions (practice sessions are not rounds), so an agent can route without opening any 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?

Explicit when-to-use ('para ver su historial, comparar fuentes o decir de dónde viene una vuelta'), explicit when-not (TrackMan practice sessions belong to list_trackman_sessions; correcting/closing/rescuing a round belongs to list_rounds), plus an instruction to always state the origin. Both the alternative and the selecting condition are named.

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.