Skip to main content
Glama
ztuskes

Garmin Documentation MCP Server

by ztuskes
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Garmin Documentation MCP Server

An MCP (Model Context Protocol) server that provides comprehensive offline access to the complete Garmin Connect IQ SDK 8.2.3 documentation ecosystem for AI assistants like Claude.

Features

🚀 Fully Offline: Works with local documentation - no internet required!
📚 Complete Documentation: Access to API docs, programming guides, device reference, FAQ, and visual resources (1,407+ files)
🔍 Enhanced Search: Deep semantic search with fuzzy matching and cross-reference support
⚡ Fast: Local parsing and indexing for instant responses
🎯 Accurate Versioning: Proper API Level to SDK version mapping (fixes common confusion)
📱 Device-Specific Info: Hardware capabilities, memory limits, round device support
📖 Programming Guides: Getting started tutorials, debugging, testing, and best practices
❓ FAQ & Troubleshooting: Common issues with fonts, memory, graphics, and more

Related MCP server: AppCan Helper MCP Server

v1.0.1 New Features

✨ Fixed API Level Confusion: Now correctly shows API Level 4.2.0 (≈ SDK 6.x+) instead of misleading version info
✨ Fixed Module Functions: Critical bug fix - now properly finds all module-level functions (Math.stdev, Cryptography.createPublicKey, etc.)
✨ 3 New Tools: Device reference search, programming guides, and FAQ search
✨ Enhanced Coverage: Now indexes programming guides, device docs, FAQ resources, and personality library
✨ Better Search Results: Includes guide content in main search with comprehensive cross-references

The server provides the following tools:

Core API Tools

  • search_garmin_docs: Enhanced search across modules, classes, methods, properties, constants, and guides

  • get_module_details: Complete module information with corrected version mapping

  • get_class_details: Detailed class information with proper SDK version context

  • list_modules: Comprehensive listing of all SDK 8.2.3 modules with statistics

  • get_api_examples: Code examples with SDK version-specific syntax

New Documentation Tools

  • search_device_reference: Search device-specific capabilities, memory limits, and hardware features

  • get_programming_guide: Access getting started guides, tutorials, and development best practices

  • search_faq: Find troubleshooting info for common issues (fonts, memory, graphics, etc.)

Installation

  1. Clone or download this repository

  2. Copy the Garmin Connect IQ SDK 8.2.3 documentation to a docs/ folder in the project root

  3. Install dependencies:

npm install

  1. Build the project:

npm run build

Note: On first run, the server will automatically parse and index all documentation files. This may take a few seconds initially but subsequent runs will be instant.

Usage

Running the Server

For development:

npm run dev

For production:

npm start

Configuration for Claude Code (Recommended)

Add the MCP server using the Claude Code CLI:

# Add the server (run from any directory)
claude mcp add garmin-documentation /path/to/garmin-documentation-mcp-server/dist/index.js

# Or add at project scope for team collaboration
claude mcp add --scope project garmin-documentation /path/to/garmin-documentation-mcp-server/dist/index.js

Verify installation:

claude mcp list

Configuration for Claude Desktop

Add this server to your Claude Desktop configuration file:

On macOS: ~/Library/Application Support/Claude/claude_desktop_config.json On Windows: %APPDATA%\\Claude\\claude_desktop_config.json

{
  "mcpServers": {
    "garmin-documentation": {
      "command": "node",
      "args": ["/path/to/garmin-documentation-mcp-server/dist/index.js"]
    }
  }
}

Replace /path/to/garmin-documentation-mcp-server with the actual path to your installation.

Available Tools

Core API Tools

search_garmin_docs

Enhanced search across the entire Garmin Connect IQ documentation ecosystem.

Parameters:

  • query (required): Search term

  • category (optional): Filter by type ("module", "class", "function", or "all")

New in v1.0.1: Now includes programming guides, device docs, and FAQ in search results with proper API Level to SDK version mapping.

get_module_details

Get detailed information about a specific module with corrected version information.

Parameters:

  • module_name (required): Name of the module (e.g., "System", "Activity", "WatchUi")

Improvement: Shows API Level 4.2.0 (≈ SDK 6.x+) instead of confusing raw API levels.

get_class_details

Get detailed information about a specific class with proper SDK version context.

Parameters:

  • class_name (required): Name of the class

  • module_name (optional): Module containing the class

list_modules

List all available Garmin Connect IQ modules with descriptions and statistics.

get_api_examples

Get code examples for specific functionality with SDK version-specific syntax.

Parameters:

  • topic (required): Topic for examples (e.g., "activity monitoring", "bluetooth", "watchface")

New Documentation Tools (v1.0.1)

search_device_reference

Search device-specific reference documentation and hardware capabilities.

