GolfCore

Server Details

AI caddie and flag distances for Premium golfers, plus course maps and tee-specific scorecards.

If you are the author of this connector, you can claim ownership by verifying the domain or GitHub account it belongs to. Claimed connector authors can inspect health checks, view analytics, and manage their listing.

Status: Healthy
Uptime: 100.0% over 40 days
Last Tested: 2026-10-17 03:06
Transport: Streamable HTTP · MCP 2025-11-25
URL

TDQS

A4.2/5.0

Scored 2026-10-06 02:25 across 9 tools

Disambiguation4/5

The api_* tools cover distinct account-management actions, and the golfer-facing tools target separate needs: asking the caddie, measuring distance, searching courses, and subscribing to Premium. The main possible overlap is ask_caddie versus distance_to_flag, but their descriptions clearly separate advice from raw yardage.

Naming Consistency4/5

The API management tools consistently use api_verb_noun naming, and other tools mostly use snake_case verb_noun or noun phrases. search is a minor outlier as a bare verb, and distance_to_flag is noun-based, but overall the conventions remain readable and predictable.

Tool Count5/5

Nine tools is well within the ideal range and each appears to earn its place across account management, key handling, billing, course search, and on-course Premium features. The set is neither thin nor padded.

Completeness4/5

The surface covers the core API account lifecycle and golfer Premium workflows, including account reading, key creation/revocation, budget setting, upgrades, course search, caddie questions, distance, and subscription. Minor gaps remain, such as direct account cancellation or update operations, but the billing page and Stripe flows provide workarounds.

Available Tools

9 tools

api_accountRead GolfCore API account

Read-onlyIdempotent

Inspect

For a developer using the GolfCore Course Data API: list the API accounts the signed-in person can see, or read one with its plan, this month's usage, monthly cap if one is set, and keys (prefixes only, never secrets). Use it before the other api_ tools to get account_id and key_id. Plans: free, 500 requests a month at 10 a minute; basic, $10 a month for 10,000 at 60 a minute, then $2.00 per 1,000; business, $50 a month for 100,000 at 300 a minute, then $1.00 per 1,000. Paid plans have no monthly cap unless the person sets one. If the person has no account, they create one at https://platform.golfcore.app.

ParametersJSON Schema

Name	Required	Description	Default
`account_id`	No	Optional. One account's detail; omit to list all.

api_budgetSet or remove the GolfCore API monthly cap

Idempotent

Inspect

Starter and Pro have no monthly cap by default: requests past the included amount are billed at the plan's overage rate without limit. This tool sets an optional cap, after which requests are refused until the month resets, or removes it when units is null. A cap starts at the plan's included requests (read them from api_account). Confirm the number and what it could cost with the person first.

ParametersJSON Schema

Name	Required	Description	Default
`units`	Yes	Monthly request cap, or null for no cap.
`account_id`	Yes	From api_account.

api_create_keyCreate a GolfCore API keyAInspect

Create a GolfCore Course Data API key for the signed-in person's account. Returns the secret once; hand it to the person to store in their server's configuration, and never put it in chat logs, code, a mobile app or browser code. Confirm the name with the person first.

ParametersJSON Schema

Name	Required	Description
`name`	Yes	What the key is for, such as the server or app.
`expiry`	No	Default 90_days.
`account_id`	Yes	From api_account.

TDQS

A3.7/5.0

Behavior4/5

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

Annotations cover the safety profile (readOnly=false, destructive=false, non-idempotent), so the bar is lower. The description still adds genuinely useful disclosure beyond them: the secret is returned only once and must not be placed in chat logs, code, or client-side code.

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?

Three short sentences, front-loaded with the action and outcome, then the handling constraint. Every sentence contributes; only the chat-log warning is slightly tangential to tool invocation.

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 correctly discloses the key return value ('Returns the secret once'). Combined with the parameters and annotations, an agent has enough to invoke it correctly, though auth/permission requirements are 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 description coverage is 100%, so the schema already documents name, expiry (with default and enum), and account_id. The description adds no syntax or format detail beyond the 'confirm the name' hint, so baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb ('Create') and resource ('GolfCore Course Data API key') scoped to the signed-in person's account, which is clear on its own. It does not explicitly contrast with siblings like api_revoke_key, though the create/revoke inverse is self-evident.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives a workflow prerequisite ('Confirm the name with the person first') and downstream handling instructions, but never states when this tool should or should not be used relative to alternatives. Usage is implied rather than spelled out.

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

