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 서버입니다.

list 및 get 작업을 포함하는 7개의 MCP 도구(제품당 하나)를 노출합니다. 모든 인증은 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 통합

서버는 .env를 로드하는 start-mcp.sh를 통해 자동으로 시작됩니다. 등록하려면:

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