golfdata.online — verified golf clubs

by online.golfdata

Overview Discussions Admin

Server Details

Golf clubs & courses directory (not equipment): facts, booking links, requests where enabled

Ownership verified

Status: Healthy
Uptime: 100.0% over the last 24 hours
Last Tested: 2026-11-09 20:22
Transport: Streamable HTTP · MCP 2025-06-18
URL
ChatGPT: –
Claude: –

TDQS

A4/5.0

Scored 2026-11-01 13:20 across 4 tools

Disambiguation4/5

Each tool maps to a distinct operation: free-text search, single-record fetch, provenance listing, and booking request. The only soft overlap is that get_club already returns sources[] while list_sources_for exists to page full provenance, which could cause an agent to pick one when it meant the other.

Naming Consistency4/5

All names are snake_case verb_noun constructions (search_clubs, get_club, request_booking), which is predictable. list_sources_for adds a prepositional object and is the only slight deviation from the pattern.

Tool Count4/5

Four tools is lean but each covers a real step: discovery, detail, provenance, and booking. It is slightly thin for a directory-plus-booking service, but nothing looks redundant or padded.

Completeness3/5

The read side is well covered (search, get, provenance) and there is a write path via request_booking, but the booking lifecycle is a dead end: no way to check a request's status, cancel it, or retrieve it by id. There is also no tool to enumerate valid country/island/region filter values, forcing agents to guess filter inputs.

Available Tools

4 tools

get_clubGet golf club detailsA

Read-onlyIdempotent

Inspect

Get one approved club by UUID or slug, with all facts, sources[] (max 200; sources_truncated: true if cut) and club_facts: what the club itself published from its verified account (green fee, visitor rules, booking link, hours, buggies, dress code, languages), or null. phone is in E.164 (e.g. +441375891352). links carries tracked booking/website/phone URLs — give users links.* so the club sees demand for it (the raw booking_url/website/phone fields are unchanged).

Name	Required	Description
`topic`	No	What the golfer wants to know (optional).
`question`	No	The golfer's question, as asked (optional). It is stored, cleaned of personal data, and shown to the club as what golfers ask; it does not change the answer.
`id_or_slug`	Yes	UUID or slug

Output Schema

Name	Required	Description
`id`	No
`lat`	No
`lng`	No
`par`	No
`card`	No
`name`	No
`slug`	No
`email`	No
`found`	Yes
`holes`	No
`links`	No
`phone`	No
`island`	No
`region`	No
`address`	No
`country`	No
`sources`	No
`version`	No
`website`	No
`currency`	No
`designer`	No
`length_m`	No
`postcode`	No
`visitors`	No
`club_facts`	No
`facilities`	No
`length_tee`	No
`updated_at`	No
`booking_url`	No
`course_type`	No
`entity_type`	No
`year_opened`	No
`green_fee_to`	No
`handicap_max`	No
`municipality`	No
`slope_rating`	No
`course_rating`	No
`federation_id`	No
`last_verified`	No
`green_fee_from`	No
`green_fee_year`	No
`club_facts_note`	No
`sources_truncated`	No
`booking_requests_enabled`	No

TDQS

A4.2/5.0

Behavior5/5

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

Goes well past the annotations (which only declare read-only/idempotent/non-destructive) by disclosing the 200-source cap and the sources_truncated flag, that club_facts can be null, the E.164 phone format, and that links.* are tracked URLs while raw fields stay unchanged. These are exactly the non-obvious traits an agent needs to interpret results correctly.

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-loads verb, resource, and lookup key, then layers return-shape and usage notes; nearly every clause carries information. It is dense with parentheticals (max 200; sources_truncated; the raw fields are unchanged) that make it slightly 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?

An output schema exists, yet the description still supplies the interpretive context that matters (truncation semantics, nullability of club_facts, link tracking). For a single-record read with full annotation coverage, 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 description coverage is 100%, so all three parameters are already documented; the description adds little on parameters beyond restating that the lookup key is a UUID or slug. It never mentions the topic enum or how topic interacts with the returned club_facts, which would have been the value-add.

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 and resource ('Get one approved club by UUID or slug') and enumerates the payload it returns (facts, sources[], club_facts). This clearly separates it from the sibling search_clubs (many results, query-based) and list_sources_for (sources only), so an agent can pick it 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 Guidelines3/5

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