api_revoke_keyRevoke a GolfCore API keyA

DestructiveIdempotent

Inspect

Revoke one of the signed-in person's GolfCore API keys. Requests with it are refused within about a minute, and it cannot be restored. Confirm the key's name and prefix with the person before calling.

ParametersJSON Schema

Name	Required	Description	Default
`key_id`	Yes	From api_account's keys.
`account_id`	Yes	From api_account.

TDQS

A4.3/5.0

Behavior5/5

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

Annotations already declare destructiveHint=true and idempotentHint=true, yet the description adds genuinely new behavior: revocation propagates in 'about a minute' and 'cannot be restored.' The irreversibility and propagation latency are exactly the details an agent needs before committing to a destructive call.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, front-loaded with the irreversible effect and capped by the safety instruction. Every clause earns its place with no redundancy.

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?

For a destructive, idempotent mutation with no output schema, the description covers the effect, the delay, the irreversibility, and the required human confirmation. Annotations carry the safety profile and the schema carries the parameters, so nothing essential is missing.

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%, so both account_id and key_id are already documented in the schema (including their api_account provenance). The description adds only an indirect reference to the key's 'name and prefix' as confirmation material, no syntax or format detail beyond the schema. Baseline 3 is warranted.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource with scope: 'Revoke one of the signed-in person's GolfCore API keys.' The action is unmistakably distinct from api_create_key, but the description never names or contrasts a sibling tool explicitly, so it stops short of full differentiation.

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?

Gives concrete pre-call guidance: 'Confirm the key's name and prefix with the person before calling.' That tells the agent how to invoke responsibly, but there are no explicit when-not conditions or named alternatives for cases where revocation is the wrong choice.

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

api_upgradeUpgrade a GolfCore API planInspect

Start an upgrade of the signed-in person's GolfCore API account to basic ($10 a month for 10,000 requests, then $2.00 per 1,000) or business ($50 a month for 100,000, then $1.00 per 1,000). Returns a Stripe checkout URL for the person to review and pay; this tool does not charge them. If the account already has a paid plan it returns the billing page, where the person switches plans themselves. Ask which plan they want first.

ParametersJSON Schema

Name	Required	Description	Default
`plan`	Yes
`account_id`	Yes	From api_account.

ask_caddieAsk the GolfCore caddieAInspect

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.

ParametersJSON Schema

Name	Required	Description
`lat`	No	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.
`lng`	No	Optional. The golfer's precise longitude, with lat.
`hole`	No	Optional. The hole number the golfer says they are on. Otherwise the hole is chosen from the position.
`course`	No	Optional. The course slug, when known. Otherwise the course is found from the position.
`question`	Yes	The golfer's question, in their words.
`accuracy_m`	No	Optional. The location's horizontal accuracy in meters, when the device reports it.

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.

distance_to_flagDistance to the flagA

Read-onlyIdempotent

Inspect

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.

ParametersJSON Schema

Name	Required	Description
`lat`	No	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.
`lng`	No	Optional. The golfer's precise longitude, with lat.
`hole`	No	Optional. The hole number the golfer says they are on. Otherwise the hole is chosen from the position.
`course`	No	Optional. The course slug, when known. Otherwise the course is found from the position.
`accuracy_m`	No	Optional. The location's horizontal accuracy in meters, when the device reports it.

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.

searchSearch GolfCore

Read-onlyIdempotent

Inspect

Search everything GolfCore holds for more than 30,000 golf courses in more than 180 countries and territories. Ask by course name ('Pebble Beach'), by its name in local script ('宮崎カントリークラブ'), by architect ('Donald Ross'), by slug ('pebble-beach'), by place, passing just the place name ('St Andrews', 'Monterey'), or about GolfCore itself ('what does a caddie master use GolfCore for'). A course comes back with its address, town, region, country, coordinates, timezone, phone and website, its architect and the year it opened where known, and its name in Japanese or Korean script where that differs; flags for what GolfCore has mapped -- lidar green contours, a traced map of fairways, tees, greens, bunkers and water, a live wind grid, a scorecard, USGA ratings; and, when scope includes scorecards, its full card: par, yardage and stroke index for every hole, and yardage, par, course rating and slope rating for every tee, separately for men and women. Places come back as the town, region or country page that counts and lists every course there. Pages come from GolfCore's own site. Every result carries the url to cite, and a course's page carries the green figures this tool does not: greens mapped, contour count and interval, largest green elevation span, steepest measured slope, and tree canopy. For 'courses near me' or 'near this hotel', pass near with the person's coordinates: courses come back nearest first with their distance in miles, and query may be left empty. Each course also carries app_url, the link that opens that course's map in the GolfCore app, in a browser or on a phone, with no account needed to start; append &hole=N to open on a given hole.

