Skip to main content
Glama
Sign In
golf-coach

golf-coach

by bjornj12
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

setup

Read-onlyIdempotent

Get all onboarding materials to configure the Trackman golf coach: system prompt, upload-ready skills, and step-by-step client instructions.

Instructions

One-call onboarding for the Trackman golf coach.

Returns everything needed to set the coach up in your client:

  • system_prompt: paste into a Claude/ChatGPT Project's custom instructions so every chat in it is the coach (with this MCP connected);

  • skills: upload-ready SKILL.md files (Settings → Capabilities → Skills) for always-on auto-activation;

  • instructions: per-client steps (Claude Projects, Desktop Skills, ChatGPT, Claude Code).

An MCP server can't create the Project or enable Skills itself — this hands you the content + steps. In Claude Code, the assistant can write the files for you directly from this kit. (Pairs with the setup prompt.)

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "setup"
  }
}

Input Schema

NameRequiredDescriptionDefault

No arguments

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.7.0

TDQS

A4.5/5.0
Behavior4/5

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

Beyond the annotations (readOnlyHint, idempotentHint), the description discloses that the tool only returns content and cannot perform external actions like creating Projects. This explains the tool's non-mutating behavior and its limitation, which is valuable context not fully captured by annotations alone.

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 well-structured with a concise opening sentence, a bulleted list of return items, and a short paragraph on limitations. Each sentence serves a purpose—no fluff or redundancy—and the most important information is front-loaded.

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, a detailed output schema, and annotations covering safety, the description fully explains what the tool does, what it returns, and its limitations. It leaves no ambiguity about the tool's role in the overall setup workflow, making it contextually complete.

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 schema coverage is trivially 100%. Per the rubric, a baseline of 4 applies for 0-param tools. The description does not need to explain paramet semantics, but it does clarify the returned object structure, which adds useful context.

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 'One-call onboarding for the Trackman golf coach,' which clearly states a specific verb (onboarding) and resource (coach setup). It enumerates concrete outputs (system_prompt, skills, instructions) and thus distinguishes itself from sibling tools like auth or session_analysis by its setup-focused role.

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 explains that the tool returns setup content and explicitly states an MCP server cannot create Projects or enable Skills itself, which clarifies when to use this tool (to get setup material) versus doing manual setup separately. It also notes the alternative of using Claude Code to directly write files, providing contextual usage guidance without explicit exclusions.

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

Deploy Server

Other Tools