de en es ja ko pt ru zh

mcp-mgccli

Name: mcp-mgccli
Author: hedibertosilva

by hedibertosilva

Overview Schema Source Related Servers Discussions Admin

Python

Local

mcp-mgccli

MCP server para consultas de leitura na Magalu Cloud via mgc CLI.

Expõe 7 tools MCP (um por produto), cobrindo operações list e get. Toda autenticação é feita via API key — nenhuma credencial no código.

Requisitos

Python 3.11+
mgc CLI v0.54.0+ no PATH
API key Magalu Cloud com permissões de leitura

Related MCP server: cloud-chat-assistant

Instalação

pip install -e /caminho/para/mcp-mgccli

Configuração

Copie o arquivo de exemplo e preencha sua API key:

cp .env.example .env

.env:

MGC_API_KEY=sua-api-key-aqui
MGC_REGION=br-ne1   # opcional — br-ne1 ou br-se1
MGC_TIMEOUT=30      # opcional — timeout em segundos (default: 30)

Integração com Claude Code

O servidor já é iniciado automaticamente via start-mcp.sh, que carrega o .env. Para registrar:

claude mcp add --scope user mgc /caminho/para/mcp-mgccli/start-mcp.sh

Ou adicione manualmente em ~/.claude.json:

{
  "mcpServers": {
    "mgc": {
      "command": "/caminho/para/mcp-mgccli/start-mcp.sh"
    }
  }
}

Integração com Claude Desktop

Edite ~/Library/Application Support/Claude/claude_desktop_config.json (macOS) ou %APPDATA%\Claude\claude_desktop_config.json (Windows):

{
  "mcpServers": {
    "mgc": {
      "command": "/caminho/para/mcp-mgccli/start-mcp.sh"
    }
  }
}

Tools Disponíveis

Tool	Recursos
`block_storage`	volumes, snapshots, volume-types, schedulers
`virtual_machine`	instances, images, machine-types, snapshots
`kubernetes`	cluster, nodepool, flavor, version
`dbaas`	instances, clusters, replicas, snapshots, engines, instance-types, parameter-groups
`network`	vpcs, security-groups, public-ips, ports, subnetpools, subnets¹, rules¹
`container_registry`	registries, repositories, images, proxy-caches
`audit`	events, event-types

¹ subnets e rules são subrecursos — exigem parent_id para list:

subnets list: parent_id=<vpc-id>
rules list: parent_id=<security-group-id>

Parâmetros comuns

Parâmetro	Tipo	Descrição
`resource`	string	Recurso a consultar (ver tabela acima)
`action`	`list` \| `get`	Operação
`id`	string	ID do recurso (obrigatório para `get`)
`region`	string	`br-ne1` ou `br-se1` — sobrescreve `MGC_REGION`
`parent_id`	string	ID do recurso pai (apenas `network` com `subnets`/`rules`)

Inferência de região

O Claude infere a região automaticamente a partir de linguagem natural:

Menção	Região
"nordeste", "ne", "NE1"	`br-ne1`
"sudeste", "se", "SE1"	`br-se1`

Se a região não for mencionada e MGC_REGION não estiver definido, o Claude pergunta antes de executar.

Exemplos de uso

"Liste minhas VMs no nordeste"
"Quais volumes existem no sudeste?"
"Mostre detalhes do cluster Kubernetes abc-123"
"Liste os security groups da região br-ne1"
"Quais subnets existem na VPC 7211a812-f159-4757-a6ba-c09933a5f6d8?"
"Liste as regras do security group bf8743af-f14b-4f31-917e-8e8160cff838"

Desenvolvimento

# instalar em modo editável
pip install -e .

# rodar testes
python -m pytest tests/ -v

Available Tools

7 tools

auditB

Consulta eventos de Audit da Magalu Cloud (somente leitura).

Recursos: events, event-types. Audit é global — sem parâmetro de região.

ParametersJSON Schema

Name	Required	Description	Default
`resource`	Yes
`action`	Yes
`id`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

B3.4/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden. It correctly indicates read-only behavior and global scope, but lacks details on pagination, rate limits, or how the optional 'id' parameter affects behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences and contains no extraneous information. It is well-front-loaded but could add more details without becoming verbose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the existence of an output schema and the tool's simplicity, the description provides the essential scope (read-only, global). However, it lacks guidance on when to use 'list' vs 'get' or the role of 'id', leaving the agent with incomplete context.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate. It partially does by listing the allowed resources, matching the 'resource' enum. However, it does not explain the 'action' or 'id' parameters, which are necessary for correct invocation.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it's for consulting Audit events (read-only) and lists the specific resources (events, event-types). This effectively distinguishes it from sibling tools which focus on other cloud services.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description mentions it's read-only and global (no region parameter), providing some context. However, it does not explicitly state when to use this tool versus alternatives or provide exclusions, leaving room for ambiguity.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

