Skip to main content
Glama
opengolfapi

OpenGolfAPI MCP Server

Official
by opengolfapi
OverviewSchemaRelated ServersScoreDiscussions
TypeScript
Remote

@opengolfapi/mcp-server

Golf, for AI agents — the open data layer for golf. Give your assistant every US golf course (16,845), free, and let it contribute back, sign players in, and run tournaments. Build a whole golf app from a prompt.

OpenGolfAPI is a community-owned commons. One free key, and your agent can read the world's golf data and write to four open standards.

The standards (the whole story)

OpenGolfAPI is built on open, composable protocols — implement one or all:

Standard

What it is

You use it to…

OpenShot

A CC0 shape for a launch-monitor shot — one schema every device maps to (Trackman, GSPro, Garmin, …).

Ingest shots from any monitor/sim → log_shot.

Moments

The universal event ingest — any sensor signal (GPS breadcrumb, swing, putt, club, score, pin, condition, presence) as one flexible event.

Send whatever signal you have → submit_moment.

OpenJoin

Signed, scoped, expiring join tokens. One QR/link → everyone who redeems lands in the same round/tournament = the group, linked.

Onboard a foursome or a whole tournament in one tap → create_tournament_invite / join_tournament.

OpenGolf ID

A portable golf identity — "Sign in with OpenGolf." One pseudonymous player_id across every app; handicap + history follow the player everywhere (engines fold by player_id, so a claimed identity's cross-app record just exists).

Give a player one identity the whole ecosystem shares → sign_in_with_opengolf.

The big idea: every shot, moment, and round contributed makes the shared commons better for everyone — a true two-way data layer. Read is free; contributing is how you earn your place in the standard.

Related MCP server: Jinko Hotel Booking MCP Server

What your agent gets

  • Read (free, no key): search & compare courses · full scorecards (par / handicap / yardages) · hazards · live weather & climate · nearby places · tee advice.

  • Contribute (free key): log_shot, submit_moment → write to the open standards · get_my_shots → read your own data back.

  • Identity & tournaments (free key): sign_in_with_opengolf (portable ID) · create_tournament_invite + join_tournament (run an event — handicaps optional, gross or net).

A great golf app is an afternoon, not a year.

Install (MCP client config)

{
  "mcpServers": {
    "opengolfapi": {
      "command": "npx",
      "args": ["-y", "@opengolfapi/mcp-server"],
      "env": {
        "OPENGOLFAPI_KEY": "<free, optional — enables contributing, identity & tournaments>"
      }
    }
  }
}

Get a free OPENGOLFAPI_KEY at https://courses.opengolfapi.org/api-keys. Read tools work with no key.

Claude Desktop: the config file is claude_desktop_config.json (Settings → Developer → Edit Config). Claude Code: claude mcp add opengolfapi -- npx -y @opengolfapi/mcp-server. Going keyless? Delete the whole env block — every read tool works without it (do NOT paste the placeholder as a key).

First prompt to try: "Find golf courses near Chicago and show me the hardest one."

Which score tool when: casual one-shot scoring → score_round · leagues/tournaments (scores arrive over time, standings matter) → create_competition → record_attempt → finalize_competition · streaming devices/live apps → submit_moment. Canonical domain model: https://api.opengolfapi.org/api/v1/model

Tools

56 tools:

  • search_courses — Search US golf courses by name, US state, or location (lat/lng + radius). Returns matching courses with location, type, par. Free, ODbL data.

  • get_course — Full detail for one course by id: scorecard (par + handicap per hole), tees, location, contact, nearby. Free.

  • get_tees — All tee sets for a course with ratings, slopes, and yardages. Free.

  • get_weather — Live weather forecast for a course location (Weather.gov). Free.

  • get_climate — Monthly climate normals + best months to play for a course. Free.

  • get_nearby — Nearby hotels, restaurants, and other courses for a course. Free.

  • log_shot — Contribute a golf shot to the open OpenShot standard (any launch monitor). Requires a key. Units: speed mph, angles deg, spin rpm, distance yds.

  • submit_moment — Contribute an Open Connect event from any sensor/wearable/phone. The whole sensor spectrum rides through here — type-specific data goes in payload. Requires a key.

  • get_my_shots — Read back your own contributed shots by player or session. Requires a key.

  • get_my_moments — Read back your own contributed moments (breadcrumbs, swings, putts, conditions…) by player, session, or type. Requires a key.

  • propose_correction — Propose a fix to a course FACT field (phone, website, address, architect, year_built, course_name, city, postal_code, course_type). Our AI reviews it (approve/reject/needs_info). Requires a key. Geometry is not correctable here.

  • respond_to_review — Respond to a correction that came back as needs_info — add a source or explanation and re-open it for review. Requires a key.

  • get_correction — Check the status/verdict of a correction you proposed (approved | rejected | needs_info | applied). Requires a key.

  • how_to_build — The safe playbook for building on OpenGolfAPI and contributing data the right way. Call this once before contributing.

  • get_passport — FREE (public, no key). Any golfer's shareable record — display name, OpenGolf Member #, courses played, rounds, trophies, referrals. Show a player's golf resume in your app.

  • record_referral — Record that one user referred another (a REFERRED_BY edge) — build YOUR app's invite loop on the shared graph, namespaced to your app. Needs a key.

  • get_referrals — How many golfers a user has referred (+ the list) — the viral-loop metric for your app. Needs a key.

  • about — What OpenGolfAPI is and how to use this MCP server.

  • request_sign_in_code — Start "Sign in with OpenGolf" for a person: emails them a 6-digit code. No API key needed. They read you the code, then call complete_sign_in.

  • complete_sign_in — Finish sign-in: exchange the 6-digit code for their OpenGolf ID + access token (use as X-OpenGolf-Token to act as them). Pass ref= when another player's invite brought them — it credits the referral.

  • create_dev_key — Mint a developer API key bound to an OpenGolf ID (sign in first via request_sign_in_code → complete_sign_in). Returns the key ONCE. First-party rail: no OpenGolf ID, no key.

  • sign_in_with_opengolf — Derive a user's OpenGolf ID deterministically from their email (sub = ogid_ + sha256(lower(trim(email)))[:16]) — one line, no redirect. For a VERIFIED session token use request_sign_in_code → complete_sign_in.

  • register_webhook — Register an https URL for your domain events (HMAC-signed deliveries, owner-scoped). Requires your key (Authorization: Bearer ogapi_…).

  • create_tournament_invite — Create a shareable invite (QR/link); everyone who redeems it joins the SAME event/session. max_uses caps size (foursome=4). Requires key.

  • join_tournament — Redeem an invite token — the player joins the group/event. Requires key.

  • list_game_formats — Every OpenMatch scoring format. GROSS scoring is free & keyless.

  • score_round — Score a round in any format — GROSS, FREE, no key. players:[{player_id,holes:{"1":4}}] or entries:[{player_id,hole,value}]; holes:[{hole,par,stroke_index?}].

  • plays_like — Effective distance — THE canonical "plays like" number (wind/elevation/temp/altitude), factors itemized. FREE, no key. Pair with get_conditions for live wind.

  • get_conditions — LIVE weather at a course (temp/wind/precip, forecast-model, 15-min cache). FREE. Feeds plays_like.

  • link_dev_key — Confirm your OpenGolf ID on an EXISTING key. Sign in first; pass that access_token + the key.

  • list_dev_keys — List the keys owned by your OpenGolf ID (prefixes only). Needs access_token from complete_sign_in.

  • get_profile — A player's public OpenGolf ID card — name, avatar, links, prefs. Free.

  • update_profile — Edit a player's self-asserted profile fields (derived facts can't be set). Requires key (claimed players need their grant).

  • get_awards — A player's OpenAwards — derived trophies + course passport. Requires key.

  • set_beacon — Broadcast a consented, EXPIRING presence/availability beacon (present|available|open). Requires key.

  • find_beacons — Discover ACTIVE public beacons (find-my-group / matchmaking). Requires key.

  • record_consent — Record a player's consent grant (auditable, revocable). Requires key.

  • create_competition — Create a Competition (any OpenMatch format). Requires key.

  • list_competitions — List Competitions (free). Filter org/course/status.

  • get_competition — A Competition + live gross standings (free).

  • record_attempt — Record an Attempt (score or side-game value). Idempotent. Requires key.

  • finalize_competition — Finalize — run the kernel, store the gross Result. Requires key.

  • broadcast_feed — OpenBroadcast P1 — ONE typed feed for a session: broadcast-worthy items (score/side_game/money/award/condition) in ascending (recorded_at, seq) order, each with template narration (headline<=60/ticker<=80). Money appears only via settled records. Replaces stitching moments+results+live_state. Requires key + session access (participant or compute).

  • get_handicap — OpenIndex (beta) — a player's estimated handicap computed from real, notarized rounds (every score stamped when it happened; verifiable by anyone). Not official — provable. Reading your OWN is free with your key; player_id must be the ogid_… form.

  • get_showcase — A player's public showcase — the collectibles/records on their OpenGolf ID (og.* namespaces + course.*). Free, keyless: pass their ogid_. Tombstoned (revoked/expired) records hidden. The provable trophy wall.

  • verify_record — Verify a record/collectible against the OpenGolf Chain (a signed, hash-linked, Bitcoin-anchored transparency log). Returns the hash + whether it matches + the CLIENT-RECOMPUTE recipe (sha256 of the canonical record) + the anchor. Then you can go further, all keyless: pull a merkle inclusion proof (GET /chain/anchors/:id/inclusion?hash=), verify the checkpoint's RS256 signature against /.well-known/jwks.json, and resolve the Bitcoin (OpenTimestamps) anchor. Free. Trust no one — recompute the hash, check inclusion, resolve Bitcoin yourself.

  • list_webhooks — List your active webhook subscriptions. Requires key.

  • remove_webhook — Deactivate one of your webhook subscriptions by id (audit row kept). Requires key.

  • list_orgs — Public directory of verified orgs (free).

  • mint_asset — Mint an Asset (trophy/badge/stamp/coupon/membership) into the owner's trophy case + chain. Requires key.

  • file_claim — File a Claim in the trust ledger (ownership/attestation/identity/record/correction). Requires key.

  • list_claims — List Claims (free). Filter claimant/subject/status.

  • post_beta — Drop local course knowledge ("beta") on a hole — the AI-caddie's fuel. Requires key.

  • get_beta — Read local course knowledge for a course/hole (free).

  • get_my_chain — Export YOUR tamper-evident OpenGolf Chain + checkpoints. Requires key (own-read free).

  • verify_chain — Verify a Chain export OR walk the public transparency log (GET /chain/log?subject=), public + keyless — recompute the hash-links, verify each RS256 checkpoint signature against the JWKS, and resolve the Bitcoin anchors; reports tampering and where. The whole history (registry, per-course, master) is independently auditable — trust no one.

