Skip to main content
Glama

Search Golf Coaches

search_golf_coaches
Read-only

Search for qualified PGA golf coaches listed on pga.com/coach in the specified location (required). Use this tool when the user asks to find, browse, or compare coaches for private lessons in a location. For location-first discovery of clinics, camps, classes, or other group programs, use search_golf_programs instead. If the user asks for availability for a specific coach, use get_golf_coach_availability instead. Internal record identifiers (for example coach slug and offering id) are for tool calls only and must never be shown or mentioned to the user.

  • Search results include the coach's profile information, private-lesson offerings, pricing, and a short teaser of upcoming public programs they host (capped at 2). For location-first program discovery, use search_golf_programs.

  • Use that program context to recommend which group offering best fits the golfer when relevant; present upcoming programs when available.

  • Results are ordered by proximity to the search location, so list them to the user in this order.

  • Results are paginated, so use the pagination cursor provided at the end of the response to retrieve the next page of results.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
searchRadiusNoSearch radius in miles from `searchLocation`. Use 25 by default unless the user requests a different radius.
searchLocationYesRequired location used to find nearby coaches. Accepts city/state, ZIP code, full address, or latitude/longitude coordinates.
paginationCursorNoPagination cursor from a prior `search_golf_coaches` response. Use only when fetching additional pages of the same search.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
countYes
coachesYes
endCursorYes
hasNextPageYes

TDQS

A4.6/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true (safe, read-only operation). The description adds valuable context beyond annotations: ordering by proximity, pagination behavior, that results are capped at 2 program teasers, and that internal record identifiers must be hidden from users. No contradictions are present.

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 front-loaded with the essential purpose, then usage guidelines, then behavioral details. It is reasonably concise for the amount of guidance provided, though the repeated sibling references could be slightly tighter. Every sentence adds value.

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 presence of an output schema and good annotations, the description covers all necessary aspects: what the tool does, when to use it vs siblings, ordering, pagination, and handling of internal identifiers. No gaps remain for the agent to make correct decisions.

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 good descriptions for all parameters. The description amplifies understanding by clarifying that searchLocation is required and provides guidance on default searchRadius (25 miles unless user requests otherwise). It also explains the paginationCursor usage appropriately.

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 uses a specific verb ('Search') and resource ('qualified PGA golf coaches listed on pga.com/coach'), clearly distinguishing its purpose from siblings. It explicitly states the required location and that results include profile info, pricing, and program teasers.

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 ('when the user asks to find, browse, or compare coaches for private lessons'), when-not-to-use alternatives ('use search_golf_programs for clinics/camps/classes; use get_golf_coach_availability for coach availability'), and even advises on presenting results to the user.

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

Try in Browser

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