The identifier requirement ('by UUID or slug') implies you must resolve a club via search_clubs first, but that prerequisite is never stated and no sibling is named as an alternative. The only explicit guidance is output-side ('give users links.* so the club sees demand'), not when-to-call guidance.

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

list_sources_forList sources for a clubA

Read-onlyIdempotent

Inspect

List provenance (source URL, publisher, trust level, field, retrieved_at) for a club (max 200; sources_truncated: true if cut).

Name	Required	Description	Default
`entity_id`	Yes	Entity UUID
`entity_type`	Yes

Output Schema

Name	Required	Description
`sources`	Yes
`entity_id`	Yes
`entity_type`	Yes
`sources_truncated`	No

TDQS

A3.8/5.0

Behavior4/5

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

Annotations already declare this as read-only, idempotent, non-destructive, and closed-world. The description adds useful behavioral detail beyond annotations: a maximum of 200 results and a sources_truncated flag when results are cut.

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?

A single compact sentence front-loads the purpose, lists the returned provenance fields, and states the cap and truncation behavior. Every element earns its place.

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 an output schema present and rich annotations covering safety, the description supplies the key runtime detail an agent needs: the 200-item cap and truncation indicator. It could be slightly stronger with explicit usage guidance, but it is largely complete.

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 50%. The description implies the entity is a club, matching the entity_type enum, but adds no detail about entity_id format or parameter naming beyond what the schema provides.

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?

The description names a specific verb and resource: listing provenance sources for a club. It clearly distinguishes the tool from siblings like get_club and search_clubs by focusing on source/provenance data, though it does not explicitly name those siblings.

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?

Usage is implied: call this when you need provenance information for a club. There is no explicit when-to-use vs. when-not-to-use guidance and no mention of alternatives such as get_club.

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

request_bookingSend a booking request to a clubAInspect

Send a booking request to a club whose card says booking.requests_enabled is true. golfdata only FORWARDS the request to the club (by email, or a WhatsApp click-to-chat link) and does NOT confirm the booking. Returns a request id and, for the whatsapp channel, a tracked link. For a club that is not enabled it returns accepted: false. You must have the golfer's consent before sending their name, email or phone. The golfer's details are forwarded to the club and kept for 24 months, then anonymized; a golfer can ask to erase them sooner by writing to hello@golfdata.online.

Name	Required	Description
`date`	Yes	Requested play date, YYYY-MM-DD (today..+365).
`name`	Yes	The golfer's name (with their consent).
`time`	No	Preferred tee time, HH:MM (24h).
`email`	Yes	The golfer's email (with their consent); used as reply-to, never shared beyond the club.
`holes`	No	9 or 18.
`phone`	No	The golfer's phone in E.164, e.g. +34600123456 (with their consent).
`channel`	No	email (default) or whatsapp.
`club_id`	Yes	Club UUID (from get_club or the card).
`message`	No	Optional message to the club.
`players`	Yes	Number of players, 1..8.

Output Schema

Name	Required	Description
`note`	No
`links`	No
`phone`	No
`reason`	No
`status`	No
`channel`	No
`accepted`	Yes
`request_id`	No
`booking_url`	No
`whatsapp_url`	No

TDQS

A4.6/5.0

Behavior5/5

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

Goes well beyond the annotations (readOnlyHint=false, openWorldHint=true, idempotentHint=false) by disclosing that the request is only forwarded to the club via email or a WhatsApp click-to-chat link and never confirmed, that a not-enabled club yields accepted: false rather than an error, and that the response contains a request id plus a tracked link on the whatsapp channel. It also surfaces consent and 24-month retention/anonymization obligations, which the annotations cannot express.

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 precondition and the forwards-does-not-confirm disclaimer, then returns, then consent/privacy. Dense and largely waste-free, though the final retention sentence is long and slightly crowds the operative guidance.

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 10-parameter, 5-required, open-world mutation with an output schema, the description covers the precondition, side effects, failure mode, response shape, consent, and data lifecycle. Nothing an agent needs in order to call it safely or interpret the result is missing.

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%, so the baseline is 3; the description earns more by tying name/email/phone to the consent requirement and explaining that email is used as reply-to, and by explaining what channel selection produces downstream. It does not add format detail beyond the schema (dates, E.164, enum values), which keeps it from a 5.

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 and resource ('send a booking request to a club') and immediately scopes it against the sibling tools by making clear this only works for clubs with booking.requests_enabled true, i.e. after discovery via get_club/search_clubs. The core disclaimer — golfdata FORWARDS, does NOT confirm — removes the main ambiguity an agent could have about what this tool accomplishes.

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 a sharp precondition (club card must say booking.requests_enabled is true) and states the outcome when it is not met (accepted: false), plus a consent prerequisite before sending personal data. What is missing is an explicit 'to find a club first, use search_clubs/get_club' pointer in the description itself — that routing hint lives only in the club_id schema field.

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