The bigger ecosystem — two front doors

Agents come through this MCP; sensors/devices come through OpenGolf Connect (one open connector streaming shots from any launch monitor — R10, MLM2PRO, Uneekor, SkyTrak, Foresight — into POST /v1/shots). Both write to the same open commons. → https://opengolfapi.org/connect

Learn more

MIT licensed. Course data ODbL. Shots CC0.

Attribution (required if you display or redistribute the data): Course data © OpenStreetMap contributors (ODbL 1.0) via OpenGolfAPI · Weather data by Open-Meteo.com (CC BY 4.0) · Descriptions from Wikipedia (CC BY-SA 4.0) · Contact + social from Foursquare / Overture (Apache 2.0). Full list: https://opengolfapi.org/attribution

Available Tools

6 tools
aboutA

Information about OpenGolfAPI: dataset size, license, how to contribute, how to contact the maintainers. Useful when an AI agent or user wants to know who built this and how to reach them.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A4.5/5.0
Behavior4/5

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

No annotations provided, but the description fully discloses its read-only informational nature, listing exactly what information is returned. No hidden behaviors or side effects.

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 purpose and utility. Every word adds value; 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?

Given zero parameters, no output schema, and a simple purpose, the description is fully complete. It tells what the tool does and when to invoke it.

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?