Parameters:

  • query (required): Search term for device capabilities, memory limits, or hardware features

  • device_type (optional): Device type filter (e.g., "watch", "bike", "golf")

Use Cases: Find memory limits, round device support, hardware-specific features.

get_programming_guide

Access programming guides and tutorials for Connect IQ development.

Parameters:

  • topic (required): Programming topic (e.g., "getting started", "app types", "debugging", "testing")

Coverage: Getting started guides, app development tutorials, compiler documentation, debugging tips.

search_faq

Search frequently asked questions and troubleshooting information.

Parameters:

  • query (required): Search term for FAQ or troubleshooting topics

Topics Include: Font rendering, memory management, graphics optimization, music control, map integration, and more.

Example Usage with Claude

Once configured, you can ask Claude questions like:

Core API Questions

  • "Search for bluetooth functionality in Garmin Connect IQ"

  • "Show me details about the System module"

  • "Get examples for creating a watch face"

  • "What classes are available in the Activity module?"

  • "List all available modules"

  • "Find methods related to heart rate monitoring"

New v1.0.1 Capabilities

  • "Are complications available in SDK 7?" ✅ Now answers correctly with proper version mapping

  • "How do I use stdev function?" ✅ Now finds Math.stdev with complete examples

  • "Show me createPublicKey usage" ✅ Now finds Cryptography.createPublicKey with examples

  • "How do I get started with Connect IQ development?"

  • "What are the memory limits for different Garmin devices?"

  • "How do I support round devices in my app?"

  • "What's the difference between API Level and SDK version?"

  • "How do I troubleshoot font rendering issues?"

  • "Find device reference for watch memory capabilities"

Management Commands (Claude Code)

# List all configured MCP servers
claude mcp list

# Get details about the server
claude mcp get garmin-documentation

# Remove the server
claude mcp remove garmin-documentation

Documentation Coverage

API Modules (33 modules, 282 classes, 27+ module functions)

The server provides access to all major Garmin Connect IQ modules including:

  • Activity: Activity recording and monitoring

  • ActivityMonitor: Daily activity metrics

  • ANT: ANT wireless communication

  • Application: App framework and lifecycle

  • BluetoothLowEnergy: BLE communication

  • Complications: Watch face complications (✅ Available in SDK 6.x+, not 4.2+ as previously confusing)

  • Cryptography: Encryption, key generation, createPublicKey(), randomBytes()

  • Graphics: Drawing and rendering, createBufferedBitmap(), createColor()

  • Math: Statistical functions like stdev(), mean(), variance(), plus trigonometric functions

  • Position: GPS and location services

  • Sensor: Device sensor access

  • System: Core system functions (including round device detection)

  • WatchUi: User interface components

  • And 20 more modules...

Additional Resources (1,407+ files total)

  • Programming Guides: Getting started tutorials, app types, debugging, compiler documentation

  • Device Reference: Hardware specifications, memory limits, capabilities for all supported devices

  • FAQ Resources: Troubleshooting guides for fonts, graphics, memory, music, maps, and common issues

  • Personality Library: UI patterns, iconography, colors, confirmations for consistent app design

  • UX Guidelines: User experience best practices and design patterns

Version Accuracy

✅ Fixed Major Issue: API Level confusion resolved
✅ Proper Mapping: API Level 4.2.0 correctly mapped to ≈ SDK 6.x+
✅ SDK 7 Support Confirmed: Complications, Activity info, round devices all properly supported

License

MIT

Available Tools

8 tools
get_api_examplesB

Get code examples for specific Garmin Connect IQ functionality

ParametersJSON Schema
NameRequiredDescriptionDefault
topicYesTopic to get examples for (e.g., "activity monitoring", "bluetooth", "watchface")

TDQS

B3.1/5.0
Behavior2/5

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

With no annotations provided, the description carries full burden for behavioral disclosure, but it only states the read operation ('Get'). It does not mention response format, limitations, authentication needs, or scope of examples, which are essential for safe invocation.

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 a single sentence that efficiently conveys the core purpose. It is front-loaded with the action and resource, with no wasted words, though it sacrifices completeness for brevity.

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

Completeness2/5

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

The description is minimal for a tool with no output schema and no annotations. It lacks information about the return format, example quantity, or how to specify topics beyond the vague schema example, leaving the agent underinformed.

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 the sole parameter 'topic' with a description, achieving 100% coverage. The description adds no extra meaning beyond the schema, so it meets the baseline but does not improve it.

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 code examples for Garmin Connect IQ functionality. It uses a specific verb ('Get') and resource ('code examples'), and distinguishes from sibling tools like 'get_class_details' or 'search_garmin_docs' which serve different purposes.

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 is given on when to use this tool versus alternatives. The description does not mention any context, prerequisites, or exclusions, leaving the agent to infer usage solely from the name and sibling tool list.

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

