Conversation
…n MCP tools and handlers
…r live check tool
…metric, search, and span tools
…icies and preprocessor support
Codecov Report❌ Patch coverage is
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. 🚀 New features to boost your workflow:
|
| /// - `get_entity` - Get a specific entity by type | ||
| /// - `live_check` - Validate telemetry samples against the registry | ||
| #[derive(Clone)] | ||
| pub struct WeaverMcpService { |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
Oooh - I like that better!
jsuereth
left a comment
There was a problem hiding this comment.
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.
crates/weaver_mcp/src/service.rs
Outdated
|
|
||
| /// MCP service for the semantic convention registry. | ||
| /// | ||
| /// This service exposes 7 tools for querying and validating against the registry: |
There was a problem hiding this comment.
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. |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
This PR adds
weaver registry mcpan 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.searchget_attributeget_metricget_spanget_eventget_entitylive_check