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

用于通过 mgc CLI 对 Magalu Cloud 进行只读查询的 MCP 服务器。

提供 7 个 MCP 工具（每个产品一个），涵盖 list 和 get 操作。所有身份验证均通过 API 密钥完成 — 代码中不包含任何凭据。

要求

Python 3.11+
PATH 中需包含 mgc CLI v0.54.0+
具有读取权限的 Magalu Cloud API 密钥

Related MCP server: cloud-chat-assistant

安装

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

配置

复制示例文件并填写您的 API 密钥：

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)

与 Claude Code 集成

服务器通过 start-mcp.sh 自动启动，该脚本会加载 .env 文件。注册方式如下：

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

或者手动添加到 ~/.claude.json：

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

与 Claude Desktop 集成

编辑 ~/Library/Application Support/Claude/claude_desktop_config.json (macOS) 或 %APPDATA%\Claude\claude_desktop_config.json (Windows)：

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

可用工具

工具	资源
`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 和 rules 是子资源 — list 操作需要 parent_id：

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

通用参数

参数	类型	描述
`resource`	string	要查询的资源（见上表）
`action`	`list`	`get`	操作
`id`	string	资源 ID（`get` 操作必需）
`region`	string	`br-ne1` 或 `br-se1` — 覆盖 `MGC_REGION`
`parent_id`	string	父资源 ID（仅限 `network` 的 `subnets`/`rules`）

区域推断

Claude 会根据自然语言自动推断区域：

提及内容	区域
"nordeste", "ne", "NE1"	`br-ne1`
"sudeste", "se", "SE1"	`br-se1`

如果未提及区域且未定义 MGC_REGION，Claude 会在执行前询问。

使用示例

"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"

开发

# 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