get_class_detailsB

Get detailed information about a specific class in the Garmin Connect IQ API

ParametersJSON Schema
NameRequiredDescriptionDefault
class_nameYesName of the class
module_nameNoModule containing the class (optional)

TDQS

B3.4/5.0
Behavior2/5

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

With no annotations, the description must disclose behavior, but it only vaguely mentions 'detailed information' without specifying what is included (e.g., methods, properties) or any edge cases (e.g., missing class, error handling).

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 a single clear sentence with no redundancy, making it concise and front-loaded.

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?

For a simple tool with 2 parameters and no output schema, the description is minimally adequate, but lacks details on return value structure or error conditions, which would improve completeness.

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 already describes both parameters (class_name, module_name) with 100% coverage, so the description adds no meaningful semantic value beyond repeating the purpose.

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 information about a specific class', and the domain 'Garmin Connect IQ API', distinguishing it from siblings like get_module_details which focuses on modules.

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 class details are needed, but does not provide explicit when-to-use or when-not-to-use guidance, nor does it compare with sibling tools like get_api_examples or list_modules.

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

get_module_detailsB

Get detailed information about a specific Garmin Connect IQ module

ParametersJSON Schema
NameRequiredDescriptionDefault
module_nameYesName of the module (e.g., "System", "Activity", "WatchUi")

TDQS

B3.2/5.0
Behavior2/5

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

With no annotations, the description must disclose behavioral traits. It only states the tool 'gets detailed information' but omits any side effects, authentication needs, rate limits, or what 'detailed' means. This is insufficient for a read operation without annotation support.

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, concise sentence that front-loads the core action. Every word is necessary and there is no redundant information.

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

Completeness2/5

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

Given the simple parameter set and lack of output schema or annotations, the description is too minimal. It does not explain what 'detailed information' includes, expected output format, or any usage caveats, leaving the agent underinformed.

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 one parameter with a clear description and example. The tool description adds no additional semantic value beyond what the schema already provides, meeting the baseline.

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 detailed information about a specific Garmin Connect IQ module, using a verb and resource format. It distinguishes from sibling tools like 'list_modules' (which lists all modules) and 'get_class_details' (which focuses on classes).

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 is provided on when to use this tool versus alternatives (e.g., 'list_modules' or 'search_garmin_docs'). The description lacks explicit context about when it's appropriate or when to choose another tool.

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

get_programming_guideC

Get programming guides and tutorials for Connect IQ development

ParametersJSON Schema
NameRequiredDescriptionDefault
topicYesProgramming topic (e.g., "getting started", "app types", "debugging", "testing")

TDQS

C2.9/5.0
Behavior2/5

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

No annotations are present, and the description does not disclose behavioral traits such as whether the tool returns a list, handles missing topics, or has any side effects. The one-line description is insufficient for a tool with no other behavioral cues.

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 a single, efficient sentence with no filler. It is front-loaded with the core action, but may benefit from slightly more detail without becoming verbose.

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

Completeness2/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), the description should clarify the return format or behavior on error. It lacks completeness for an agent to confidently use it without assumptions.

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 the parameter 'topic' well-described in the schema. The tool description adds no additional semantic value beyond the schema, meeting the baseline for high coverage.

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 it retrieves 'programming guides and tutorials' for Connect IQ development, which distinguishes it from sibling tools like get_api_examples and get_class_details. However, the verb 'get' is generic and could be more specific.

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 is provided on when to use this tool versus alternatives like get_api_examples or search_garmin_docs. The description does not mention context or exclusions.

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

list_modulesA

List all available Garmin Connect IQ modules with descriptions

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A4/5.0
Behavior3/5

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

With no annotations, the description must carry the full burden of behavioral disclosure. It correctly indicates a read-only listing operation, but does not mention pagination, potential size of the list, or that descriptions are static. For a simple no-parameter tool, this is adequate but not thorough.

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, front-loaded sentence with no filler. Every word serves the purpose. It is perfectly concise for the tool's simplicity.

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 no parameters, no output schema, and no annotations, the description sufficiently conveys the tool's purpose and result. It is complete enough for a simple list tool, though it could briefly mention that the list is comprehensive and useful for orientation.

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?

There are zero parameters, so the baseline is 4. The description does not need to add parameter meaning, and it adds no unnecessary information. The phrase 'with descriptions' hints at output content but is not relevant to parameter semantics.

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 ('list') and resource ('Garmin Connect IQ modules'), clearly indicating the action and subject. It distinguishes from sibling tools like search_garmin_docs or get_api_examples, which search or retrieve details rather than listing all modules.

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 states what the tool does but provides no explicit guidance on when to use it vs alternatives. For example, it doesn't mention that this tool is ideal for getting an overview before using search or detail tools. The usage is implied but not clearly contextualized.

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