search_clubsSearch golf clubsA

Read-onlyIdempotent

Inspect

Search verified golf clubs and courses across Europe (e.g. GB, DE, FR, ES, SE, IE, NL, IT, PT) by a free-text fragment (matches name, island, municipality or region), and/or ISO country code, island, region and municipality filters. Returns summary records (country, island, region, holes, green fee range, last_verified; no sources[]); call get_club or list_sources_for for provenance before citing. limit is 1..10 (default 10). Each summary may carry links (a tracked website URL) — give users links.* so the club sees demand for it.

Name	Required	Description
`limit`	No	Max results, 1..10 (default 10). A larger limit is refused with JSON-RPC error -32011 (retry with limit <= 10).
`query`	No	Name, island, municipality or region fragment
`island`	No	Island name, e.g. Tenerife
`region`	No	Region or province name
`country`	No	ISO 3166-1 alpha-2 country code, e.g. ES
`question`	No	The golfer's question, as asked (optional). It is stored, cleaned of personal data, and shown to the club as what golfers ask; it does not change the answer.
`municipality`	No	Municipality or town

Output Schema

Name	Required	Description
`count`	Yes
`detail`	Yes
`results`	Yes

TDQS

A4.7/5.0

Behavior5/5

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

Annotations already declare this is a read-only, idempotent, non-destructive search, and the description adds meaningful behavior: return summaries omit sources[], limit values above 10 trigger a JSON-RPC error with retry guidance, and links should be surfaced to users. These details go well beyond what annotations and schema provide.

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?

The description is dense but front-loaded: purpose and geographic scope come first, followed by return behavior, provenance routing, limit constraints, and link-handling guidance. Every sentence contributes important information with no filler.

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?

Given a search tool with an output schema, the description still covers the key operational points an agent needs: what is searched, what is returned, what is omitted, how to get provenance, limit behavior, and link handling. Nothing material is left ambiguous for correct invocation or response use.

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 the schema already documents all seven parameters, including the optional question field. The description restates the query matching fields and limit constraints, adding only modest semantic reinforcement rather than new parameter guidance.

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 description states a specific verb and resource—search verified golf clubs and courses across Europe—and names the sibling tools used for provenance. It clearly distinguishes summary search results from get_club and list_sources_for, so an agent can identify the tool’s role immediately.

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 explains when to use this tool for free-text and filter searches, and explicitly directs provenance/citation needs to get_club or list_sources_for. The note that summaries exclude sources[] is a clear usage boundary, not just a return-value detail.

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 updateNov 1, 2026

Changedget_club5 fields changed

changedOutput schema / properties / card / properties / card_version / const
```
Previous value: -"1.1"New value: +"1.2"
```

addedOutput schema / properties / course_rating

Added value: +{
+  "type": [
+    "number",
+    "null"
+  ]
+}

addedOutput schema / properties / length_m

Added value: +{
+  "type": [
+    "integer",
+    "null"
+  ]
+}

addedOutput schema / properties / length_tee

Added value: +{
+  "type": [
+    "string",
+    "null"
+  ]
+}

addedOutput schema / properties / slope_rating

Added value: +{
+  "type": [
+    "integer",
+    "null"
+  ]
+}

1 tool updateOct 31, 2026

Changedsearch_clubs5 fields changed

addedInput schema / properties / island

Added value: +{
+  "description": "Island name, e.g. Tenerife",
+  "maxLength": 60,
+  "type": "string"
+}

addedInput schema / properties / limit / description

Added value: +"Max results, 1..10 (default 10). A larger limit is refused with JSON-RPC error -32011 (retry with limit <= 10)."

changedInput schema / properties / limit / maximum
```
Previous value: -50New value: +10
```

changedInput schema / properties / query / description