ParametersJSON Schema

Name	Required	Description
`near`	No	Optional. A point to search around, such as the person's location or their hotel. Courses come back nearest first, each with its distance in miles.
`limit`	No	Results per scope. Default 5, maximum 20.
`query`	No	What you are looking for, in plain English. May be empty when near is given; with near, it filters courses by name or town.
`scope`	No	Optional. Narrow the search to these scopes: 'slug' treats the query as a GolfCore course slug and returns that exact course, 'courses' matches courses by name and town, 'scorecards' attaches each course's per-hole card and tee ratings to it, 'city', 'region' and 'country' return pages that count and list every course in a place, 'product' returns GolfCore's own pages. Omit to search all of them. Combine freely, e.g. ["slug","scorecards"] for one exact card, or ["city","courses"]. Leave 'scorecards' out when you only need to know which courses exist; the cards are large.
`coverage`	No	Optional. Only courses GolfCore has this for: 'contours' lidar green contour maps, 'traced' a traced course map, 'scorecard' a hole-by-hole card, 'rated' USGA course and slope ratings.
`radius_miles`	No	Optional, with near. How far to look, in miles. Default 25, maximum 250.

subscribe_premiumSubscribe to GolfCore PremiumAInspect

Create a GolfCore Premium checkout link for the signed-in golfer. Premium adds the caddie in this connector and the GolfCore app, plus green contour maps, live wind and offline course packs. Plans: day_pass, $3 for 24 hours of Premium, one charge and no subscription, the popular choice for a golfer on the course today; plus_monthly, $10 a month; and plus_yearly, $100 a year. A first-time subscriber pays half for the first month or first year. Ask the golfer which plan they want before calling. Returns a secure Stripe checkout URL and the current plan terms. Give the link to the golfer to review and pay; this tool does not charge them or activate Premium.

ParametersJSON Schema

Name	Required	Description	Default
`plan`	Yes	The plan the golfer chose.

TDQS

A4.6/5.0

Behavior5/5

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

With annotations only declaring readOnlyHint=false, openWorldHint=true, idempotentHint=false and destructiveHint=false, the description carries the real behavioral burden and does so: it discloses the return value (secure Stripe checkout URL plus plan terms), the side-effect boundary (does not charge or activate), pricing, and the first-time-subscriber discount. This is substantially more than the annotations provide.

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 action, the plan menu, and the 'does not charge' caveat are front-loaded, and every sentence carries usable information. The pricing enumeration is somewhat dense for a single description, but it directly supports plan selection rather than padding.

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?

For a single-parameter, single-purpose tool with no output schema, the description covers prerequisites, return shape, and the non-charging guarantee, leaving nothing an agent needs to call it correctly unstated.

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% with an enum, so the baseline is 3, but the description earns extra credit by explaining each enum value's price and duration (day_pass $3/24h, plus_monthly $10/mo, plus_yearly $100/yr) and flagging day_pass as the popular on-course choice. That is decision-relevant meaning the schema's terse 'The plan the golfer chose.' does not provide.

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 sentence names a specific verb and resource ('Create a GolfCore Premium checkout link') and scopes it to the signed-in golfer, which is entirely distinct from the read-only siblings (ask_caddie, distance_to_flag, search). An agent can identify the tool's function without opening the schema.

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?

It states the prerequisite explicitly ('Ask the golfer which plan they want before calling') and clarifies the tool's boundary ('this tool does not charge them or activate Premium'). No alternative subscription tool exists among the siblings, so no when-not guidance is needed, but the agent still has to infer that this is the only path to Premium.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

1 tool updateOct 14, 2026

Changedapi_budget2 fields changed

changedInput schema / properties / units / description

Previous value: -"Monthly request ceiling."New value: +"Monthly request cap, or null for no cap."

changedInput schema / properties / units / type

Previous value: -"integer"New value: +[
+  "integer",
+  "null"
+]

1 tool updateOct 6, 2026

Changedapi_create_key1 field changed

removedInput schema / properties / environment