No parameters, so schema coverage is 100%. The description adds meaning by detailing the categories of information beyond the empty schema, such as dataset size and license.

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 it provides information about OpenGolfAPI, listing specific categories like dataset size, license, contribution, and contacts. This distinguishes it from siblings like get_climate or search_courses, which are data-oriented.

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?

Explicitly states when to use: when an AI agent or user wants to know who built this and how to reach them. No need for exclusions given the tool's simplicity.

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

get_climateB

Get monthly climate normals for a course (temperature, precipitation, playability). ODbL licensed.

ParametersJSON Schema
NameRequiredDescriptionDefault
course_idYesCourse UUID

TDQS

B3.3/5.0
Behavior2/5

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

No annotations are provided, so the description must carry behavioral transparency. It mentions the ODbL license but does not disclose important traits like whether the operation is read-only, error handling for invalid course_id, rate limits, or data freshness. This leaves significant ambiguity for the agent.

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 a single sentence plus a license note, with zero wasted words. It is appropriately sized for a simple tool with one parameter.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema, the description is minimal: it lists the data types but does not explain the format or units of 'monthly climate normals' or what 'playability' means. It is adequate but not fully complete for an agent to understand the expected return structure.

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% with a clear description for course_id ('Course UUID'). The description adds no further meaning beyond the schema, such as where to obtain the UUID or any constraints. Baseline score of 3 as schema already documents the parameter.

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 verb 'Get' and the resource 'monthly climate normals for a course', listing specific data fields (temperature, precipitation, playability). It distinguishes from sibling tools like get_course and get_nearby by focusing solely on climate data.

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

