Copilot CLI usage metrics API now tracks MCP and skills
The Copilot usage metrics API gained five new arrays plus distinct-use counters, so admins can see which skills, MCP servers and plugins teams actually run.
In short
As of September 17, 2026, GitHub's Copilot usage metrics API reports separate counts for the skills, custom agents, MCP servers, slash commands and plugins used inside Copilot CLI.
At a glance
- New arrays: totals_by_skill, totals_by_custom_agent, totals_by_mcp, totals_by_slash_cmd, totals_by_plugin.
- Each array lists up to five items with the most recorded activity, each with an interaction_count.
- distinct_*_use_count fields measure variety: how many different items of a category were used.
- Present in 1-day reports (per-user and aggregate), per-user 28-day reports, and in day_totals entries.
- Customer-defined names stay hidden; only recognized GitHub-provided items are named.
Teams have been building Copilot CLI customizations faster than they could measure them. On September 17, 2026, GitHub closed part of that gap: the Copilot usage metrics API now breaks CLI activity down by the extensions doing the work, rather than reporting the CLI as a single block.
Who gets used, and how widely
Five arrays carry the leaderboard data: totals_by_skill, totals_by_custom_agent, totals_by_mcp, totals_by_slash_cmd and totals_by_plugin. Each one returns up to five items with the most recorded activity, reported through an interaction_count. That is enough to answer whether an internal MCP server is a load-bearing part of a workflow or effectively dead weight.
A second group of fields answers a different question. distinct_skill_use_count, distinct_custom_agent_use_count and their siblings count how many different items a person or org touched. Read together, the two groups separate concentration from breadth — heavy traffic through two skills looks nothing like light traffic spread across twenty.
Where the fields show up
The new data lands inside reports that already existed. It appears in enterprise and organization 1-day reports, both per-user and aggregate, in per-user 28-day reports, and in the day_totals entries of aggregate 28-day reports. No new endpoint is involved, so existing integrations mainly need to widen their parsing.
The privacy tradeoff
Attribution stops short of naming everything. GitHub says recognized items it provides are shown by name, while customer-defined names are withheld to protect privacy. In practice, a home-grown skill or a private MCP server surfaces as an unnamed bucket, which limits how precisely the numbers can be traced back to one team's tooling.
Access is scoped to enterprise owners, billing managers and organization owners, plus anyone holding a custom role that grants the "View Copilot Metrics" permission.
Three things the changelog does not answer
The announcement says nothing about how long this data is retained, and nothing about whether earlier periods are backfilled. It also never states whether the fields cover only Copilot CLI or extend to IDE and chat usage, though the wording refers to CLI reports throughout. None of these three points is confirmed, so treat them as open questions against the API reference before building reporting on top.
FAQ
What new fields did the Copilot usage metrics API add?
Five arrays — totals_by_skill, totals_by_custom_agent, totals_by_mcp, totals_by_slash_cmd and totals_by_plugin — each listing up to five items with an interaction_count, plus matching distinct_*_use_count fields.
Can I see the names of my own skills and MCP servers?
No. Only recognized GitHub-provided items are shown by name; customer-defined names are withheld to protect privacy, so internal items appear as unnamed buckets.
Who can access Copilot usage metrics?
Enterprise owners, billing managers, organization owners, and users with a custom role that grants the "View Copilot Metrics" permission.
