Latest in AI
GitHub Copilot Usage Metrics Now Name Custom Skills, Agents and MCP Servers
The API can show which internal agent tools developers use, but its counters need a closer reading before they become adoption targets.
GitHub updated Copilot usage metrics on October 22, 2026 to identify an organization's custom skills, agents, MCP servers, slash commands and plugins by name. Administrators can now distinguish internal tools that were previously grouped together, making it easier to see whether a rollout reaches developers.
For a platform team maintaining several agent integrations, that is a useful change. A single category for custom tools can hide both a successful integration and one that nobody has found.
What changed in the Copilot usage metrics API
The release announcement says the relevant breakdown arrays now show configured names instead of generic labels. Each list holds up to 25 entries per record, increased from five, with remaining activity grouped under other.
Names appear only in report days processed after the release. Older reports do not gain them retroactively. Names are trimmed to 128 characters, while values resembling file paths remain grouped rather than exposed. Review internal naming before sharing reports externally.
Coverage includes Copilot CLI, the Copilot app, ACP integrations and the Copilot SDK. Prompt mode, the app and ACP require CLI 1.0.97 or later; SDK-based experiences require SDK 1.0.21 or later. Built-in IDE chat telemetry does not report these names.
MCP usage does not mean MCP tool calls
The most useful detail is in GitHub's metrics field reference. These counters measure different events:
| Breakdown | What its interaction count measures |
|---|---|
| Skills | Skill invocations |
| Custom agents | Agent starts |
| MCP servers | Connection and reconnection attempts, including failed attempts |
| Slash commands | Command invocations |
| Plugins | Skill invocations associated with a plugin |
Tool calls made through an existing MCP connection do not increase the MCP counter. Plugin interactions already belong to skill totals, so adding those two figures double-counts activity. Distinct-item counts describe different identifiers with activity, rather than people or total uses.
A busy MCP connection counter is not proof of a useful integration. A server reconnecting repeatedly could produce a larger number without helping anyone complete more work. Conversely, a stable connection could support useful activity without generating many connection events.
The sensible comparison is within the same counter over time, alongside evidence that the workflow is working. Ranking an agent, a skill and an MCP server by their raw interaction counts would compare different things.
How to retrieve and interpret the reports
GitHub's REST API documentation describes enterprise and organization reports, including daily and 28-day versions. The enterprise daily endpoint is /enterprises/{enterprise}/copilot/metrics/reports/enterprise-1-day, with a day query parameter. It returns signed download links for processed reports rather than a live stream of activity.
Access requires the appropriate metrics permission and an enabled Copilot usage metrics policy. These are administrative reports, not an endpoint any developer can query simply because they have a Copilot seat.
GitHub also documents telemetry and reporting differences. Missing client telemetry can leave detailed activity out of reports even when server-side activity contributes to an active-user count. CLI and IDE metrics also have different coverage. Align the reporting period and the population before treating a discrepancy as a change in behavior.
What engineering teams can do with named tools
A reasonable starting point is one internal skill with a clear job, such as preparing a repository for a release. Check whether people find it after rollout, then ask whether its output reduces review effort or merely moves that effort elsewhere.
Names make adoption easier to investigate; they do not establish quality. The opportunity is to stop treating all internal agent work as one anonymous category and start maintaining these integrations like products, with a defined user, a useful job and evidence that the job gets done.
I’m Paras. I work at the intersection of AI, engineering and distribution.
I help technical teams explain complex AI launches and developer workflows in content that founders and developers can use and share.