Skip to content

MCP Server#1113

Merged
jerbly merged 25 commits intoopen-telemetry:mainfrom
jerbly:mcp
Jan 11, 2026
Merged

MCP Server#1113
jerbly merged 25 commits intoopen-telemetry:mainfrom
jerbly:mcp

Conversation

@jerbly
Copy link
Contributor

@jerbly jerbly commented Jan 5, 2026

weaver-mcp

This PR adds weaver registry mcp an MCP (Model Context Protocol) server that exposes the semantic conventions registry to LLMs. This enables natural language queries for finding and understanding conventions while writing instrumentation code.

Tool Description
search Search across all registry items (attributes, metrics, spans, events, entities)
get_attribute Get detailed information about a specific attribute by key
get_metric Get detailed information about a specific metric by name
get_span Get detailed information about a specific span by type
get_event Get detailed information about a specific event by name
get_entity Get detailed information about a specific entity by type
live_check Validate telemetry samples against the registry

@codecov
Copy link

codecov bot commented Jan 5, 2026

Codecov Report

❌ Patch coverage is 87.23404% with 18 lines in your changes missing coverage. Please review.
✅ Project coverage is 80.3%. Comparing base (b3f81ed) to head (bfafb6b).
⚠️ Report is 1 commits behind head on main.

Files with missing lines Patch % Lines
crates/weaver_mcp/src/lib.rs 11.1% 16 Missing ⚠️
crates/weaver_mcp/src/service.rs 97.4% 2 Missing ⚠️
Additional details and impacted files
@@           Coverage Diff           @@
##            main   #1113     +/-   ##
=======================================
+ Coverage   79.2%   80.3%   +1.0%     
=======================================
  Files        103     105      +2     
  Lines       7992    8126    +134     
=======================================
+ Hits        6333    6528    +195     
+ Misses      1659    1598     -61     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
  • 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

@jerbly jerbly marked this pull request as ready for review January 5, 2026 02:41
@jerbly jerbly requested a review from a team as a code owner January 5, 2026 02:41
/// - `get_entity` - Get a specific entity by type
/// - `live_check` - Validate telemetry samples against the registry
#[derive(Clone)]
pub struct WeaverMcpService {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I know this may be crazy, but is there any chance we can re-use the vanilla API server and just "wrap" API methods with MCP definitions instead of having two instances of serving / application flow?

I think there's a LOT of commonality between the two pieces, and it'd be ideal if we could share it.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Wrapping a web api with mcp is an anti-pattern. I did move all the internals of search and get* into the weaver_search crate to make it common. I think it's likely they'll diverge, for example I'm experimenting with multiple tools for live-check.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Wrapping a web api with mcp is an anti-pattern.

Interesting - tell me more?

I'm suggesting MCP is basically API++. Where we can delegate to API functions we should. If you add more that's great.

E.g. I'd be nice if we had a consistent "AppContext" structure that has our Arc<State> in it and a set of methods on this that both the MCP + API server would use.

I'm not suggesting we directly call the API from MCP - just that we take small amount of time to but in a shared abstraction they can both use to interact with a 'served weaver' thing.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actually @lquerel first pointed this out to me in this comment #798 (comment) where I had a similar idea to you. Subsequently I have read this same advice quite a few times. The video link is good, there's also a good reddit thread if I recall correctly.

Did you see that I moved the common internals to the weaver_search crate?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the link! I'll take a look.

Did you see that I moved the common internals to the weaver_search crate?

I did not, but that's great!

I was actually thinking of naming the create weaver_debugger or some such - i.e. if I were to add "jq", "rego" or "jinja" debugging tools, what crate should that live in?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

weaver_devtools??

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oooh - I like that better!

Copy link
Contributor

@jsuereth jsuereth left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for all the cleanups!

I think this is good to merge, but we should track some work to make it clear how "extensions" are loaded in weaver, e.g. Rego policies.


/// MCP service for the semantic convention registry.
///
/// This service exposes 7 tools for querying and validating against the registry:
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit - let's update this to say exposes tools for querying, debugging and validating against the registry. For example:

#[command(flatten)]
pub diagnostic: DiagnosticArgs,

/// Advice policies directory. Set this to override the default policies.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My only remaining hangup on this PR is these two advice_* arguments. Basically I think our current "when to load rego, jq + jinja" story is a bit off. It's unclear when weaver.yml controls it, when you pull from the same directory as a registry and when you specify via the command line.

I think that's bigger than the scope of this PR, but let's sort that out going forward.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree, also how to specify builtins to use AND custom, or when to override the builtin with a custom. For example, often I want all the otel policies plus my own on top.

@jerbly jerbly merged commit 85bf53c into open-telemetry:main Jan 11, 2026
22 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants