-
Notifications
You must be signed in to change notification settings - Fork 62
Add dart mcp server events #2112
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
Package publishing
Documentation at https://github.com/dart-lang/ecosystem/wiki/Publishing-automation. |
PR Health
Breaking changes
|
Package | Change | Current Version | New Version | Needed Version | Looking good? |
---|---|---|---|---|---|
unified_analytics | Breaking | 8.0.1 | 8.0.2 | 9.0.0 Got "8.0.2" expected >= "9.0.0" (breaking changes) |
This check can be disabled by tagging the PR with skip-breaking-check
.
Changelog Entry ✔️
Package | Changed Files |
---|
Changes to files need to be accounted for in their respective changelogs.
Coverage ⚠️
File | Coverage |
---|---|
pkgs/unified_analytics/lib/src/constants.dart | 💔 Not covered |
pkgs/unified_analytics/lib/src/enums.dart | 💚 100 % |
pkgs/unified_analytics/lib/src/event.dart | 💚 98 % ⬆️ 0 % |
This check for test coverage is informational (issues shown here will not fail the PR).
This check can be disabled by tagging the PR with skip-coverage-check
.
API leaks ⚠️
The following packages contain symbols visible in the public API, but not exported by the library. Export these symbols or remove them from your publicly visible API.
Package | Leaked API symbols |
---|---|
unified_analytics | Condition PersistedSurvey GAClient UserProperty |
This check can be disabled by tagging the PR with skip-leaking-check
.
License Headers ✔️
// Copyright (c) 2025, the Dart project authors. Please see the AUTHORS file
// for details. All rights reserved. Use of this source code is governed by a
// BSD-style license that can be found in the LICENSE file.
Files |
---|
no missing headers |
All source files should start with a license header.
Unrelated files missing license headers
Files |
---|
pkgs/bazel_worker/benchmark/benchmark.dart |
pkgs/bazel_worker/example/client.dart |
pkgs/bazel_worker/example/worker.dart |
pkgs/benchmark_harness/integration_test/perf_benchmark_test.dart |
pkgs/boolean_selector/example/example.dart |
pkgs/clock/lib/clock.dart |
pkgs/clock/lib/src/clock.dart |
pkgs/clock/lib/src/default.dart |
pkgs/clock/lib/src/stopwatch.dart |
pkgs/clock/lib/src/utils.dart |
pkgs/clock/test/clock_test.dart |
pkgs/clock/test/default_test.dart |
pkgs/clock/test/stopwatch_test.dart |
pkgs/clock/test/utils.dart |
pkgs/coverage/lib/src/coverage_options.dart |
pkgs/html/example/main.dart |
pkgs/html/lib/dom.dart |
pkgs/html/lib/dom_parsing.dart |
pkgs/html/lib/html_escape.dart |
pkgs/html/lib/parser.dart |
pkgs/html/lib/src/constants.dart |
pkgs/html/lib/src/encoding_parser.dart |
pkgs/html/lib/src/html_input_stream.dart |
pkgs/html/lib/src/list_proxy.dart |
pkgs/html/lib/src/query_selector.dart |
pkgs/html/lib/src/token.dart |
pkgs/html/lib/src/tokenizer.dart |
pkgs/html/lib/src/treebuilder.dart |
pkgs/html/lib/src/utils.dart |
pkgs/html/test/dom_test.dart |
pkgs/html/test/parser_feature_test.dart |
pkgs/html/test/parser_test.dart |
pkgs/html/test/query_selector_test.dart |
pkgs/html/test/selectors/level1_baseline_test.dart |
pkgs/html/test/selectors/level1_lib.dart |
pkgs/html/test/selectors/selectors.dart |
pkgs/html/test/support.dart |
pkgs/html/test/tokenizer_test.dart |
pkgs/html/test/trie_test.dart |
pkgs/html/tool/generate_trie.dart |
pkgs/pubspec_parse/test/git_uri_test.dart |
pkgs/stack_trace/example/example.dart |
pkgs/watcher/test/custom_watcher_factory_test.dart |
pkgs/yaml_edit/example/example.dart |
Cross linking tracking issue: #2112 |
We could add a parameter |
Yeah, I just don't know if we need more specific types or not, if generic events are fine I would lean towards that direction. |
Generic events are fine to use. We can just pass some event label in the data and then use that to look it up in queries. Take a look at |
Ok, I made the events more generic and also added a field for the MCP server version. |
(note that I will update tests once we agree on a structure for these events) |
Nevermind, I see the DevTools strategy is just to flatten all the fields directly into the parent map, that works. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM once this is approved from a product perspective @anderdobo
@@ -55,6 +55,11 @@ enum DashEvent { | |||
description: 'Pub package resolution details', | |||
toolOwner: DashTool.dartTool, | |||
), | |||
dartMCPEvent( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Note: I assume I don't have to consider this breaking since it isn't exported publicly.
Ok, I just pushed up the test and pubspec/changelog updates, PTAL. Are we ok to publish this right after the merge? |
/// | ||
/// The [serverVersion] is the version of the Dart MCP server. | ||
/// | ||
/// The [type] identifies the kind of event this is, and [eventData] is the |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
do we have a list of the expected event types? should we use an enum?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It will live in the dart_mcp_server package
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there a reason it should live there an not here? If it lives here, we can enforce the parameter to have the enum type and guarantee what types of events are getting sent to analytics. Otherwise, any string could be passed in here and the enum values are not enforced.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It doesn't have to be this way, I was mostly just replicating how the devtools events work, but I think there are two primary reasons:
- It makes it easier to add new events
- These are public which means adding a new event would be a breaking change in this package which would be unfortunate (adding values to public enums breaks switches and other exhaustiveness checks)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fair points. Fine to leave in dart_mcp_server then.
Based on dart-lang/tools#2112 Adds analytics events for all tool calls as well as for the runtime errors resource. We could consider a generic resource read event which includes the URI, but we could accidentally create URIs that have some information we don't want to capture, so I chose to instead just customize this and not provide the URI, but a field that describes the type of resource that was read. I did not add any debouncing because I don't think it is necessary, LLMs do not invoke tools in super rapid succession generally, but let me know if you all disagree and think I should do some debouncing.
This is more a proposal for potential new analytics events than a PR intended to be merged right now.
Specifically, we should consider whether we want a more general purpose event type, or specific events for different MCP server interactions.
For example we do expose runtime errors as both a tool and a resource currently, depending on the client support. Do we want a separate event to capture access to resources, or should we try and make this more general so we can add that kind of event later on without changes to this package?