- GitHub's Copilot usage metrics now show the configured names of an organisation's own skills, custom agents, MCP servers, slash commands and plugins, instead of 'other' or 'custom'.
- Each record lists up to 25 named entries, up from five. GitHub says the data comes from client telemetry and can undercount activity.
- Leaders can use the names as a starting list of internal AI tooling in use, then ask who owns each item.
Seats tell you who. Names tell you what.
A seat count shows which employees have an AI coding assistant. It does not show what their teams have taught that assistant to do. A GitHub changelog entry dated October 22 narrows that gap.
Until now, Copilot's usage reports dumped anything an organisation built itself into generic buckets labelled "other" or "custom". GitHub now reports each item by its configured name. Five kinds of item are covered: skills, custom agents, slash commands, plugins and servers that use the Model Context Protocol (MCP).
What a record looks like
The change sits in the Copilot usage metrics API, in enterprise and organisation reports. Each record carries five arrays whose names start with totals_by_: skill, custom_agent, mcp, slash_cmd and plugin. Every entry in those arrays is one named item, with an interaction_count and distinct use counts beside it.
The arrays used to hold five entries. They now hold up to 25. Activity beyond the listed entries is combined into a trailing "other" entry. GitHub says the larger cap shows more of the long tail of tools developers use. For a company with many small, team-built tools, the cap decides how much of that tail is visible by name.
GitHub says the counts are worked out the same way as before, so the labels are what changed. Names appear as configured, trimmed to 128 characters. A name that looks like a file path is still filed under the generic label. Some tooling will therefore stay anonymous.
Why the data can undercount
An MCP server is a small program that links an AI assistant to other tools or data through a shared protocol. A skill or custom agent is a bundle of instructions a team writes for the assistant. Both differ from one company to the next.
The names are collected on the developer's side, from four kinds of client. These are Copilot's command-line tool, the GitHub Copilot app, editors that connect through the Agent Client Protocol (ACP), such as JetBrains, and the Copilot SDK. Interactive command-line sessions have no stated minimum version. Prompt mode, the app and ACP integrations need Copilot CLI 1.0.97 or later. The SDK needs v1.0.21 or later.
An IDE's built-in chat telemetry does not supply names. An IDE reports them only when its agent features run on SDK v1.0.21 or later.
Because the data comes from software on laptops, GitHub warns it can undercount. Outdated clients and blocked telemetry are its two examples. Its advice is to read the numbers as trends and adoption, not exact accounting.
The idea: the licence is no longer the whole picture
GitHub presents the change as an adoption aid. Administrators can see which internal tools developers actually use, watch uptake after a launch and aim training where it is needed. GitHub notes that the customisations most valuable to an organisation are often ones its own teams made.
Here is our interpretation. The value and the risk of AI coding tools may sit less in the licence and more in what gets attached to it. An assistant connected to an internal system through an MCP server can become part of your infrastructure. A seat count cannot show that.
Think of the step from counting laptops to listing installed software. The first number is easy to report. The second tells you what people can do. Named entries make a list of the second kind possible for Copilot.
One caution. The metrics show that something was used. They do not show what a tool can reach, who approved it or whether anyone reviewed it. A name in a report is where the questions start.
Other limits to keep in view
Names appear only for report days processed after the release. Usage from before the release stays under "other" or "custom", so you cannot trace a spring rollout's early adoption by name.
Names can also reveal internal projects. GitHub advises reviewing them before sharing reports outside the organisation.
What to ask your team
Enterprise owners, billing managers, organisation owners and anyone with a custom role granting "View Copilot Metrics" can open the reports. The Copilot usage metrics policy must also be switched on. Check both first.
Then put four questions to the people who run developer tooling.
First, which named MCP servers and custom agents appear, and does each have a named owner? Second, which are on an approved list, and which are not? Third, how many developers use prompt mode, the app or ACP integrations on CLI 1.0.97 or later, and the SDK on v1.0.21 or later? GitHub says outdated clients can cause undercounting. Fourth, is the report reviewed after each internal rollout, so adoption is measured and not assumed?
A seat count says how many people have the tool. A named list begins to show what they built with it. Leaders who can read that list can ask sharper questions about trust, usage and ownership. Cost questions would need other data.
Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: GitHub.
