golfdata.online — verified golf clubs

Send a booking request to a club

request_booking

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.

Input Schema

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	Default
`note`	No
`links`	No
`phone`	No
`reason`	No
`status`	No
`channel`	No
`accepted`	Yes
`request_id`	No
`booking_url`	No
`whatsapp_url`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 30, 2026

addedOutput schema / properties / links

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

AddedOct 30, 2026

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.

All golfdata.online — verified golf clubs tools Inspect

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?