Interacts with GitHub's internal API endpoints to retrieve service-specific usage metrics and account quotas.
Provides tools to monitor GitHub Copilot usage, including real-time statistics, interaction quotas, and account limits.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@GitHub Copilot Usage MCP Server how many premium interactions do I have left?"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Um servidor MCP (Model Context Protocol) para obter informações de uso atual do GitHub Copilot, incluindo cotas, limites e estatísticas de uso.
npx -y copilot-usage-mcp# Clone o repositório
git clone <url-do-repositorio>
cd copilot-usage-mcp
# Instale as dependências
npm install
# Execute o servidor
npx -y -p "path_do_projeto" copilot-usage-mcpRelated MCP server: copilot-status-mcp
Para usar este MCP server, você precisa do token de acesso do GitHub Copilot. Existem algumas formas de obtê-lo:
Abra o VS Code com a extensão GitHub Copilot instalada
Pressione Ctrl+Shift+P (ou Cmd+Shift+P no Mac)
Digite "Developer: Open Webview Developer Tools"
Na aba Network, faça uma requisição que utilize o Copilot
Procure por requisições para api.github.com/copilot_internal
Copie o valor do header Authorization (remova o "token " do início)
Você pode usar ferramentas como mitmproxy ou interceptar requisições do VS Code para capturar o token.
Importante: o token obtido por esses métodos é temporário e expirará após algumas horas. Você precisará renová-lo periodicamente.
As extensões oficiais do Copilot para várias IDEs (incluindo Neovim com copilot.lua e a suíte JetBrains) armazenam as informações de autenticação em um arquivo JSON local. Você pode extrair o token diretamente deste arquivo.
Localize e abra o arquivo: O arquivo geralmente está localizado em ~/.config/github-copilot/apps.json.
Encontre o token: Dentro do arquivo JSON, procure por uma chave chamada oauth_token. O valor associado a essa chave é o seu token de acesso.
Você pode usar o seguinte comando no terminal para extrair o token rapidamente (requer a ferramenta jq):
cat ~/.config/github-copilot/apps.json | jq -r '.[].oauth_token'Esse token não é temporário e pode continuar sendo usado, para revoga-lo acesse:https://github.com/settings/apps/authorizations
claude mcp add --scope user copilot-usage --env COPILOT_TOKEN="seu_token_aqui" -- npx -y copilot-usage-mcpgemini mcp add copilot-usage npx -y copilot-usage-mcp -e COPILOT_TOKEN="seu_token_aqui"Adicione ao seu arquivo de configuração do Claude Desktop (claude_desktop_config.json):
{
"mcpServers": {
"copilot-usage": {
"command": "npx",
"args": ["-y", "copilot-usage-mcp"],
"env": {
"COPILOT_TOKEN": "seu_token_aqui"
}
}
}
}get_copilot_usageObtém informações brutas de uso do GitHub Copilot em formato JSON.
get_copilot_usage_formattedObtém informações de uso do GitHub Copilot formatadas de forma legível em português.
get_copilot_usage_summaryObtém um resumo conciso das informações principais de uso premium do GitHub Copilot.
Depois de configurado, você pode usar o MCP server em conversas com seu agent AI:
"Verifique meu uso atual do GitHub Copilot""Quanto restam das minhas interações premium do Copilot?""Mostre meu status de cota do GitHub Copilot de forma detalhada"copilot-usage-mcp/
├── index.js # Ponto de entrada principal
├── package.json # Dependências e configuração do NPM
├── package-lock.json # Lockfile do NPM
├── README.md # Este arquivo
├── LICENSE # Licença MIT
├── .gitignore # Arquivos ignorados pelo Git
├── src/ # Código fonte principal
│ ├── server.js # Servidor MCP principal
│ ├── api.js # Lógica da API do GitHub Copilot
│ └── formatter.js # Utilitários de formatação
└── test/ # Testes
├── index.test.js
├── api.test.js
├── formatter.test.js
├── server.test.js
└── mocks/
├── handlers.js
└── server.js@modelcontextprotocol/sdk: SDK oficial do MCP
⚠️ Este servidor utiliza um endpoint interno não documentado do GitHub (copilot_internal/user)
Não é uma API oficial: O endpoint pode ser alterado ou removido sem aviso
Token temporário: O token expira e precisa ser renovado periodicamente (a não ser o utilizado pelo nvim ou jetbrains)
Rate limiting: Pode haver limites de taxa nas requisições
Termos de uso: Use por sua conta e risco, considerando os termos de serviço do GitHub
Fork o projeto
Crie uma branch para sua feature (git checkout -b feature/AmazingFeature)
Commit suas mudanças (git commit -m 'Add some AmazingFeature')
Push para a branch (git push origin feature/AmazingFeature)
Abra um Pull Request
Este projeto está licenciado sob a licença MIT - veja o arquivo LICENSE para detalhes.
Este projeto é não oficial e não está afiliado ao GitHub ou à Microsoft. Use por sua conta e risco.
Obtém informações de uso atual do GitHub Copilot, incluindo cotas e limites, dados originais da API
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It describes a read operation returning usage data, which implies no side effects. However, it does not explicitly state it is read-only or mention authentication or rate limits. For a simple get tool, this is adequate but not thorough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no unnecessary words. It is front-loaded with the key purpose and includes specific details about the data type.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, no output schema), the description comprehensively explains the tool's purpose and return content. No additional information is needed for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters and schema coverage is 100% vacuously. The description adds meaning by detailing what the tool returns (usage, quotas, limits, original API data), which goes beyond the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves GitHub Copilot usage information including quotas and limits, and specifies it returns original API data. This effectively differentiates it from siblings like get_copilot_usage_formatted and get_copilot_usage_summary.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus the sibling tools (formatted, summary). An agent would not know which one to select based on the description alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Obtém informações de uso do GitHub Copilot formatado humanizado
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, and the description does not disclose behavioral aspects such as read-only nature, rate limits, authentication requirements, or side effects. The verb 'gets' suggests a read operation, but this is not confirmed, leaving the agent with minimal behavioral insight.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that efficiently conveys the core purpose. Every word is justified, and there is no extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of an output schema, the description should compensate by explaining the return format or content. The phrase 'humanized format' is vague and does not clarify what data is returned. The tool is simple, but the description remains incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so the schema coverage is 100% by default. The description adds no parameter details, but none are needed. Per guidelines, 0 parameters yields a baseline of 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that it retrieves GitHub Copilot usage information in a humanized format, specifying the verb 'gets' and the resource. However, it does not differentiate from sibling tools get_copilot_usage and get_copilot_usage_summary, which may overlap in function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like get_copilot_usage or get_copilot_usage_summary. The description implies a preference for human-readable output, but this is not explicitly stated as a usage condition.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Obtém um resumo conciso do uso do GitHub Copilot com informações principais, como o restante da quota premium (economiza tokens)
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description mentions 'saves tokens' hinting at low cost but doesn't disclose auth requirements, side effects, or error scenarios. Limited behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence conveying purpose and key output information. Efficient for a simple tool, though language may be an issue for non-Portuguese agents.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema and no annotations; description lacks details about return format, prerequisites, or edge cases. For a parameterless tool, it is sparse.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters in the schema; baseline score for zero-parameter tool as per calibration. Description adds no parameter info, but none needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly indicates it retrieves a concise summary of GitHub Copilot usage, mentioning specific information like premium quota. Differentiates from siblings (get_copilot_usage and get_copilot_usage_formatted) through 'concise summary'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus the sibling tools. The description implies it is for a quick overview, but lacks direct comparison or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v2.1.5get_copilot_usageget_copilot_usage_formattedget_copilot_usage_summaryThe three tools all retrieve GitHub Copilot usage data, but each targets a different output format (raw, human-readable, summary). While distinct, an agent might still be uncertain which to use for a given task, though descriptions clarify the differences.
All tool names follow a consistent 'get_copilot_usage' prefix with suffixes that clearly indicate the output type (empty, _formatted, _summary). This pattern is predictable and easy to understand.
With exactly 3 tools, the count is well-scoped for a focused server that provides usage information in three formats. It covers the necessary variations without being excessive or insufficient.
The surface covers the primary use case of retrieving Copilot usage data, offering different formats. Minor gaps exist, such as the absence of historical data or team-specific queries, but these are not essential for the stated purpose.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
The Cortex MCP server provides read-only access to real-time engineering context from the Cortex developer portal, allowing AI coding assistants to answer natural language questions about your organization's catalog (microservices, libraries, domains, teams, infrastructure), scorecards (engineering standards and best practices), initiatives (goals and deadlines), and Engineering Intelligence metrics. It includes tools for querying documentation, tracking personal entities, and accessing AI-assisted insights across the entire Cortex ecosystem.
An MCP server that gives your AI access to the source code and docs of all public github repos
Hosted MCP server for live public-data APIs and Skills for AI agents.
Use AI models for chat, image, and video generation from Claude Code and other MCP hosts.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/lucasliet/copilot-usage-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