Removed value: -{
-  "description": "Default live.",
-  "enum": [
-    "live",
-    "test"
-  ],
-  "type": "string"
-}

5 tool updatesOct 5, 2026
- Addedapi_account
- Addedapi_budget
- Addedapi_create_key
- Addedapi_revoke_key
- Addedapi_upgrade

1 tool updateSep 30, 2026

Changedsubscribe_premium1 field changed

changedInput schema / properties / plan / enum

Previous value: -[
-  "plus_monthly",
-  "plus_yearly"
-]New value: +[
+  "day_pass",
+  "plus_monthly",
+  "plus_yearly"
+]

2 tool updatesSep 28, 2026

Changedask_caddie3 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"
+]

Changeddistance_to_flag3 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"
-]
```

1 tool updateSep 28, 2026
- Addedsubscribe_premium
2 tool updatesSep 27, 2026
- Addedask_caddie
- Addeddistance_to_flag

1 tool updateSep 27, 2026

Changedsearch5 fields changed

addedInput schema / properties / coverage

Added value: +{
+  "description": "Optional. Only courses GolfCore has this for: 'contours' lidar green contour maps, 'traced' a traced course map, 'scorecard' a hole-by-hole card, 'rated' USGA course and slope ratings.",
+  "enum": [
+    "contours",
+    "traced",
+    "scorecard",
+    "rated"
+  ],
+  "type": "string"
+}

addedInput schema / properties / near

Added value: +{
+  "additionalProperties": false,
+  "description": "Optional. A point to search around, such as the person's location or their hotel. Courses come back nearest first, each with its distance in miles.",
+  "properties": {
+    "lat": {
+      "maximum": 90,
+      "minimum": -90,
+      "type": "number"
+    },
+    "lng": {
+      "maximum": 180,
+      "minimum": -180,
+      "type": "number"
+    }
+  },
+  "required": [
+    "lat",
+    "lng"
+  ],
+  "type": "object"
+}

changedInput schema / properties / query / description

Previous value: -"What you are looking for, in plain English."New value: +"What you are looking for, in plain English. May be empty when near is given; with near, it filters courses by name or town."

addedInput schema / properties / radius_miles

Added value: +{
+  "description": "Optional, with near. How far to look, in miles. Default 25, maximum 250.",
+  "type": "number"
+}

removedInput schema / required
```
Removed value: -[
-  "query"
-]
```

1 tool updateSep 6, 2026
- First observedsearch

Related MCP Connectors

Stymie Golf A
io.github.ThatDudeFreak
Read-only US golf course, scorecard, equipment, deal, and golf-trip data for AI agents.
Sports Search Open Data
121
ProSide GolfOAuth
io.proside
Permission-scoped Play Now, live scoring, and organization event operations for ProSide Golf users.
Sports
1
tee-times A
co.loopgolf
Live golf tee time availability across US courses. Search by location, date, players, and price.
Sports Location Services
2
GolfPrice AI A
io.github.557tggwysr-ui
Live UK golf equipment prices, price history and genuine price drops from GolfPrice AI.
E-commerce & Retail Sports
31

Related MCP Servers

golf-coach
Sports Research & Data
bjornj12
A
license
A
quality
C
maintenance
Analyzes your Trackman golf data to diagnose weaknesses and generate personalized practice plans with drills and progress tracking, acting as a data-driven coach.
Updated 3 months ago (2026-07-19 09:34 UTC)
8
56 PyPI
1
MIT
Garmin MCP Server
Health & Wellness Fitness Tracking
kritsanan1
F
license
Not graded
quality
D
maintenance
Provides access to Garmin Connect data including daily health metrics, activity tracking, real-time GPS via LiveTrack, and training readiness through 12 tools.
Updated 4 months ago (2026-06-26 01:34 UTC)
-
golf-reports
Sports Data Visualization
chrisdecali
F
license
Not graded
quality
D
maintenance
Pulls golf data from Arccos, GHIN, and 18Birdies, and generates interactive HTML and PDF round reports with shot maps and stats via local MCP tools.
Updated 4 months ago (2026-06-14 22:24 UTC)
-
xweather
Weather Services Location Services Data Visualization
manufacts
A
license
Not graded
quality
B
maintenance
Enables map-only weather exploration with live storm cells, lightning, forecast layers, and up to five monitored places through MCP tools.
Updated 25 days ago (2026-09-21 16:06 UTC)
MIT

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

Need Help?