PGA Golf

Search Golf Programs

search_golf_programs

Read-only

Search for upcoming public PGA Coach programs (clinics, camps, classes, and other group events) near a location (required). Use this tool when the user asks to find programs, clinics, camps, classes, or group events — not private one-on-one lessons. For private lesson coaches, use search_golf_coaches instead. Internal record identifiers (for example program id and coach slug) are for tool calls only and must never be shown or mentioned to the user.

Search results include program details plus the hosting coach and facility for each program.
The response also includes top-level coaches and facilities arrays summarizing the unique coaches and venues in the result set — always present those to the user.
Results are ordered by program start instant and filtered to the requested radius.
Discovery uses nearby PGA Coach profiles (nearest 20 in the radius), then loads up to 30 upcoming public programs per coach in a 180-day window in one batched GraphQL request. Facility coordinates still have to fall inside the radius.
Results are paginated. The pagination cursor carries the remaining nearby programs so additional pages do not repeat GraphQL discovery. Reuse that cursor with the original location and radius.
Direct golfers to the program URL to view details and register. Coach profile and booking URLs are also included when the golfer wants to learn more about the coach.

Input Schema

TableJSON Schema

Name	Required	Description
`searchRadius`	No	Search radius in miles from `searchLocation`. Use 50 by default unless the user requests a different radius.
`searchLocation`	Yes	Required location used to find nearby PGA Coach programs. Accepts city/state, ZIP code, full address, or latitude/longitude coordinates.
`paginationCursor`	No	Pagination cursor from a prior `search_golf_programs` response. Use only when fetching additional pages of the same search (same location and radius).

Output Schema

TableJSON Schema

Name	Required	Description
`count`	Yes
`coaches`	Yes	Unique coaches hosting the returned programs. Present these alongside the programs so golfers can see who is teaching.
`programs`	Yes
`endCursor`	Yes
`facilities`	Yes	Unique facilities hosting the returned programs. Present these alongside the programs so golfers can see where programs are held.
`hasNextPage`	Yes

TDQS

A4.8/5.0

Behavior5/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, establishing the tool is safe. The description adds rich behavioral details: discovery uses nearby PGA Coach profiles, loads up to 30 programs per coach in a 180-day window via batched GraphQL request, pagination cursor behavior, ordering by start instant, and the inclusion of top-level `coaches` and `facilities` arrays. No contradictions with 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?

The description is well-structured with front-loaded purpose, then usage guidance, then behavioral details, and finally pagination instructions. Each sentence is justified. It is slightly longer than necessary but remains clear and non-redundant. A minor improvement would be to trim redundant explanations of the pagination cursor already covered in the schema.

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 the complexity (3 parameters, output schema exists, annotations present), the description covers purpose, usage, behavioral mechanics, pagination, and presentation instructions. It explains the internal discovery process, pagination reuse, and directs users to program URLs. No gaps are evident for an AI agent to correctly select and invoke the tool.

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 description coverage is 100%, so baseline is 3. The description adds value for `searchLocation` by specifying accepted formats (city/state, ZIP, address, lat/lng). For `searchRadius` and `paginationCursor`, the schema already provides detailed descriptions; the description reinforces pagination behavior but does not add new parameter-specific semantics. Overall, it provides meaningful extra context beyond the schema.

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 clearly states the tool searches for 'upcoming public PGA Coach programs (clinics, camps, classes, and other group events) near a location.' It explicitly distinguishes from private lessons and names the sibling tool `search_golf_coaches` for that purpose. The verb 'search' and resource 'golf programs' are specific and unambiguous.

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?

The description provides explicit when-to-use guidance: 'Use this tool when the user asks to find programs, clinics, camps, classes, or group events — not private one-on-one lessons.' It also gives a clear alternative: 'For private lesson coaches, use `search_golf_coaches` instead.' This covers both positive and negative use cases.

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

All PGA Golf tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.6/5.0

Disambiguation5/5

Each tool targets a distinct aspect of the golf coaching process: searching for coaches (private), searching for programs (group), checking a specific coach's availability, and booking a lesson. There is no overlap in functionality.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern using snake_case (book_golf_lesson, get_golf_coach_availability, search_golf_coaches, search_golf_programs). The naming is predictable and clear.

Tool Count5/5

With 4 tools, the server is tightly scoped to the core workflow of discovering and booking golf lessons. It is neither too sparse nor excessive for its purpose.

Completeness4/5

The tool set covers the main discovery and booking workflows well. However, it lacks tools for canceling or modifying bookings, which are common post-booking actions. This is a minor gap given the server's apparent focus on initial booking.

Resources

Need Help?