Skip to main content
Glama

Session breakdown

session_detail
Read-onlyIdempotent

Break down one range session: Swing Score, its areas and skill scores when the app synced them, plus the median of each swing measurement (tempo, backswing/downswing time, hip turn, posture; shoulder turn, X-Factor and hand speed with Apple Watch; head stability with AirPods). For a focus session, how many focus swings landed in the zone vs before; What your swing shows (patterns) when the app synced them. Newer sessions report On target and every stat as "k of n in range" (Work on, Good, Watch) instead of a Swing Score; On target is relative to the golfer's own normal, never a comparison with anyone else. Defaults to the latest session. Only interpret what is returned; PocketCaddie does not measure ball flight, carry or club head speed.

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": "session_detail"
  }
}

Input Schema

NameRequiredDescriptionDefault
session_idNoFrom recent_sessions. Omit for the latest.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.1/5.0
Behavior4/5

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

Annotations already cover the read-only/idempotent/non-destructive profile, but the description adds real value: it explains that newer sessions return 'k of n in range' instead of a Swing Score, that On target is relative to the golfer's own baseline, and that ball flight/carry/club head speed are not measured. The only gap is nothing about behavior for an invalid or unknown session_id.

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 purpose is front-loaded and there is little filler; every clause carries information about outputs or interpretation limits. However, the dense semicolon-chained measurement list is hard to parse in one pass.

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?

With no output schema, the description carries the burden of explaining return values, and it does so thoroughly, including the older-vs-newer reporting format split and the interpretation caveat. Nothing critical is missing for correct invocation.

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 description coverage is 100% and the single parameter is already documented as coming from recent_sessions with 'omit for the latest'. The description's 'Defaults to the latest session' merely restates this, adding no new syntax or format detail.

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?

Opens with a specific verb and resource ('Break down one range session') and then enumerates exactly what is returned: Swing Score, area/skill scores, medians of swing measurements, and focus-session zone counts. This is clearly distinguishable from the list-oriented sibling recent_sessions and from progress.

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?

'Defaults to the latest session' gives clear operational context, and the schema ties the optional id back to recent_sessions. It does not explicitly say when to prefer this over recent_sessions or progress, so it falls short of full routing guidance.

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.

Resources