Usage Guidelines2/5

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

No guidance on when to use this tool versus alternatives like get_course for general course info or search_courses for finding courses. The description lacks any when-to-use or when-not-to-use hints.

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

get_courseA

Get detailed golf course info including full scorecard with par and handicap index per hole. ODbL licensed.

ParametersJSON Schema
NameRequiredDescriptionDefault
course_idYesCourse UUID from search results

TDQS

A4/5.0
Behavior4/5

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

No annotations are provided, so the description carries full burden. It correctly indicates a read operation ('Get') and discloses data licensing ('ODbL licensed'). However, it could be more explicit about being read-only, having no side effects, or requiring authentication, but the current level is sufficient.

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 sentence that is immediately informative, front-loaded with purpose, and contains no filler. Every word 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 one parameter and no output schema, the description adequately covers what is returned (scorecard info). It could mention that the result includes additional details like course name and location, but as stated it provides enough context for an agent.

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% with one parameter described as 'Course UUID from search results'. The description adds 'from search results' which is useful context, but does not significantly add beyond the schema. Baseline 3 is appropriate.

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 verb 'Get', the resource 'detailed golf course info', and specifics 'full scorecard with par and handicap index per hole'. It distinguishes from sibling tools like search_courses (which is for finding courses) and get_tees (which is for tee info).

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 description does not explicitly state when to use this tool versus alternatives. The required parameter course_id implies you need a specific course UUID, but there is no guidance like 'use after search_courses' or 'use for retrieving a full course profile'.

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

get_nearbyA

Get nearby points of interest for a course (hotels, restaurants, airports) within ~20 miles. ODbL licensed.

ParametersJSON Schema
NameRequiredDescriptionDefault
course_idYesCourse UUID

TDQS

A3.8/5.0
Behavior3/5

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

Without annotations, the description adds some behavioral context like the approximate radius (20 miles) and ODbL license, but does not disclose error handling, data source details, or performance characteristics.

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 clear sentences, no unnecessary words, front-loaded with purpose. Highly efficient.

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 simple 1-parameter tool with no output schema, the description covers purpose, types of results, radius, and license. Slight gap in not specifying the data origin (implied by ODbL).

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?

The only parameter course_id is described in schema as 'Course UUID'. The description adds no extra meaning beyond scope (course). With 100% schema coverage, baseline 3 is appropriate.

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 gets nearby points of interest (hotels, restaurants, airports) for a course within a ~20 mile radius. This differentiates it from sibling tools like get_course or search_courses.

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 description implies usage when needing nearby POIs for a course, but does not explicitly state when to use or when not to use, nor does it mention alternatives.

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

get_teesA

Get all tee sets for a course including ratings, slopes, and yardages per tee. ODbL licensed.

