Skip to main content
Glama
Sign In

Morris Golf

by golf.morris
OverviewDiscussionsAdmin

Get trackman range

get_trackman_range
Read-onlyIdempotent

Read the player's sessions from their own TrackMan account (the native connection): latest sessions with a per-club history, a per-club analysis, or every shot. Use it for range or simulator questions about TrackMan; sessions kept in Badgie instead (TrackMan report links, launch monitor CSVs such as Garmin R10 or Rapsodo) are read with list_trackman_sessions. In view summary, badgie_sessions counts those too: if it is above 0, never say there are no sessions. Figures are computed in code; demo true means sample data. Read-only: it does not sync.

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

Input Schema

NameRequiredDescriptionDefault
viewNosummary (default): latest sessions (date, range or simulator, balls, clubs) and the last year per club. analysis: dispersion, gapping, trends, ball and club speed, smash and worst shots per club. shots: every shot, paged with offset.
limitNoHow many recent sessions to read, 1-5. Default 3.
offsetNoWith view shots, the first shot to return: pass next_offset from the previous page. Default 0.
accountNoprincipal (default): the player's TrackMan connection. vinculada: the connection of their older linked account on another channel. Check both before saying there is no data, and never add their figures: they may overlap.
activityIdNoOne TrackMan session id from a previous answer, to read only that session.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed5 schema fields changed
    • addedInput schema / properties / account / description
      Added value: +"principal (default): the player's TrackMan connection. vinculada: the connection of their older linked account on another channel. Check both before saying there is no data, and never add their figures: they may overlap."
    • addedInput schema / properties / activityId / description
      Added value: +"One TrackMan session id from a previous answer, to read only that session."
    • addedInput schema / properties / limit / description
      Added value: +"How many recent sessions to read, 1-5. Default 3."
    • addedInput schema / properties / offset / description
      Added value: +"With view shots, the first shot to return: pass next_offset from the previous page. Default 0."
    • addedInput schema / properties / view / description
      Added value: +"summary (default): latest sessions (date, range or simulator, balls, clubs) and the last year per club. analysis: dispersion, gapping, trends, ball and club speed, smash and worst shots per club. shots: every shot, paged with offset."
  2. First observed

TDQS

A4.5/5.0
Behavior5/5

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

Annotations already declare readOnly/idempotent/non-destructive, so the description correctly spends its words on traits annotations cannot express: "Read-only: it does not sync", "Figures are computed in code; demo true means sample data", and the warning that the two account channels may overlap and must not be summed. These are genuine operational caveats that prevent wrong answers.

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?

Purpose is front-loaded in the first sentence, and the sibling disambiguation and the badgie_sessions guard follow in logical order. It is dense with parentheticals ("the native connection", "TrackMan report links, launch monitor CSVs such as Garmin R10 or Rapsodo") which cost some readability but each carries real disambiguating information.

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 five-parameter read tool with no output schema, the description covers purpose, routing, the two account channels, the summary counter caveat, the demo flag, and shot pagination via next_offset. The only real gap is that the returned field shapes for the analysis and shots views are left entirely to the schema, which is acceptable but slightly thin for a tool with no declared output schema.

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% and the enum values for view and account are already fully described in the schema, including the "check both before saying there is no data" caveat. The description repeats rather than extends that guidance, adding only the cross-reference to badgie_sessions, so the baseline 3 for a schema-complete tool applies.

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?

"Read the player's sessions from their own TrackMan account (the native connection)" states a specific verb and resource, then enumerates the three output shapes (latest sessions with per-club history, per-club analysis, every shot). It explicitly contrasts with list_trackman_sessions for Badgie-stored sessions, so an agent can discriminate this tool from its nearest sibling without opening a 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?

It states the positive case ("range or simulator questions about TrackMan"), the negative case with the named alternative ("sessions kept in Badgie instead ... are read with list_trackman_sessions"), and even a decision rule for the result ("if badgie_sessions is above 0, never say there are no sessions"). When/when-not/alternative are all covered.

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