block_storageD

ParametersJSON Schema

Name	Required	Description	Default
`resource`	Yes
`action`	Yes
`id`	No
`region`	No
`expand`	No
`name`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

D1/5.0

Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

container_registryD

ParametersJSON Schema

Name	Required	Description	Default
`resource`	Yes
`action`	Yes
`id`	No
`region`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

D1/5.0

Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

dbaasD

ParametersJSON Schema

Name	Required	Description	Default
`resource`	Yes
`action`	Yes
`id`	No
`region`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

D1/5.0

Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

kubernetesD

ParametersJSON Schema

Name	Required	Description	Default
`resource`	Yes
`action`	Yes
`id`	No
`region`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

D1/5.0

Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

networkD

ParametersJSON Schema

Name	Required	Description	Default
`resource`	Yes
`action`	Yes
`id`	No
`region`	No
`parent_id`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

D1/5.0

Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

virtual_machineD

ParametersJSON Schema

Name	Required	Description	Default
`resource`	Yes
`action`	Yes
`id`	No
`region`	No
`expand`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

D1/5.0

Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

7 tool updatesv0.1.0Apr 25, 2026
- First observedaudit
- First observedblock_storage
- First observedcontainer_registry
- First observeddbaas
- First observedkubernetes
- First observednetwork
- First observedvirtual_machine

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

D1.7/5.0

Scored 2026-04-25 04:05 across 7 tools

Disambiguation1/5

Six of the seven tools have no descriptions, making it impossible to distinguish their specific functions beyond the generic resource names. Only 'audit' has a description, but the others are ambiguous.

Naming Consistency4/5

All tool names are single-word, lowercase nouns (e.g., 'audit', 'network'), following a consistent pattern. However, they lack verbs, which is unconventional for MCP tool naming.

Tool Count4/5

With 7 tools, the count is reasonable for a cloud service provider's MCP interface, covering several major resource categories without being excessive.

Completeness2/5

The set covers core services like compute, storage, networking, and databases, but without descriptions, it's unclear what operations are available. The lack of detail suggests significant gaps in the tool surface.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

Synlake
ai.synlake
Unified API to query AWS, GCP, Azure and generate Terraform/CLI execution kits for AI agents.
Cloud Platforms Developer Tools Agent Orchestration
2
Dataassist-IOOAuth
io.github.DataAssistIO
Query your org's data in natural language — read-only MCP access to SQL, NoSQL, files & warehouses.
Search Databases
2
llm-orchestration-agent-2
ai.getvda
MCP-Native LLM Orchestration Agent
Agent Orchestration AI & Machine Learning
1
mcp A
com.googleapis.compute
Provides capabilities that let LLM agents perform a range of infrastructure management tasks.
Cloud Platforms Networking & Infrastructure OS Automation
292

Related MCP Servers

oci-mcp-server
Cloud Platforms Developer Tools
sauryadas
A
license
Not graded
quality
D
maintenance
Enables natural-language access to Oracle Cloud Infrastructure resources, allowing users to query compute instances, OKE clusters, networking, and Object Storage via MCP tools.
Updated 5 months ago (2026-05-16 01:45 UTC)
MIT
cloud-chat-assistant
AI & Machine Learning Cloud Platforms
techempower-org
F
license
Not graded
quality
C
maintenance
Multi-cloud MCP server that exposes cloud AI models as tools for AI CLI agents, supporting streaming, conversation history, parallel multi-model queries, and dynamic model discovery.
Updated 2 months ago (2026-08-12 11:42 UTC)
2
-
cloud-mcp
Cloud Platforms Command Line
LesterAJohn
A
license
Not graded
quality
C
maintenance
Wraps multiple cloud CLIs (AWS, GCP, Azure, OCI) into a unified command interface and exposes them as MCP tools for AI assistants.
Updated 3 months ago (2026-07-28 20:26 UTC)
8 npm
MIT
Foundry Agents MCP Server
denniszielke
A
license
A
quality
D
maintenance
Exposes Azure AI Foundry agents, workflows, and AI Search vector-database capabilities as MCP tools, enabling natural language interaction with agents, semantic search, and index management.
Updated 7 months ago (2026-03-09 18:51 UTC)
10
2
MIT