ParametersJSON Schema
NameRequiredDescriptionDefault
course_idYesCourse UUID

TDQS

A3.9/5.0
Behavior3/5

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

With no annotations provided, the description carries the burden of behavioral disclosure. It correctly identifies the tool as a read operation ('Get') and mentions the ODbL license. However, it does not specify error behavior (e.g., invalid course_id) or any constraints beyond licensing.

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 two sentences long, front-loaded with the core purpose, and contains no fluff. Every sentence adds value: purpose and data fields, plus licensing notice.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (one parameter, no output schema, no annotations), the description is adequate but lacks details about return format (e.g., array of tee objects) and error handling. For a tool with no output schema, more insight into response structure would be beneficial.

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?

The input schema covers 100% of the single parameter with a description ('Course UUID'). The tool description adds context by tying the parameter to the course, but does not enhance semantics beyond what the schema already provides. Baseline score of 3 applies.

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 verb 'Get' and specifies the resource 'all tee sets for a course' with explicit details on included fields (ratings, slopes, yardages). It distinguishes itself from sibling tools like get_course which likely returns course-level info.

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?

The description implicitly indicates usage for retrieving tee set data given a course ID. No explicit alternatives or when-not-to-use are given, but the purpose is straightforward and unambiguous.

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

search_coursesA

Search golf courses by name, state, or location. Returns full course info. ODbL licensed data from OpenGolfAPI.

ParametersJSON Schema
NameRequiredDescriptionDefault
latNoLatitude for geo search
lngNoLongitude for geo search
radius_miNoSearch radius in miles
queryNoCourse name search
stateNo2-letter US state code
limitNoMax results

TDQS

A3.8/5.0
Behavior3/5

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

No annotations are provided, so the description carries the full burden. It adds context about ODbL licensing and returning full course info, but does not disclose pagination, rate limits, or other behavioral traits beyond the basic purpose.

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 action, resource, and criteria. No wasted words.

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 search tool with 6 optional parameters and no output schema, the description adequately states the purpose and return type. It could mention result count or format, but 'full course info' is sufficient.

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?

Input schema coverage is 100%, so the description does not need to add parameter details. It mentions name, state, and location, which align with query, state, and lat/lng, but adds no new semantic value 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 verb 'Search', the resource 'golf courses', and the search criteria: name, state, or location. It also mentions the data source and licensing, and distinguishes from siblings like get_course and get_nearby.

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 description implies usage for searching courses but does not explicitly state when to use this tool versus alternatives, nor does it provide when-not or exclusions.

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

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

TDQS

A3.9/5.0
Disambiguation5/5

Each tool has a distinct purpose: about for metadata, get_climate for weather, get_course for details, get_nearby for POIs, get_tees for tee sets, and search_courses for searching. No overlap or ambiguity.

Naming Consistency4/5

Most tools follow a consistent 'get_' prefix for data retrieval (get_climate, get_course, get_nearby, get_tees), along with search_courses and about. While about deviates, it is a common convention for info commands, so only minor inconsistency.

Tool Count5/5

Six tools is well-scoped for a golf course data API. Each tool covers a key aspect (search, course info, tee sets, climate, POIs, metadata) without being overwhelming or insufficient.

Completeness4/5

The set covers the main data retrieval operations for golf courses: search, details, tees, climate, and nearby points. Minor gaps like course reviews or booking are absent, but the core domain is well-served.

Maintenance

ActivityActive
ResponsivenessNo issues

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

  • Golf v2 MCP Server

    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.
    -

  • Jinko Hotel Booking MCP Server

    dumyCq
    A
    license
    A
    quality
    D
    maintenance
    Enables AI agents to search, browse, and book hotels from a database of 2 million properties worldwide. Provides comprehensive hotel search capabilities with location lookup, filtering by amenities, detailed property information, and integrated booking functionality.
    6
    22
    1
    ISC

  • Google Maps MCP Server

    iceener
    F
    license
    Not graded
    quality
    C
    maintenance
    Enables location-aware AI agents to search for nearby places, get detailed place information including hours and ratings, and calculate routes with turn-by-turn directions using Google Maps APIs.
    22
    -

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/opengolfapi/mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server