Previous value: -"Name fragment"New value: +"Name, island, municipality or region fragment"

addedInput schema / properties / region

Added value: +{
+  "description": "Region or province name",
+  "maxLength": 60,
+  "type": "string"
+}

3 tool updatesOct 30, 2026

Changedget_club1 field changed

addedOutput schema / properties / links

Added value: +{
+  "properties": {
+    "booking": {
+      "type": "string"
+    },
+    "phone": {
+      "type": "string"
+    },
+    "website": {
+      "type": "string"
+    }
+  },
+  "required": [],
+  "type": "object"
+}

Changedrequest_booking1 field changed

addedOutput schema / properties / links

Added value: +{
+  "properties": {
+    "booking": {
+      "type": "string"
+    },
+    "phone": {
+      "type": "string"
+    },
+    "website": {
+      "type": "string"
+    }
+  },
+  "required": [],
+  "type": "object"
+}

Changedsearch_clubs1 field changed

addedOutput schema / properties / results / items / properties / links

Added value: +{
+  "properties": {
+    "booking": {
+      "type": "string"
+    },
+    "phone": {
+      "type": "string"
+    },
+    "website": {
+      "type": "string"
+    }
+  },
+  "required": [],
+  "type": "object"
+}

2 tool updatesOct 30, 2026
- Changedget_club2 fields changed
  - addedOutput schema / properties / booking_requests_enabled
```
Added value: +{
+  "type": [
+    "boolean",
+    "null"
+  ]
+}
```
  - changedOutput schema / properties / card / properties / card_version / const
```
Previous value: -"1.0"New value: +"1.1"
```
- Addedrequest_booking

1 tool updateOct 29, 2026

Changedget_club1 field changed

addedOutput schema / properties / card

Added value: +{
+  "properties": {
+    "card_version": {
+      "const": "1.0",
+      "type": "string"
+    }
+  },
+  "required": [
+    "card_version"
+  ],
+  "type": "object"
+}

1 tool updateOct 29, 2026
- Changedget_club8 fields changed
  - addedOutput schema / properties / club_facts / properties / facts / properties / booking_email
```
Added value: +{}
```
  - addedOutput schema / properties / club_facts / properties / facts / properties / buggy_price
```
Added value: +{}
```
  - addedOutput schema / properties / club_facts / properties / facts / properties / cancellation
```
Added value: +{}
```
  - addedOutput schema / properties / club_facts / properties / facts / properties / expected_response
```
Added value: +{}
```
  - addedOutput schema / properties / club_facts / properties / facts / properties / green_fees
```
Added value: +{}
```
  - addedOutput schema / properties / club_facts / properties / facts / properties / hours_structured
```
Added value: +{}
```
  - addedOutput schema / properties / club_facts / properties / facts / properties / lead_time
```
Added value: +{}
```
  - addedOutput schema / properties / club_facts / properties / facts / properties / whatsapp_e164
```
Added value: +{}
```

3 tool updatesOct 29, 2026

