Allows browsing OpenTelemetry repositories and searching issues via the GitHub API.
Provides access to OpenTelemetry repositories, documentation, examples, semantic conventions, and instrumentation scoring to help implement high-quality observability.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@otel-instrumentation-mcp find the semantic convention for database span attributes"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
---
A Model Context Protocol (MCP) server that bridges AI coding assistants (like ClaudeCode, OpenCode, Windsurf, and Cursor) with the OpenTelemetry ecosystem. It provides real-time access to OpenTelemetry repositories, documentation, examples, semantic conventions, and the instrumentation score specification to help engineers implement high-quality observability in their applications.
OpenTelemetry has extensive documentation and many implementation patterns. This MCP server helps AI assistants:
Navigate the complexity of OpenTelemetry documentation
Provide accurate, up-to-date instrumentation code
Follow best practices and semantic conventions
Generate instrumentation that scores qualitatively high
Avoid common pitfalls and anti-patterns
Related MCP server: AI Workflow Intelligence
The MCP server provides tools and prompts to help AI assistants with OpenTelemetry tasks:
Repository & Issue Access - Browse OpenTelemetry repositories and search issues
Examples & Documentation - Language-specific examples and documentation
Semantic Conventions - Access to standardized attribute definitions
Instrumentation Scoring - Evaluate telemetry quality based on best practices
AI Prompts - Analyze code and generate instrumentation suggestions
Additional capabilities:
Self-Instrumented - Full distributed tracing with OpenTelemetry
Multi-Transport - Supports stdio (local), HTTP, and SSE protocols
Production Ready - Kubernetes manifests, health checks, graceful shutdown
GitHub Integration - Authenticated API access via GitHub App or Personal Access Token
Currently supported authentication methods:
GitHub Personal Access Token (PAT) - For individual, local use.
GitHub App - For hosted deployments.
IMPORTANT: OAuth support is planned for future implementations. Ensure your credentials are properly secured and never commit them to version control.
Python 3.13+
uv package manager
GitHub authentication (Personal Access Token or GitHub App credentials)
Clone the repository:
git clone https://github.com/liatrio-labs/otel-instrumentation-mcp.git
cd otel-instrumentation-mcpInstall dependencies:
uv syncSet up GitHub authentication (choose one):
Option A: Personal Access Token
export GITHUB_TOKEN="github_pat_..."Option B: GitHub App (recommended for production)
export GITHUB_APP_ID="123456"
export GITHUB_INSTALLATION_ID="654321"
export GITHUB_APP_PRIVATE_KEY_PATH="/path/to/private-key.pem"NOTE: Additional environment variables can be set, like the
OTEL_EXPORTER_OTLP_ENDPOINT. For a list of available environment variables, see .env.examples
Run the MCP server:
uv run otel-instrumentation-mcpFor development with hot reload and local Kubernetes:
# Install development dependencies
task install
# Run with Tilt (includes local Kubernetes, OpenTelemetry Collector, hot reload)
tilt up
# Or run development server standalone with hot reload
task dev
# Run tests
task test
# Run linting and formatting
task lint
# Run all checks (test + lint)
task checksAdd to your Claude Desktop configuration:
{
"mcpServers": {
"otel-instrumentation-mcp": {
"command": "uv",
"args": ["run", "otel-instrumentation-mcp"],
"cwd": "/path/to/otel-instrumentation-mcp",
"env": {
"GITHUB_TOKEN": "your_github_token"
}
}
}
}VS Code supports MCP servers through the GitHub Copilot extension (requires Copilot
Chat). Add to your workspace's .vscode/mcp.json file:
{
"servers": {
"otel-instrumentation-mcp": {
"command": "uv",
"args": ["run", "otel-instrumentation-mcp"],
"cwd": "/path/to/otel-instrumentation-mcp",
"env": {
"GITHUB_TOKEN": "your_github_token"
}
}
}
}Alternatively, add to your VS Code settings.json for global configuration:
{
"mcp": {
"servers": {
"otel-instrumentation-mcp": {
"command": "uv",
"args": ["run", "otel-instrumentation-mcp"],
"cwd": "/path/to/otel-instrumentation-mcp",
"env": {
"GITHUB_TOKEN": "your_github_token"
}
}
}
}
}Note: Ensure
uvis in your PATH or use the full path to theuvexecutable. After adding the configuration, reload VS Code and the MCP server should appear in Copilot Chat's available tools.
Add to your MCP configuration file:
{
"mcpServers": {
"otel-instrumentation-mcp": {
"command": "uv",
"args": ["run", "otel-instrumentation-mcp"],
"cwd": "/path/to/otel-instrumentation-mcp",
"env": {
"GITHUB_TOKEN": "your_github_token"
}
}
}
}npx @modelcontextprotocol/inspector uv run otel-instrumentation-mcpFor network-accessible deployments:
# HTTP Transport
SERVICE_PORT=8080 uv run otel-instrumentation-mcp
# Access at: http://localhost:8080/mcp/
# SSE Transport
MCP_TRANSPORT=sse MCP_PORT=8080 uv run otel-instrumentation-mcp
# Access at: http://localhost:8080/Note: Remote access currently requires GitHub authentication configured via environment variables. OAuth support for client authentication is coming soon.
Once configured, you can ask your AI assistant to help with OpenTelemetry instrumentation:
User: Help me add OpenTelemetry instrumentation to my Python Flask application
AI Assistant: I'll help you add OpenTelemetry instrumentation to your Flask
application. Let me first check the latest OpenTelemetry documentation and
examples for Python.
[Uses get_opentelemetry_docs_by_language tool]
[Uses get_opentelemetry_examples_by_language tool]
[Uses get_semantic_conventions tool]
Based on the latest OpenTelemetry documentation, here's how to properly
instrument your Flask application...
[Provides relatively accurate* up-to-date instrumentation code following best
practices]The repository includes Kubernetes manifests with:
Deployment with health checks and resource limits
Service for internal communication
OpenTelemetry Collector integration
ConfigMaps for feature flags
Support for different environments via the Kustomize overlay pattern (dev, local, prod)
# Example
kubectl apply -k manifests/overlays/prodVariable | Description | Default |
| Service name for telemetry |
|
| Service version |
|
| Instance identifier |
|
| Port for HTTP transport (overrides MCP_PORT) | - |
| Transport type ( |
|
| Host binding for HTTP/SSE | Auto-detected |
| Port for HTTP/SSE transport |
|
| OTLP collector endpoint |
|
Choose one authentication method:
GitHub App (Recommended):
GITHUB_APP_ID - GitHub App ID
GITHUB_INSTALLATION_ID - Installation ID
GITHUB_APP_PRIVATE_KEY_PATH - Path to private key
Personal Access Token:
GITHUB_TOKEN - GitHub personal access token
# Run all tests
task test
# Run specific test
task test-single -- tests/test_main.py::test_list_opentelemetry_repos_tool
# Run with coverage
task test-coverage# Run all checks
task checks
# Format code
task lint# Start with hot reload
task dev
# Custom port
SERVICE_PORT=3000 task devThe MCP server is fully instrumented with OpenTelemetry, providing:
Distributed tracing for MCP operations
Custom semantic conventions for MCP and GenAI specific attributes
Integration with standard OpenTelemetry collectors
High instrumentation quality (measured with Instrumentation Score)
View traces in your preferred backend (Jaeger, Honeycomb, Datadog, Dash0, etc.)
by configuring OTEL_EXPORTER_OTLP_ENDPOINT.
FastMCP Framework - Provides MCP protocol implementation
OpenTelemetry SDK - Full observability with auto-instrumentation
Async Python - High-performance async/await patterns
GitHub GraphQL API - Efficient data fetching from repositories
Multi-transport - Flexible deployment options (stdio, HTTP, SSE)
OAuth Support - Full OAuth flow for MCP authentication
Caching Layer - Native caching for GitHub API responses to improve performance
Weaver Custom Semantic Conventions - Support for custom semantic convention registries through Weaver.
OAuth flow for MCPs isn't implemented yet.
GitHub API rate limits apply organizationally when self-hosting through an app.
Currently optimized for OpenTelemetry repositories only.
We welcome contributions! Please submit issues and pull requests on GitHub. See CONTRIBUTING.md to get started.
This project is licensed under the Apache License 2.0 - see the LICENSE file for details.
Issues: GitHub Issues
Discussions: GitHub Discussions
This is a derived worked from @sgsharma's original otel-instrumentation-mcp at this commit.
Get Instrumentation Score rules
Returns scoring rules from the Instrumentation Score specification. Rules can be filtered by ID, impact level, or target type.
Args: rule_ids: Comma-separated list of rule IDs to fetch (e.g., "RES-001,SPA-001") impact_levels: Comma-separated list of impact levels (e.g., "Critical,Important") targets: Comma-separated list of targets (e.g., "Resource,Span")
| Name | Required | Description | Default |
|---|---|---|---|
| rule_ids | No | ||
| impact_levels | No | ||
| targets | No |
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. It indicates a read operation (returns rules) but omits details on authorization needs, rate limits, data volume, error handling, or whether unfiltered calls return all rules. Minimal but adequate for a simple retrieval tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: a two-sentence overview followed by a clean bullet-style args list. Every sentence adds value, with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description should clarify what is returned. It states 'returns scoring rules' but does not specify the structure, whether filtering is case-sensitive, or default behavior when no parameters are provided. Some gaps remain for a fully self-contained tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 0% description coverage (no descriptions on properties). The description compensates fully by explaining each parameter's purpose, expected format (comma-separated lists), and providing example values for each, which adds critical meaning beyond the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves scoring rules from the Instrumentation Score specification, with filtering options. It distinguishes itself from sibling tool get_instrumentation_score_spec by specifying it returns individual rules, not the spec.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions filtering parameters but provides no explicit guidance on when to use this tool versus its siblings, such as get_instrumentation_score_spec or the OpenTelemetry search tools. No when-to-use or when-not-to-use advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the Instrumentation Score specification
Returns the main specification document for the Instrumentation Score standard, which provides a standardized metric for assessing OpenTelemetry instrumentation quality.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description correctly indicates it's a read operation returning the spec document. It could be improved by stating the format (e.g., text, JSON) but is adequate for a simple retrieval.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two front-loaded sentences with no wasted words. Every sentence serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description explains what is returned (specification document) but could specify the media type or structure. Overall, it's sufficiently complete for a parameterless tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so baseline is 4. The description adds context about the spec's purpose, adding value beyond the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets the 'Instrumentation Score specification', using a specific verb and resource. It distinguishes from the sibling 'get_instrumentation_score_rules' which focuses on rules rather than the spec.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when the spec is needed but lacks explicit guidance on when to use this tool vs alternatives like get_instrumentation_score_rules or other documentation tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get OpenTelemetry documentation by language and version
Returns OpenTelemetry documentation for a specific programming language and version
Args: language: Programming language (e.g. python, java, go) version: Version to retrieve (e.g. "v1.2.3", "latest", or None for latest)
| Name | Required | Description | Default |
|---|---|---|---|
| language | No | python | |
| version | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility. It does not disclose any behavioral traits such as authentication needs, rate limits, or error behavior (e.g., what happens if the version is not found). The description is minimal and lacks transparency beyond the basic function.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences plus a compact argument list. Every sentence is necessary and front-loads the main purpose. No unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (2 simple parameters, no output schema) and the presence of related siblings, the description covers the essential function and parameter details. However, it lacks behavioral information and does not describe the return format, which would be helpful for a complete understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, so the description must compensate. It explains both parameters: language (with examples like python, java, go) and version (with examples like v1.2.3, latest, or None for latest). This adds meaningful semantics beyond the schema's type and default fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns OpenTelemetry documentation for a specific language and version. It uses a specific verb ('Get') and identifies the resource ('OpenTelemetry documentation'). However, it does not differentiate from sibling tools like get_opentelemetry_examples_by_language, which is a minor gap.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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. There are no explicit when-not-to-use or prerequisite conditions. The sibling tools handle related topics (examples, rules, specs), but no usage context is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get OpenTelemetry examples
Returns a list of OpenTelemetry demo services and examples
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, and the description only states that the tool returns a list without any additional behavioral context such as the structure of the list, potential filtering, or any side effects. For a simple read tool, more transparency about the output would be helpful.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two short sentences, front-loading the purpose. No extraneous information is present.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having no parameters and no output schema, the description lacks details about what constitutes an 'example', the format of the returned list, or how it relates to the sibling tools. More context would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, so schema coverage is 100%. The description adds no param-specific information, but none is needed. Baseline score of 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets OpenTelemetry examples and returns a list of demo services and examples. However, it does not differentiate from the sibling tool 'get_opentelemetry_examples_by_language', which suggests this may return all examples without filtering.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidelines are provided. The description does not indicate when to use this tool versus other sibling tools like 'get_opentelemetry_examples_by_language' or 'search_opentelemetry_issues'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get OpenTelemetry examples by language
Returns OpenTelemetry examples for a specific programming language
Args: language: Programming language (e.g. python, java, go)
| Name | Required | Description | Default |
|---|---|---|---|
| language | No | python |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description does not disclose any behavioral traits such as read-only, pagination, or error conditions. For a retrieval tool, basic safety info is absent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three lines, includes a redundant title line (same as tool name). Could be more concise by removing the first line or merging with description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description covers basic purpose and parameter. Missing info about response format or potential limits.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description adds meaning by stating 'Programming language (e.g. python, java, go)'. However, it is minimal and does not list supported languages or format requirements.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly specifies verb 'Get', resource 'OpenTelemetry examples', and filter 'by language'. Distinguishes from sibling 'get_opentelemetry_examples' which likely returns all examples without language filter.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies use when examples for a specific language are needed, but no explicit when-not-to-use or alternatives mentioned. Sibling tools exist but are not referenced.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get OpenTelemetry semantic conventions from the semantic-conventions repository
Returns semantic conventions from the OpenTelemetry semantic-conventions repository as markdown documentation files.
Args: category: Optional category filter (e.g., "http", "database", "messaging") count: Maximum number of files to retrieve (default: 50)
| Name | Required | Description | Default |
|---|---|---|---|
| category | No | ||
| count | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It reveals that the tool returns markdown documentation files, which is helpful. However, it does not disclose other behaviors like readability, authentication needs, or effects of invalid parameters. Acceptable but could be more transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with slight redundancy (first two both describe returning conventions). Could be more concise by merging, but not overly verbose. Front-loaded with purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose and parameters adequately for a retrieval tool with two optional params. Lacks details on return value structure (list of files, content?) and error handling. With no output schema, more specificity would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description compensates well by explaining both parameters: 'category' as optional filter, 'count' as maximum number of files with default 50. This adds meaningful context beyond the schema's type/default fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states verb 'Get' and resource 'OpenTelemetry semantic conventions' from the repository, and specifies output format as 'markdown documentation files'. While not extremely detailed, it effectively distinguishes from sibling tools focused on instrumentation scoring and docs by language.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description implies use by listing optional parameters (category, count), but no explicit guidance on when to use or avoid this tool vs alternatives. Sibling tools cover different topics, so context is somewhat clear but lacks explicit usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get OpenTelemetry repository issues
Returns issues from a specific OpenTelemetry repository
Args: repo: Repository name (e.g. opentelemetry-python)
| Name | Required | Description | Default |
|---|---|---|---|
| repo | No | opentelemetry-python |
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 whether returned issues are open/closed, pagination, limits, or authentication needs. It only states it returns issues.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded, but the second sentence ('Returns issues from a specific OpenTelemetry repository') is redundant with the first, slightly reducing efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema is provided, and the description does not describe what the returned data contains (e.g., issue IDs, titles) or mention pagination/limits. This leaves the agent with incomplete information for a list tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description adds an example value ('opentelemetry-python') but does not specify allowed values, format, or constraints beyond naming the parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses 'Get OpenTelemetry repository issues' and explains it returns issues from a specific repo. It is clear but does not distinguish from sibling 'search_opentelemetry_issues' which may offer filtering.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 search_opentelemetry_issues. The description only implies it is for specific repos.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List OpenTelemetry repositories
Returns a list of OpenTelemetry repositories
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description indicates the tool returns a list, which is basic behavioral information. Since there are no annotations to contradict, and no parameters, the description is minimally sufficient but lacks any additional details like pagination or filtering.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two short sentences, but it is slightly redundant ('List...' and 'Returns a list...'). Still, it is front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters, output schema, or annotations, the description provides the minimum. It confirms the tool returns a list but does not specify any constraints or ordering, which could be helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameters, so schema coverage is 100% by default. The baseline for 0 parameters is 4, and the description does not need to add parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List' and resource 'OpenTelemetry repositories', making the purpose clear. However, it does not distinguish this tool from siblings like 'list_opentelemetry_issues', leaving room for ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 such as 'list_opentelemetry_issues' or other OpenTelemetry tools. The description lacks usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search OpenTelemetry repository issues
Search for issues in a specific OpenTelemetry repository using keywords
Args: repo: Repository name (e.g. opentelemetry-python) keywords: Keywords to search for in issues
| Name | Required | Description | Default |
|---|---|---|---|
| repo | No | opentelemetry-python | |
| keywords | No | metrics |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description lacks disclosure of behavioral traits such as result limit, pagination, authentication needs, or error handling. Minimum detail on what the tool does beyond the basic operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is fairly concise but repeats the purpose in two sentences (title then explanation). It could be more streamlined. Structure is adequate with clearly labeled args.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema or annotations, the description covers the essential purpose and parameters but lacks details on return format, ordering, or limitations. It is functionally complete for a simple search but could be more informative.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description explains both parameters (repo and keywords) with examples, adding meaning beyond the bare schema which has no descriptions. Schema coverage is 0%, so this compensation is valuable, though more detail (e.g., keyword format) could be added.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it searches issues in a specific OpenTelemetry repo using keywords, distinguishing it from list_opentelemetry_issues which likely lists all. However, it does not explicitly contrast with siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when searching with keywords but provides no guidance on when not to use it or alternatives like list_opentelemetry_issues. No prerequisites or context are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.5.0get_instrumentation_score_rulesget_instrumentation_score_specget_opentelemetry_docs_by_languageget_opentelemetry_examplesget_opentelemetry_examples_by_languageget_semantic_conventionslist_opentelemetry_issueslist_opentelemetry_repossearch_opentelemetry_issuesScored across 9 tools
Each tool targets a distinct purpose: rules, spec, docs, examples, semantic conventions, repos, issues, and search. There's no overlap; even the two 'by language' tools differentiate between documentation and examples.
All tool names follow a consistent verb_noun pattern with snake_case, using clear prefixes like get_, list_, search_. Suffixes like _by_language are applied uniformly, making the naming predictable and easy to navigate.
With 9 tools, the server is well-scoped for its purpose as a reference and documentation resource for OpenTelemetry instrumentation. Each tool serves a clear role without being excessive or insufficient.
The tool set covers essential aspects: rules, spec, docs, examples, conventions, and repository interaction. A minor gap is the lack of a direct tool to compute or evaluate an instrumentation score, but the provided tools offer foundational information for that purpose.
Query your team's drift, vulnerability, and upgrade data from any AI assistant. OAuth 2.1, 51 tools.
AI agent observability for production traces, natural-language insights, and improvement loops.
Your team's shipping standards, org map and delivery metrics, inside your coding agent.
LLM Orchestration Agent (Opentelemetry Api)
