Skip to main content
Glama

GolfCore

by org.golfcore
OverviewDiscussionsAdmin

Distance to the flag

distance_to_flag
Read-onlyIdempotent

How far the golfer is from the flag, from where they are standing: 'how far is that flag', 'what's the yardage'. Returns the course, the hole, its par and stroke index, and yards to the flag (today's pin as the club set it) and to the middle of the green. Pass lat and lng only if your device gives you the golfer's GPS position; otherwise call it with no arguments, and GolfCore reads the golfer's position from the GolfCore app on their phone. It is part of GolfCore Premium: the golfer signs in to GolfCore the first time, and without Premium the result lists the plans for subscribe_premium. position_age_s says how old that position is. When hole_inferred is true the hole was chosen from the position, so say which hole you assumed.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
latNoOptional. The golfer's precise latitude, only when your device gives you their GPS position. Never ask the golfer for coordinates: leave lat and lng out and GolfCore uses the position from the GolfCore app on their phone.
lngNoOptional. The golfer's precise longitude, with lat.
holeNoOptional. The hole number the golfer says they are on. Otherwise the hole is chosen from the position.
courseNoOptional. The course slug, when known. Otherwise the course is found from the position.
accuracy_mNoOptional. The location's horizontal accuracy in meters, when the device reports it.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • changedInput schema / properties / lat / description
      Previous value: -"The golfer's latitude, from their phone or glasses."New value: +"Optional. The golfer's precise latitude, only when your device gives you their GPS position. Never ask the golfer for coordinates: leave lat and lng out and GolfCore uses the position from the GolfCore app on their phone."
    • changedInput schema / properties / lng / description
      Previous value: -"The golfer's longitude."New value: +"Optional. The golfer's precise longitude, with lat."
    • removedInput schema / required
      Removed value: -[
-  "lat",
-  "lng"
-]
  2. Added

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already cover the safe-read profile (readOnly, idempotent, non-open-world), but the description adds real behavioral context beyond them: the GolfCore app supplies the position when no args are given, position_age_s reports staleness, hole_inferred signals positional inference, and Premium/sign-in is required. It stops short of describing failure modes or caching beyond staleness.

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 and trigger phrases are front-loaded and no sentence is filler, but the description is a dense run-on block mixing return values, argument policy, auth, and inference semantics in one paragraph, making it harder to scan than it needs to be.

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, and the description compensates by enumerating the returned fields; it also covers the auth/Premium prerequisite and the positional-inference caveat, leaving nothing essential for a correct call unstated.

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 each parameter already documents its fallback behavior, so baseline is 3. The description restates the lat/lng policy and the inferred hole/course logic but adds no syntax or format detail the schema lacks; the genuinely new information (position_age_s, Premium gating) concerns behavior rather than parameters.

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?

States a specific verb+resource (how far the golfer is from the flag) and the user phrasings that trigger it, plus what is returned (course, hole, par, stroke index, yards to pin and green). An agent can separate this from ask_caddie and search 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?

Explicit when-to-use ('how far is that flag'), explicit argument policy (pass lat/lng only if the device provides GPS, otherwise call with no arguments), and names the alternative path: without Premium the result lists plans for subscribe_premium.

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

All GolfCore 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