Changedget_club1 field changed

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "address": {
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "booking_url": {
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "club_facts": {
+      "properties": {
+        "facts": {
+          "properties": {
+            "booking_url": {},
+            "buggy": {},
+            "dress_code": {},
+            "green_fee_from": {},
+            "green_fee_to": {},
+            "green_fee_year": {},
+            "handicap_max": {},
+            "hours": {},
+            "languages": {},
+            "notes": {},
+            "visitors": {}
+          },
+          "required": [],
+          "type": "object"
+        },
+        "published_at": {
+          "type": [
+            "string",
+            "null"
+          ]
+        }
+      },
+      "required": [
+        "published_at",
+        "facts"
+      ],
+      "type": [
+        "object",
+        "null"
+      ]
+    },
+    "club_facts_note": {
+      "type": "string"
+    },
+    "country": {
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "course_type": {
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "currency": {
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "designer": {
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "email": {
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "entity_type": {
+      "enum": [
+        "club"
+      ],
+      "type": "string"
+    },
+    "facilities": {},
+    "federation_id": {
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "found": {
+      "type": "boolean"
+    },
+    "green_fee_from": {
+      "type": [
+        "number",
+        "null"
+      ]
+    },
+    "green_fee_to": {
+      "type": [
+        "number",
+        "null"
+      ]
+    },
+    "green_fee_year": {
+      "type": [
+        "integer",
+        "null"
+      ]
+    },
+    "handicap_max": {
+      "type": [
+        "number",
+        "null"
+      ]
+    },
+    "holes": {
+      "type": [
+        "integer",
+        "null"
+      ]
+    },
+    "id": {
+      "type": "string"
+    },
+    "island": {
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "last_verified": {
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "lat": {
+      "type": [
+        "number",
+        "null"
+      ]
+    },
+    "lng": {
+      "type": [
+        "number",
+        "null"
+      ]
+    },
+    "municipality": {
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "name": {
+      "type": "string"
+    },
+    "par": {
+      "type": [
+        "integer",
+        "null"
+      ]
+    },
+    "phone": {
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "postcode": {
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "region": {
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "slug": {
+      "type": "string"
+    },
+    "sources": {
+      "items": {
+        "properties": {
+          "extracted_value": {
+            "type": [
+              "string",
+              "null"
+            ]
+          },
+          "field": {
+            "type": [
+              "string",
+              "null"
+            ]
+          },
+          "publisher": {
+            "type": [
+              "string",
+              "null"
+            ]
+          },
+          "retrieved_at": {
+            "type": [
+              "string",
+              "null"
+            ]
+          },
+          "trust_level": {
+            "type": [
+              "integer",
+              "null"
+            ]
+          },
+          "url": {
+            "type": [
+              "string",
+              "null"
+            ]
+          }
+        },
+        "required": [],
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "sources_truncated": {
+      "type": "boolean"
+    },
+    "updated_at": {
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "version": {
+      "type": [
+        "integer",
+        "null"
+      ]
+    },
+    "visitors": {
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "website": {
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "year_opened": {
+      "type": [
+        "integer",
+        "null"
+      ]
+    }
+  },
+  "required": [
+    "found"
+  ],
+  "type": "object"
+}

Changedlist_sources_for1 field changed

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "entity_id": {
+      "type": "string"
+    },
+    "entity_type": {
+      "enum": [
+        "club"
+      ],
+      "type": "string"
+    },
+    "sources": {
+      "items": {
+        "properties": {
+          "extracted_value": {
+            "type": [
+              "string",
+              "null"
+            ]
+          },
+          "field": {
+            "type": [
+              "string",
+              "null"
+            ]
+          },
+          "publisher": {
+            "type": [
+              "string",
+              "null"
+            ]
+          },
+          "retrieved_at": {
+            "type": [
+              "string",
+              "null"
+            ]
+          },
+          "trust_level": {
+            "type": [
+              "integer",
+              "null"
+            ]
+          },
+          "url": {
+            "type": [
+              "string",
+              "null"
+            ]
+          }
+        },
+        "required": [],
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "sources_truncated": {
+      "type": "boolean"
+    }
+  },
+  "required": [
+    "entity_type",
+    "entity_id",
+    "sources"
+  ],
+  "type": "object"
+}

Changedsearch_clubs1 field changed

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "count": {
+      "type": "integer"
+    },
+    "detail": {
+      "type": "string"
+    },
+    "results": {
+      "items": {
+        "properties": {
+          "country": {
+            "type": [
+              "string",
+              "null"
+            ]
+          },
+          "course_type": {
+            "type": [
+              "string",
+              "null"
+            ]
+          },
+          "entity_type": {
+            "enum": [
+              "club"
+            ],
+            "type": "string"
+          },
+          "green_fee_from": {
+            "type": [
+              "number",
+              "null"
+            ]
+          },
+          "green_fee_to": {
+            "type": [
+              "number",
+              "null"
+            ]
+          },
+          "green_fee_year": {
+            "type": [
+              "integer",
+              "null"
+            ]
+          },
+          "holes": {
+            "type": [
+              "integer",
+              "null"
+            ]
+          },
+          "id": {
+            "type": "string"
+          },
+          "island": {
+            "type": [
+              "string",
+              "null"
+            ]
+          },
+          "last_verified": {
+            "type": [
+              "string",
+              "null"
+            ]
+          },
+          "municipality": {
+            "type": [
+              "string",
+              "null"
+            ]
+          },
+          "name": {
+            "type": "string"
+          },
+          "par": {
+            "type": [
+              "integer",
+              "null"
+            ]
+          },
+          "region": {
+            "type": [
+              "string",
+              "null"
+            ]
+          },
+          "slug": {
+            "type": "string"
+          },
+          "visitors": {
+            "type": [
+              "string",
+              "null"
+            ]
+          },
+          "website": {
+            "type": [
+              "string",
+              "null"
+            ]
+          }
+        },
+        "required": [
+          "id",
+          "slug",
+          "name",
+          "entity_type"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    }
+  },
+  "required": [
+    "count",
+    "detail",
+    "results"
+  ],
+  "type": "object"
+}

2 tool updatesOct 29, 2026

Changedget_club2 fields changed

addedInput schema / properties / question

Added value: +{
+  "description": "The golfer's question, as asked (optional). It is stored, cleaned of personal data, and shown to the club as what golfers ask; it does not change the answer.",
+  "maxLength": 500,
+  "type": "string"
+}

addedInput schema / properties / topic

Added value: +{
+  "description": "What the golfer wants to know (optional).",
+  "enum": [
+    "green_fee",
+    "booking",
+    "hours",
+    "visitors",
+    "handicap",
+    "buggy",
+    "dress_code",
+    "languages",
+    "contact",
+    "course",
+    "other"
+  ],
+  "type": "string"
+}

Changedsearch_clubs4 fields changed

addedInput schema / properties / country

Added value: +{
+  "description": "ISO 3166-1 alpha-2 country code, e.g. ES",
+  "maxLength": 2,
+  "type": "string"
+}

removedInput schema / properties / island

Removed value: -{
-  "enum": [
-    "Tenerife",
-    "Gran Canaria",
-    "Lanzarote",
-    "Fuerteventura",
-    "La Palma",
-    "La Gomera",
-    "El Hierro"
-  ],
-  "type": "string"
-}

changedInput schema / properties / municipality / description

Previous value: -"Municipality"New value: +"Municipality or town"

addedInput schema / properties / question

Added value: +{
+  "description": "The golfer's question, as asked (optional). It is stored, cleaned of personal data, and shown to the club as what golfers ask; it does not change the answer.",
+  "maxLength": 500,
+  "type": "string"
+}

3 tool updatesOct 18, 2026
- First observedget_club
- First observedlist_sources_for
- First observedsearch_clubs

Publisher details

Operator: Canary Tech Labs S.L.
Operator website: https://golfdata.online
Vendor relationship: First-party · Publisher source
Documentation: https://golfdata.online/llms.txt
Trust center: Not applicable
Restrictions: Not applicable

Related MCP Connectors

ParHard courses
com.parhard
US golf course facts with sources, plus your own rounds and stats with Plus and your consent.
1
https://parhard.com/mcp
GolfPrice AIA
io.github.557tggwysr-ui
Live UK golf prices, genuine price drops, handicap maths and golf society tools.
E-commerce & Retail Sports
131
https://golfpriceai-mcp.golfpriceai.workers.dev/mcp
Private ClubsA
com.theprivateclubs
Search, look up and compare private membership clubs worldwide
Search Location Services
51
https://www.theprivateclubs.com/api/mcp
Chalk Golf
com.chalkgolfapp
Your own golf rounds, stats, handicap record and swings. Logs practice and rounds with your OK.
Sports Fitness Tracking
1
https://api.chalkgolfapp.com/mcp

Related MCP Servers

OpenGolfAPI MCP Serverofficial
Sports Location Services
opengolfapi
A
license
A
quality
D
maintenance
Enables AI agents to search and retrieve detailed information about US golf courses, including course details, tees, climate, and nearby points of interest.
Updated 3 months ago (2026-08-18 18:57 UTC)
6
152 npm
4
MIT
Hat Trick Local Directory
Sports Search Location Services
Build-Stuff-Fast
A
license
Not graded
quality
C
maintenance
Enables read-only search and lookup of US youth sports clubs and local sports stores, including registration windows, fees, tryouts, contacts, addresses, and brands, plus link generation for claiming or correcting listings.
Updated 18 days ago (2026-10-22 16:00 UTC)
MIT
Golf v2 MCP Server
Sports Data Platforms
ag2-mcp-servers
F
license
Not graded
quality
D
maintenance
An auto-generated Multi-Agent Conversation Protocol server that enables interaction with professional golf data through the SportsData.io Golf v2 API.
Updated a year ago (2025-07-16 14:29 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 5 months ago (2026-06-14 22:24 UTC)
-