Copilot usage reports now name your team's custom skills, agents and MCP servers

What changed in the reports

As github.blog reported, Copilot's usage metrics used to lump anything an organization built itself into generic buckets labeled 'other' or 'custom'. Now the reports show the actual names of those items. That covers custom skills (reusable instructions for the assistant), custom agents, slash commands (typed shortcuts such as a command that starts a task), plugins, and MCP servers.

An MCP server, short for Model Context Protocol server, is a connector that lets an AI assistant reach another tool or set of data. Because each one is a doorway into company systems, knowing which ones developers actually call matters beyond convenience.

The change applies across enterprise and organization reports, in both the one-day and 28-day views, including per-user breakdowns. It builds on customization metrics for the command-line version of Copilot that GitHub released in September.

Five slots become 25

The second change is depth. Each category list inside a record used to show only five entries. It can now show up to 25, which exposes much more of the long tail: the small, niche customizations that only one team relies on.

Anything beyond those 25 is still folded into a final 'other' line. The counting itself has not changed. The interaction count and the distinct-use counts are calculated the same way as before, so existing dashboards and comparisons should still line up.

Which tools report names

Names flow in from several places: Copilot's command-line tool in both interactive and prompt mode, the GitHub Copilot app, tools connected through the Agent Client Protocol (ACP, a standard for plugging agents into editors such as JetBrains), and the Copilot SDK, GitHub's toolkit for building on Copilot.

Version requirements apply. Prompt mode, the app and ACP integrations need Copilot CLI 1.0.97 or later. The SDK needs v1.0.21 or later. An editor reports names only when its agent features run on SDK v1.0.21 or later.

One gap is worth knowing: names are not reported from an editor's built-in chat telemetry. If most of your developers use plain chat inside their IDE, you will see less than you might expect.

Limits to keep in mind

The numbers come from telemetry sent by each developer's software. That signal can go missing when clients are out of date or when telemetry is blocked, so the figures can undercount real use. GitHub's own advice is to read them as trends and adoption signals, not as a precise ledger.

Names are shown as configured, trimmed and capped at 128 characters. Anything that looks like a file path stays in the generic 'other' or 'custom' group. Because names are written by your own people, GitHub suggests reviewing them before a report leaves the organization.

There is also a history gap. Names appear only for report days processed after the release, so older days keep the generic labels. Do not expect to chart a year of adoption retroactively.

Access follows existing rules. Enterprise owners, billing managers and organization owners can view the reports, as can anyone given a custom role with the 'View Copilot Metrics' permission. The Copilot usage metrics policy must also be switched on.

What an admin can do with it

GitHub frames the main use as measuring adoption of what your own teams build. If you roll out a new internal skill or connector, you can now check whether people pick it up, rather than assuming so. You can also direct training and support to the places where a useful tool is going unused.

There is a security angle too. A list of the MCP servers in real use is effectively an inventory of the connections your assistants have into company data. Tools nobody uses are candidates for removal, and the busy ones are candidates for a closer review.

• Check that developers are on the minimum versions listed above, or the data will look thin.
• Treat low counts cautiously until you have ruled out outdated clients and blocked telemetry.
• Scan names before sharing reports externally.