caddie-mcp

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.1
Disambiguation4/5
Most tools have clearly distinct purposes, but get_round and get_shots both involve shot data, and query_golf_data could potentially retrieve anything. The descriptions do a good job of clarifying boundaries, so ambiguity is minimal.
Naming Consistency4/5
Almost all tools follow the verb_noun pattern (get_*, sync_*, correlate_*, query_*), except garmin_status which is a noun phrase. This minor deviation is easily understood and does not undermine predictability.
Tool Count5/5
With 13 tools, the server is well-scoped for a golf analytics platform. Each tool covers a distinct aspect of data ingestion, retrieval, analysis, and querying, without unnecessary bloat or thin coverage.
Completeness5/5
The tool set provides comprehensive coverage of the golf performance domain: syncing data, listing and inspecting rounds, shot-level details, stats (club, strokes gained, overall), handicap, course intelligence, health context, correlation analysis, and a general SQL query interface. No obvious dead ends or missing core operations.
Average 4.3/5 across 13 of 13 tools scored. Lowest: 3.5/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 3 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

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 thoroughly describes the output metrics and mentions the optional benchmark_handicap, but does not disclose potential edge cases (e.g., behavior when insufficient rounds exist) or explicitly confirm it is a read-only operation, which is implied but not stated.
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 dense but avoids extraneous words, fitting a wealth of metric detail into two sentences. The structure is slightly run-on with a long list, but every clause contributes meaning and it is appropriately sized for the tool's complexity.
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?
Given the output schema exists and covers return structure, the description focuses on metric scope and is quite complete. The main gap is the missing explanation of the category parameter, but the metric list maps naturally to the enum values, making the tool usable without explicit parameter documentation.
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 0%, so the description must compensate. It explains benchmark_handicap explicitly and last_n_rounds via 'last N rounds', but category is only indirectly implied through the metric list and is not directly described. Partial compensation, with a notable gap for the category parameter.
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 clearly states the tool provides PGA-style performance stats over a specified number of rounds, with a detailed enumeration of metrics. This distinguishes it from siblings like get_club_stats (per-club data) or get_strokes_gained (single metric), though the distinction is implied rather than explicitly stated.
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 comprehensive performance analysis and offers an optional benchmark comparison, but it does not explicitly state when to prefer this tool over alternatives like get_club_stats or get_strokes_gained. No exclusions or when-not-to-use guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral transparency. It discloses a key nuance: 'estimated_share > 0 means some shots lacked GPS and used inferred lies/distances — hedge conclusions accordingly,' which is valuable for interpreting results. It also explains how the 'auto' baseline leverages the player's handicap. However, it does not explicitly state read-only behavior or other safety aspects, though that is less critical for a get operation.
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, front-loaded with the tool's purpose and output breakdown. It packs essential details about baseline selection and the estimated_share caveat without redundancy. Every clause adds value, and the structure is clear: purpose → baseline options → data quality warning.
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 output schema exists, return values are likely covered there. The description covers the metric breakdown, baseline semantics, and a data quality warning. However, it leaves unclear how 'round_id' and 'last_n_rounds' interact (e.g., precedence) and what the default behavior is when neither is provided. This ambiguity reduces completeness for an agent needing to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, leaving the description to compensate. It thoroughly explains the 'baseline' parameter, listing all allowed values and meanings. However, it does not explain 'round_id' or 'last_n_rounds' — their semantics, defaults, and interaction (e.g., priority when both are provided) remain ambiguous. This gap is significant given the low schema coverage.
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 opens with 'Strokes Gained (Broadie method) per round: total plus off-tee / approach / short-game / putting,' which clearly states the tool's purpose and output breakdown. It differentiates itself from sibling tools like get_club_stats or get_performance_stats by focusing specifically on strokes gained metrics.
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 strokes gained analysis but does not explicitly state when to use this tool over alternatives such as get_round or get_shots. It explains baseline options and the estimated_share caveat, but lacks direct when/when-not guidance or mention of alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral transparency. It discloses what the tool checks (auth state, last sync, cached data coverage), but does not explicitly state whether the operation is read-only, has side effects, or what happens on failure. The phrase 'check' implies non-destructive, but this is not explicitly stated.
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, immediately front-loaded with the core action ('Check connector health'), followed by specifics. Every word adds value; the directive 'Call this first in a session' is pragmatic and concise. No filler or repetition.
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?
The description is complete enough for a zero-parameter status tool. It enumerates what is covered and gives session-level usage context. An output schema exists, so return values are handled by the schema. The only minor gap is that it doesn't mention if any state changes occur, but given the output schema and simple nature, this is adequate.
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?
The tool has zero parameters, so the input schema already conveys all parameter information. The description adds value by explaining the scope of the status check (rounds, shots, GPS %, club %), which is not directly in the schema. No parameter documentation is needed, and the baseline of 4 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's purpose: checking connector health including Garmin auth state, last sync, and cached data coverage. It distinguishes itself from sibling tools like sync_garmin_data (which performs syncing) and data retrieval tools by focusing on health and session-first usage.
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 explicitly says to call this tool first in a session, providing clear contextual guidance. It does not mention exclusions or alternatives, but the timing instruction is a strong usage guideline that differentiates this tool from its siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/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 discloses notable behavior: name substring match for course selection, and the specific stats returned. While it doesn't mention read-only nature or data freshness, it's clear this is an analysis/query tool. The description adds value beyond what annotations would 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 two sentences, front-loaded with the main purpose and immediately providing concrete details and a usage example. Every word earns its place, with zero fluff or repetition.
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?
The tool has an output schema, so return values are presumably documented elsewhere. The description covers the key behavioral aspects: scope, matching, and intended use case. It could mention prerequisites like having synced data, but this is not a critical omission given the tool's simplicity and sibling context.
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 0%, so the description must compensate. It clarifies that 'course' uses name substring matching, adding meaning to that parameter. However, 'last_n_rounds' is not mentioned, though its purpose is fairly inferable from its name and default value. The compensation is partial, so a 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 provides 'personal course intelligence for one course' with specific outputs (scoring average vs par, hardest/easiest holes, tee club per hole, round history). It distinguishes itself from sibling tools like get_club_stats and get_performance_stats by focusing on per-course analysis. The verb 'get' and resource 'course intel' 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives an explicit example of when to use it: 'Use for strategy questions like "how should I play X next time?"' This provides clear context. However, it does not explicitly mention alternatives or when not to use it, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It explains filtering options and the geojson output format, but does not mention default limit (500), read-only nature, or behavior when no filters are applied. The 'get' verb implies safety but not explicitly.
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: the first defines the core purpose and filters, the second explains the geojson output and use case. Every sentence adds value, with no redundancy or fluff.
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?
Given the tool's complexity (6 optional params) and presence of an output schema, the description sufficiently covers purpose, filters, and output format. It misses a few behavioral details like limit defaults and explicit differentiation from siblings, but is adequate for most use cases.
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 0%, so the description must compensate. It explains round_id, holes, club (substring match), shot_type (with allowed values), and format (geojson meaning). However, limit is only visible in schema, and no defaults or optionality are mentioned, leaving a small gap.
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 opens with 'Get shot-level data' and enumerates specific data fields (GPS, club, lie, distance, miss offsets), clearly distinguishing it from sibling tools like get_round or get_club_stats. The filterable dimensions are also listed, making the tool's scope unmistakable.
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 provides context for when to use the tool ('ideal for shot maps and dashboards') and implies use for granular shot analysis. However, it does not explicitly mention alternatives or when not to use it, which is a minor gap given the sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It explicitly states that NULL fields mean the watch didn't record and instructs the agent not to guess. It also reveals the round summary behavior. It doesn't explicitly mention read-only, but that is implied by the context.
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?
Three sentences, each earning its place. The purpose is front-loaded, the metric list is compact, and the NULL handling instruction is actionable. No filler or repetition of schema details.
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?
Given only 2 optional params and an output schema, the description covers key functionality, round_id special case, and data-missing handling. A small gap is the exact interaction of date and round_id together, but overall it is sufficiently complete for a read-only health data 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 0%, so the description must compensate. It explains the date format (YYYY-MM-DD) and the effect of round_id (adds round summary). It does not clarify behavior when both parameters are provided, but the core usage is clear.
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 retrieves health context for a round or date, listing all specific metrics (sleep, HRV, Body Battery, etc.). This distinguishes it from sibling tools like garmin_status or sync_garmin_data by focusing on round/date correlation and concrete health data.
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 implies usage: use with a date or a round_id to get health context. It clarifies that round_id also returns round summary, giving a hint about when to choose it over date. However, it does not explicitly mention alternatives or exclusion conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden for behavioral disclosure. It describes the return content and optionality of shots, but does not explicitly state read-only semantics, potential performance implications of include_shots, or any side effects. It adds some context but leaves room for more transparency.
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 concise and front-loaded: the first sentence gives the core purpose and content, the second provides usage guidance and sibling differentiation. Every sentence earns its place with 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?
With an output schema present, return value details are covered. The description adequately covers the tool's scope, input source, and optional behavior of shots. It does not explain include_holes, but that is relatively self-explanatory given the schema and the context. Slightly more detail on what 'header' contains could improve completeness, but it's sufficient for a moderate-complexity 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 0%, so the description must compensate. It meaningfully explains round_id (from list_rounds) and clarifies include_shots ('optionally every shot'). However, it does not mention include_holes beyond the schema's default, so it's slightly incomplete. Overall, it adds value beyond the schema for the most important parameters.
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 what the tool does: 'Get one round in depth' with specific return content (header, hole-by-hole scorecard, optionally every shot). It also distinguishes itself from sibling get_shots by noting when to prefer that tool for shot analysis/mapping.
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?
Explicit usage guidance is provided: round_id comes from list_rounds, and the description explicitly recommends using get_shots instead when the goal is shot analysis or mapping. This clearly delineates when to use this tool versus the alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of disclosing behavior. It specifies newest-first ordering, compact summary fields, date format (YYYY-MM-DD), and case-insensitive substring matching for course. It does not mention limit behavior or pagination, but the output schema likely covers return structure.
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 three short, informative sentences. The first sentence gives the core action and output format, the second clarifies parameter conventions, and the third points to an alternative tool. No filler or repetition exists.
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?
The description covers the core list behavior, output format, and key matching rules, and explicitly points to get_round for detailed data. With an output schema present, return values are covered. It could explicitly state that start_date and end_date filter rounds, but overall it is sufficient for safe 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?
The input schema has no property descriptions (0% coverage), so the description's added meaning is valuable: course is a case-insensitive substring, and dates use YYYY-MM-DD. However, it does not explain how start_date and end_date filter results, nor what limit does, leaving some parameters under-specified.
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 action ('List'), resource ('golf rounds'), and scope ('newest first, as compact summaries'), and lists the fields included. It also distinguishes itself from the sibling get_round tool by explicitly noting that get_round provides hole-by-hole detail.
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 explicitly directs users to get_round for hole-by-hole detail, signaling when not to use this tool. It also sets expectations for date format and course matching, providing clear context for when to use this list versus other golf analytics tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does well: it discloses that putts and penalties are excluded, details the metrics (avg/min/max/stddev, sample size, usage share, lateral miss bias from dx offsets), and mentions Garmin's own averages and advice distances. It stops short of stating side effects, but this is clearly a read-only statistics tool.
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, dense sentence that front-loads the core purpose and then efficiently lists the included metrics and caveats. Every clause adds value, with zero fluff or repetition.
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, the description need not detail return values. It thoroughly covers the tool's scope, data sources, and exclusions, making it complete for an agent to invoke correctly.
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?
The schema only defines last_n_rounds with a default, and the description enriches this by explaining 'over the last N rounds,' making the parameter's meaning clear. It doesn't specify the exact parameter name, but the correspondence is obvious.
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's purpose: 'Per-club performance over the last N rounds' with a detailed list of metrics. It is specific about the resource (club performance) and the action (getting stats), and it distinguishes itself from sibling tools like get_performance_stats or get_shots by focusing on club-level aggregates.
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 implies clear usage context: when you need per-club aggregate statistics over a rolling number of rounds. It does not explicitly name alternatives or exclusions, but the context is unambiguous enough for an agent to select this tool over siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It adds valuable context beyond the schema by explaining the calculation method (best-N-of-20), the data requirements, and that the output includes both which rounds count and trend over time. This is a read-only operation and the description gives sufficient transparency about prerequisites and what the tool computes.
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 extremely concise, consisting of two sentences with no redundant information. The first sentence front-loads the core purpose and output, and the second sentence adds a crucial prerequisite. Every word earns its place, making it highly scannable for an AI agent.
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 tool has no parameters and an output schema exists (so return values need not be described), the description covers all essential context: what the handicap index is, how it is calculated, the data needed, and that a trend is provided. It is complete enough for an agent to select and invoke the tool correctly, especially since there are no arguments to configure.
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?
The tool has zero parameters, so the baseline for this dimension is 4 as per the rubric. The description does not need to clarify parameter semantics because there are none. It instead focuses on the output and prerequisites, which 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 this tool provides a WHS-style Handicap Index, detailing that it includes best-N-of-20 differentials, which rounds count, and index trend. This distinguishes it from sibling tools like get_club_stats or get_strokes_gained, which focus on other metrics. The resource (handicap index) and the specific outputs are unambiguous.
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 provides clear context about the prerequisite data: rounds with tee rating and slope, and notes that Garmin records these when a tee box is selected. This implicitly tells the user when this tool is usable but does not explicitly mention alternatives or when not to use it, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses read-only behavior, dialect, statement restrictions, and row limit. It also guides toward aggregation, which is a useful behavioral hint. It stops short of describing error handling or permissions, but the key operational traits are well covered.
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 four sentences, front-loaded with the core purpose, then adding necessary constraints. No filler or repetition. Every sentence earns its place.
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 tool has an output schema and only one parameter, the description covers tables, dialect, statement type, row cap, and points to the data dictionary for detail. It fully enables correct use without needing more context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only defines 'sql' as a string with no description, so schema coverage is 0%. The description fully compensates by explaining what the SQL should contain: a single SELECT/WITH statement in DuckDB dialect, with links to table names and data dictionary. This gives the parameter clear semantic meaning beyond the bare 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 states a specific action: 'Run a read-only SQL SELECT over the golf database' with the DuckDB dialect. It lists target tables and clearly differentiates from sibling tools like get_round or get_shots by identifying itself as a generic SQL query interface.
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 provides clear usage constraints: single statement, SELECT/WITH only, 200-row cap, and a recommendation to aggregate server-side. It also points to the data-dictionary for schema details. It doesn't explicitly name sibling alternatives, but the context makes it clear this is for ad-hoc queries beyond the specialized getters.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden and does well: it discloses that the tool returns a paired table, r, and an interpretation, and that small samples are flagged loudly. It also clarifies the timing of metrics (night/day vs during round), which is a key behavioral trait for correct interpretation.
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 relatively long but every sentence adds value: purpose, method, metric timing, output, and interpretation. It is well-structured and front-loaded, though it could be slightly more compact without losing information.
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 that an output schema exists, the description does not need to detail return fields. It covers the purpose, parameter semantics, output shape, and important caveats (small samples, correlation sign), making it complete for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description must compensate. It does so by explicitly categorizing health_metric options into daily vs round-window metrics and explaining the lower-is-better sign interpretation for score/putts. This adds crucial meaning beyond the enum arrays.
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 computes a Pearson correlation between health/conditions and performance for each round. It distinguishes itself from sibling tools like get_health_context or get_performance_stats by focusing on the relationship between the two, not just returning raw data.
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?
It provides clear context ('Does recovery affect your golf?') and explains the distinction between daily and round-window metrics, which helps the agent decide when to use this tool. However, it does not explicitly name alternative tools or state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Even without annotations, the description fully discloses behavior: it is incremental and chunked, each call syncs up to max_rounds (default 25, ~2-4 minutes), reports rounds_remaining, and guarantees permanence ('Nothing is lost between calls; every batch is permanent'). It also explains the unbounded nature of full=True without max_rounds and the skip behavior of include_health=False, covering side effects and performance.
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 moderately long but every sentence earns its place. It front-loads the main purpose, then logically covers incremental behavior, progress loop, permanence, full mode, and an alternative execution path. No filler or repetition, and technical details are compactly parenthesized.
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 tool's complexity (sync with chunking, progress tracking, multiple modes) and the presence of an output schema (so return structure is covered), the description fully equips an agent to use the tool correctly across scenarios. It even addresses the batching loop and provides an out-of-band alternative, leaving no critical gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema description coverage, the description adds rich semantics for all three parameters. full is explained as 'refetches already-cached rounds (least-recently-synced first)', max_rounds bounds the run and defaults to 25, and include_health controls the health pass. This goes beyond the schema's bare types and defaults, giving actionable meaning.
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 opens with a specific action: 'Pull golf data from Garmin Connect into the local cache, plus daily health...' This clearly identifies the resource (Garmin Connect data), the mechanism (sync to local cache), and the scope (golf rounds + health metrics). It distinguishes itself from siblings like list_rounds or get_round, which operate on already-cached data, by emphasizing the fetch-and-store behavior.
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?
Provides explicit operational guidance: for full history, 'keep calling this tool until rounds_remaining is 0' with progress updates, and for very large backfills, recommends using `caddie-mcp sync` in a terminal. It also explains when to use include_health=False and full=True, giving clear context on how the tool should be invoked for different scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![caddie-mcp MCP server](https://glama.ai/mcp/servers/mbrionesalvarez/caddie-mcp/badges/card.svg)](https://glama.ai/mcp/servers/mbrionesalvarez/caddie-mcp)

Score Badge

Copy to your README.md:

[![caddie-mcp MCP server](https://glama.ai/mcp/servers/mbrionesalvarez/caddie-mcp/badges/score.svg)](https://glama.ai/mcp/servers/mbrionesalvarez/caddie-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/mbrionesalvarez/caddie-mcp'

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