Which integrations are available for this server?

Provides tools for listing and getting Kubernetes clusters, node pools, flavors, and versions on Magalu Cloud.

How do I use mcp-mgccli?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@mcp-mgccli List my virtual machines in northeast" 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.

de en es ja ko pt ru zh

mcp-mgccli

by hedibertosilva

Overview Schema Related Servers Score Discussions

Python

Local

mcp-mgccli

MCP server for read-only queries on Magalu Cloud via mgc CLI.

Exposes 7 MCP tools (one per product), covering list and get operations. All authentication is handled via API key — no credentials in the code.

Requirements

Python 3.11+
mgc CLI v0.54.0+ in PATH
Magalu Cloud API key with read permissions

Related MCP server: cloud-chat-assistant

Installation

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

Configuration

Copy the example file and fill in your 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)

Integration with Claude Code

The server is started automatically via start-mcp.sh, which loads the .env. To register:

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

Or add it manually to ~/.claude.json:

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

Integration with Claude Desktop

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

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

Available Tools

Tool	Resources
`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 and rules are sub-resources — they require parent_id for list:

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

Common Parameters

Parameter	Type	Description
`resource`	string	Resource to query (see table above)
`action`	`list`	`get`	Operation
`id`	string	Resource ID (required for `get`)
`region`	string	`br-ne1` or `br-se1` — overrides `MGC_REGION`
`parent_id`	string	Parent resource ID (only for `network` with `subnets`/`rules`)

Region Inference

Claude infers the region automatically from natural language:

Mention	Region
"northeast", "ne", "NE1"	`br-ne1`
"southeast", "se", "SE1"	`br-se1`

If the region is not mentioned and MGC_REGION is not set, Claude will ask before executing.

Usage Examples

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

Development

# 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.

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

D1.7/5.0

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

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

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-IO
io.github.DataAssistIO
Query your org's data in natural language — read-only MCP access to SQL, NoSQL, files & warehouses.
Search Databases
2
mcp-server A
ar.com.muovi
Read-only MCP server for Muovi, Argentina's trust-first local services marketplace (6 tools).
E-commerce & Retail
621
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 4 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 23 days ago (2026-08-12 11:42 UTC)
2
cloud-mcp
Cloud Platforms Command Line
LesterAJohn
A
license
Not graded
quality
B
maintenance
Wraps multiple cloud CLIs (AWS, GCP, Azure, OCI) into a unified command interface and exposes them as MCP tools for AI assistants.
Updated a month ago (2026-07-28 20:26 UTC)
16
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 6 months ago (2026-03-09 18:51 UTC)
10
2
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/hedibertosilva/mcp-mgccli'

If you have feedback or need assistance with the MCP directory API, please join our Discord server