Copilot MCP Usage Metrics: Why Connection Counts Are Not Tool Calls
Usage for an internal MCP server jumped in the Copilot report the same week users complained they couldn’t connect. What is that number actually counting?
- Copilot reports can identify internal skills, custom agents and MCP servers by configured name.
- MCP interaction counts include successful and failed connection attempts, not calls over an existing connection.
- Per-user reports show recorded activity; a missing name does not establish zero usage.
A busy connection counter is not a tool-call counter
A rising MCP interaction_count means more connection or reconnection attempts were recorded. Calls through an already connected server do not increment it. Failed attempts do, so a high count alone cannot establish productive tool use.
GitHub's October 22 update makes internal customizations identifiable by their configured names. It changes visibility without redefining the underlying events.
| Category | Event counted |
|---|---|
| Skill | An invocation |
| Custom agent | A start |
| MCP server | A connection or reconnection attempt, successful or failed |
| Plugin | An associated skill invocation |
The field reference also makes plugin interactions a subset of skill interactions. Adding them double-counts activity. Ranking every category by the same raw number compares different events.
Check the reporting path before treating other as unused
Names appear on report days processed after the feature's deployment; earlier days are not backfilled. File-path-like names and unavailable names can still be grouped under other or custom.
Supported paths include CLI sessions, the Copilot app, ACP integrations and the SDK. Prompt mode, the app and ACP require CLI 1.0.97 or later; the SDK requires 1.0.21 or later. An overridden SDK CLI must also meet the 1.0.97 minimum. An IDE's built-in chat telemetry does not report these names.
Per-user and aggregate one-day reports, plus aggregate 28-day day_totals, retain up to 25 named entries per category and record. Remaining activity goes into an additional other entry.
Use the user report to see whose activity was recorded
Customization metrics are API-only. With the usage metrics policy enabled and the appropriate owner or metrics-viewing role, request the user-level report for your scope:
GET /orgs/{org}/copilot/metrics/reports/users-1-day?day=YYYY-MM-DD
GET /enterprises/{enterprise}/copilot/metrics/reports/users-1-day?day=YYYY-MM-DDThe response provides download_links and report_day. Download the NDJSON through the expiring signed links, then inspect each user's totals_by_skill or totals_by_mcp. These are processed daily reports, not a live event feed.
An aggregate distinct_mcp_use_count counts different server identifiers, not the people using them. It cannot substitute for the user records.
Follow the signal to the underlying workflow
GitHub's interpretation guide recommends looking for names appearing across multiple users. Unexpected MCP connection activity calls for checking configuration and rollout, then consulting developer feedback or other internal data about ongoing tool use.
Outdated clients, blocked telemetry and retained-entry limits can hide activity. These reports help identify adoption patterns; they are not a complete audit proving that only approved tools ran.
Start with the named customization, identify the event being counted, and then ask what work it supported. That sequence makes a rollout report useful without mistaking repeated connections for repeated successful tasks.