Skip to main content
Glama

GolfCore

by org.golfcore
OverviewDiscussionsAdmin

Ask the GolfCore caddie

ask_caddie

Ask GolfCore's caddie a question about the shot the golfer is standing over, such as which club to hit or where to aim. Pass the question in their words, and lat and lng only if your device gives you their GPS position; otherwise GolfCore uses the position from the GolfCore app on their phone. The caddie reads the distance to the flag, the hazards and trees on the line, wind modeled for the terrain, the elevation change, and the golfer's own handicap and club distances from their GolfCore account, and answers with a club and a line; the golfer signs in to GolfCore the first time. It needs GolfCore Premium; without it the result lists the plans, and subscribe_premium starts one.

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.
questionYesThe golfer's question, in their words.
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."
    • changedInput schema / required
      Previous value: -[
-  "lat",
-  "lng",
-  "question"
-]New value: +[
+  "question"
+]
  2. Added

TDQS

A4.3/5.0
Behavior4/5

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

Goes well beyond annotations by enumerating the data the caddie consumes (flag distance, hazards, wind modeled for terrain, elevation, handicap, club distances) and the output shape (a club and a line). It also discloses the first-time sign-in requirement and the Premium gating with its fallback, though it says nothing about latency or failure modes. No contradiction with the annotations.

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 purpose and examples, then the required data, then the constraint. It is long but dense with useful detail; the lat/lng instruction duplicates schema text only slightly.

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 6-param tool with no output schema, the description covers inputs, data sources, result shape, auth requirement, and the Premium fallback path. An agent can invoke it correctly without guessing, though error/edge behavior is left implicit.

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%, so the schema already documents all six parameters including the lat/lng GPS caveat and the hole/course fallbacks. The description reinforces the lat/lng rule but adds no new syntax or semantics beyond the schema text, which is the expected baseline.

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 action (ask the caddie a question about the shot the golfer is standing over) with concrete examples of the question type (which club, where to aim). Clearly distinct from siblings like distance_to_flag (raw measurement) and subscribe_premium (plan purchase).

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?

Explicitly tells the agent when to pass lat/lng and when to omit them, and forbids asking the golfer for coordinates. It also routes around the Premium gate by naming subscribe_premium as the alternative when the result lists plans.

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