search_device_referenceB

Search device-specific reference documentation and capabilities

ParametersJSON Schema
NameRequiredDescriptionDefault
queryYesSearch term for device capabilities, memory limits, or hardware features
device_typeNoOptional device type filter (e.g., "watch", "bike", "golf")

TDQS

B3.3/5.0
Behavior2/5

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

No annotations are provided, and the description does not disclose behavioral traits such as read-only nature, required permissions, or response behavior, leaving the agent with insufficient information.

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 a single sentence that is front-loaded and concise, but it may be too minimal for a search tool.

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

Completeness2/5

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

No output schema exists, and the description fails to explain what the tool returns, leaving the agent without critical information about the response format.

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 both parameters described in the input schema; the description adds no additional meaning beyond what the schema already provides.

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' and the resource 'device-specific reference documentation and capabilities', distinguishing it from sibling tools like search_faq and search_garmin_docs.

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?

No explicit guidance on when to use this tool versus alternatives like get_api_examples or list_modules; usage context is implied from the name but not elaborated.

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

search_faqA

Search frequently asked questions and troubleshooting information

ParametersJSON Schema
NameRequiredDescriptionDefault
queryYesSearch term for FAQ or troubleshooting topics

TDQS

A3.5/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 convey behavior. It only states 'Search', which is obvious and adds no value beyond the tool name. No mention of side effects, permissions, or output format.

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?

Extremely concise single sentence with no unnecessary words. Perfectly front-loaded and efficient.

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?

For a simple search tool with one parameter, the description is minimally adequate but lacks details on return values, scope, or reading behavior. Given no output schema, some additional context 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?

Schema coverage is 100% for the single parameter 'query', with a clear description. The tool description does not add any extra meaning beyond what the schema already provides, meeting the baseline.

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 'frequently asked questions and troubleshooting information', specifying a distinct resource from sibling tools like search_device_reference or search_garmin_docs. It uses a clear verb and resource.

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?

No explicit guidance on when to use this tool versus alternatives. Usage is implied by the resource type, but no when-not-to-use or alternative suggestions are provided.

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

search_garmin_docsB

Search Garmin Connect IQ API documentation for modules, classes, or functions

ParametersJSON Schema
NameRequiredDescriptionDefault
queryYesSearch term (module name, class name, or function name)
categoryNoType of documentation to search forall

TDQS

B3.3/5.0
Behavior2/5

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

With no annotations provided, the description carries full burden of behavioral disclosure. It indicates a read-only search operation but does not disclose result format, pagination behavior, or any prerequisites (e.g., API key). The description is minimal and fails to add behavioral context beyond the obvious search action.

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 of 11 words, front-loaded with the action and resource. Every word is necessary and contributes to clarity. No redundancy or filler.

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?

For a simple search tool with 2 parameters and no output schema, the description covers the basic purpose. However, it lacks information about return format, result structure, or any limitations. Given the absence of an output schema, additional context would be valuable for the agent to know what to expect.

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 descriptions already covering both parameters. The description does not add new meaning to the parameters but aligns with the category enum by mentioning 'modules, classes, or functions'. Baseline 3 is appropriate as the schema does the heavy lifting.

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 ('search'), the resource ('Garmin Connect IQ API documentation'), and the scope ('modules, classes, or functions'). It effectively differentiates from sibling tools that target specific items (e.g., get_class_details) or different resources (e.g., search_device_reference).

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?

The description provides no guidance on when to use this tool versus alternatives. Given the sibling tools (e.g., get_class_details, get_module_details), an agent would benefit from knowing that for specific module or class lookups, those tools are more appropriate. The description does not establish any when-to-use or when-not-to-use context.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 8 tool updatesv1.0.1
    • First observedget_api_examples
    • First observedget_class_details
    • First observedget_module_details
    • First observedget_programming_guide
    • First observedlist_modules
    • First observedsearch_device_reference
    • First observedsearch_faq
    • First observedsearch_garmin_docs
Deploy Server
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A3.6/5.0

Scored across 8 tools

Disambiguation5/5

Each tool targets a distinct aspect of documentation (examples, class details, module details, guides, modules list, device reference, FAQ, general search), with no overlapping purposes.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern using snake_case, with verbs like get, list, and search, making the set predictable.

Tool Count5/5

Eight tools is well-scoped for a documentation server, providing focused access to different documentation types without being overwhelming or insufficient.

Completeness4/5

The set covers major documentation needs (searching, listing modules, getting details/examples/guides/FAQ/device reference), but lacks a dedicated tool to list classes within a module, though search can fill the gap.

Maintenance

ActivityInactive
ResponsivenessUnresponsive

Resources

Related MCP Connectors

Related MCP Servers