Skip to main content
Glama
ryu1maniwa

OpenTelemetry Documentation MCP Server

by ryu1maniwa
OverviewSchemaRelated ServersScoreDiscussions
Python
Hybrid

OpenTelemetry Documentation MCP Server

Model Context Protocol (MCP) server for OpenTelemetry Documentation

This MCP server provides tools to access OpenTelemetry documentation and search for content using Google Custom Search.

Acknowledgements

This project is based on aws-documentation-mcp-server by Amazon Web Services, licensed under the Apache License 2.0.

Related MCP server: oci-documentation-mcp-server

Features

  • Read Documentation: Fetch and convert OpenTelemetry documentation pages to markdown format

  • Search Documentation: Search OpenTelemetry documentation using Google Custom Search

Prerequisites

Required Components

  • Docker installed on your system

  • Internet access to pull dependencies and access OpenTelemetry documentation

Google API Key Setup

To use the search functionality, you must obtain a Google API key:

  1. Visit the Google Cloud Console (https://console.cloud.google.com/apis/credentials)

  2. Create a new API key for the Custom Search API

  3. Add this API key to your MCP configuration as shown in the installation section

Without a valid Google API key, the search_documentation tool will not function properly.

Installation

Configure the MCP server in your MCP client configuration (e.g., for Amazon Q Developer CLI, edit ~/.aws/amazonq/mcp.json):

{
  "mcpServers": {
    "opentelemetry-documentation-mcp-server": {
      "command": "uvx",
      "args": ["git+https://github.com/ryu1maniwa/opentelemetry-documentation-mcp-server"],
      "env": {
        "FASTMCP_LOG_LEVEL": "ERROR",
        "GOOGLE_API_KEY": "YOUR_GOOGLE_API_KEY"
      },
      "disabled": false,
      "autoApprove": []
    }
  }
}

or docker after a successful docker build -t opentelemetry-documentation-mcp-server .:

{
  "mcpServers": {
    "opentelemetry-documentation-mcp-server": {
      "command": "docker",
      "args": [
        "run",
        "--rm",
        "--interactive",
        "--env",
        "FASTMCP_LOG_LEVEL=ERROR",
        "--env",
        "GOOGLE_API_KEY=YOUR_GOOGLE_API_KEY",
        "opentelemetry-documentation-mcp-server:latest"
      ],
      "env": {},
      "disabled": false,
      "autoApprove": []
    }
  }
}

Basic Usage

Example:

  • "look up documentation on OpenTelemetry tracing concepts. cite your sources"

  • "search OpenTelemetry documentation for information about metrics and instrumentation"

  • "find documentation about OpenTelemetry SDK configuration"

Tools

read_documentation

Fetches a OpenTelemetry documentation page and converts it to markdown format.

read_documentation(url: str) -> str

search_documentation

Searches OpenTelemetry documentation using Google Custom Search.

search_documentation(search_phrase: str, limit: int) -> list[dict]

Google Custom Search Integration

This server uses Google Custom Search to provide search functionality for OpenTelemetry documentation. The Custom Search Engine ID (cx) used is the one used by opentelemetry.io itself:

  • Custom Search Engine ID: 015faf7de29c34606

API Limits

The Google Custom Search API has the following limits:

  • Free tier: 100 queries per day

  • $5 per 1000 queries after that

  • Maximum of 10 results per query

Available Tools

2 tools
read_documentationA

Fetch and convert a OpenTelemetry documentation page to markdown format.

Usage

This tool retrieves the content of a OpenTelemetry documentation page and converts it to markdown format. For long documents, you can make multiple calls with different start_index values to retrieve the entire content in chunks.

URL Requirements

  • Must be from the opentelemetry.io domain

  • Must be a documentation page

Example URLs

Output Format

The output is formatted as markdown text with:

  • Preserved headings and structure

  • Code blocks for examples

  • Lists and tables converted to markdown format

Handling Long Documents

If the response indicates the document was truncated, you have several options:

  1. Continue Reading: Make another call with start_index set to the end of the previous response

  2. Stop Early: For very long documents (>30,000 characters), if you've already found the specific information needed, you can stop reading

Args: ctx: MCP context for logging and error handling url: URL of the OpenTelemetry documentation page to read max_length: Maximum number of characters to return start_index: On return output starting at this character index

Returns: Markdown content of the OpenTelemetry documentation

ParametersJSON Schema
NameRequiredDescriptionDefault
urlYesURL of the OpenTelemetry documentation page to read
max_lengthNoMaximum number of characters to return.
start_indexNoOn return output starting at this character index, useful if a previous fetch was truncated and more content is required.

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.5/5.0
Behavior4/5

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

With no annotations provided, the description carries full burden and does an excellent job disclosing behavioral traits. It explains the conversion to markdown format, handling of long documents through chunking, URL domain restrictions, output format details, and strategies for dealing with truncated responses. The only minor gap is it doesn't mention rate limits or authentication requirements.

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 clear sections (Usage, URL Requirements, Example URLs, Output Format, Handling Long Documents) and every sentence adds value. It's appropriately sized for a tool with this complexity and is front-loaded with the core purpose.

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 (document fetching, conversion, chunking), no annotations, and the existence of an output schema, the description is remarkably complete. It covers purpose, usage guidelines, behavioral details, parameter context, output format, and handling edge cases like long documents. The output schema handles return values, so the description appropriately focuses on other aspects.

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?

With 100% schema description coverage, the baseline is 3. The description adds some value by explaining the purpose of start_index for chunking long documents and providing example URLs, but doesn't significantly enhance parameter understanding beyond what the schema already provides about url, max_length, and start_index.

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 with specific verbs ('fetch and convert') and resource ('OpenTelemetry documentation page'), distinguishing it from the sibling 'search_documentation' tool by focusing on retrieving and converting specific pages rather than searching across documentation.

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

Usage Guidelines5/5

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

The description provides explicit usage guidelines, including when to use it (for OpenTelemetry documentation pages), when not to use it (must be from opentelemetry.io domain), and alternatives (making multiple calls with different start_index values for long documents). It also distinguishes from the sibling tool by specifying this is for reading specific pages.

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

search_documentationA

Search OpenTelemetry documentation using Google Custom Search.

Usage

This tool searches across OpenTelemetry documentation for pages matching your search phrase. Use it to find relevant documentation when you don't have a specific URL.

Search Tips

  • Use specific technical terms rather than general phrases

  • Include OpenTelemetry concepts to narrow results (e.g., "tracing instrumentation" instead of just "tracing")

  • Use quotes for exact phrase matching (e.g., "SDK configuration")

  • Include abbreviations and alternative terms to improve results (e.g., "OTEL collector")

API Limits

The search uses Google's Custom Search API which has usage limits:

  • Free tier: 100 queries per day

  • Results are limited to 10 per page

Result Interpretation

Each result includes:

  • rank_order: The relevance ranking (lower is more relevant)

  • url: The documentation page URL

  • title: The page title

  • context: A brief excerpt or summary (if available)

Args: ctx: MCP context for logging and error handling search_phrase: Search phrase to use limit: Maximum number of results to return (will be capped at 10 due to API limitations)

Returns: List of search results with URLs, titles, and context snippets

ParametersJSON Schema
NameRequiredDescriptionDefault
search_phraseYesSearch phrase to use
limitNoMaximum number of results to return

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.4/5.0
Behavior4/5

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

Since no annotations are provided, the description carries the full burden of behavioral disclosure. It does an excellent job describing key behavioral traits: it discloses the underlying API (Google Custom Search), usage limits (100 queries/day free tier), result limitations (10 per page), and what information each result contains. The only minor gap is it doesn't explicitly mention whether this is a read-only operation (though searching implies it is) or error handling specifics.

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 well-structured with clear sections (Usage, Search Tips, API Limits, Result Interpretation) and front-loads the core purpose. However, it could be slightly more concise - some information like the 'Returns' section is somewhat redundant with the 'Result Interpretation' section. Overall, most sentences earn their place by providing valuable guidance.

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 this is a search tool with 2 parameters, 100% schema coverage, and an output schema exists, the description provides excellent contextual completeness. It covers purpose, usage guidelines, behavioral traits (API limits, result format), and search optimization tips. The existence of an output schema means the description doesn't need to explain return values in detail, which it appropriately avoids.

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%, so the schema already documents both parameters thoroughly. The description adds minimal value beyond the schema: it mentions that 'limit' will be capped at 10 due to API limitations (which is useful context), but doesn't provide additional semantic context for 'search_phrase' beyond what's in the schema. This meets the baseline expectation when schema coverage is complete.

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: 'Search OpenTelemetry documentation using Google Custom Search' with the specific verb 'search' and resource 'OpenTelemetry documentation'. It distinguishes from the sibling tool 'read_documentation' by specifying this is for searching when you don't have a specific URL, while 'read_documentation' would presumably be for reading specific documentation pages.

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

Usage Guidelines5/5

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

The description provides explicit guidance on when to use this tool: 'Use it to find relevant documentation when you don't have a specific URL.' It also includes a 'Search Tips' section with detailed advice on how to formulate effective queries, and mentions API limits that inform usage decisions. The contrast with the sibling 'read_documentation' is implied through the 'when you don't have a specific URL' statement.

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

A4.3/5.0
Disambiguation5/5

The two tools have clearly distinct purposes: 'read_documentation' fetches and converts specific documentation pages to markdown, while 'search_documentation' searches across documentation for relevant pages. There is no overlap in functionality, and an agent can easily differentiate between retrieving known content and discovering unknown content.

Naming Consistency5/5

Both tools follow a consistent verb_noun pattern with snake_case naming: 'read_documentation' and 'search_documentation'. The verbs ('read' and 'search') are distinct and appropriate for their functions, and the naming scheme is predictable and readable throughout the set.

Tool Count2/5

With only 2 tools, the server feels thin for its purpose of providing OpenTelemetry documentation access. While the tools cover basic retrieval and search, the scope suggests potential for more operations (e.g., listing documentation categories, filtering by version, or handling API interactions), making the count insufficient for a comprehensive documentation server.

Completeness3/5

The server covers core documentation access with read and search functions, but there are notable gaps. It lacks tools for browsing documentation structure (e.g., listing sections or topics), handling updates or version-specific content, or integrating with other OpenTelemetry resources, which limits agent workflows to basic lookup tasks without broader context.

Maintenance

ActivityInactive
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

Appeared in Searches

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/ryu1maniwa/opentelemetry-documentation-mcp-server'

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