Provides tools for managing Alibaba Cloud resources, including ECS, VPC, RDS, RAM, ACK, SLB, and a universal API invoker for all services.
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., "@Alibaba Cloud MCP Server list my ECS instances"
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.
A comprehensive, high-performance Model Context Protocol (MCP) server for managing Alibaba Cloud resources.
This server enables AI assistants (like Claude, Cursor, and others) to seamlessly interact with Alibaba Cloud infrastructure using natural language. It features a Hybrid Architecture:
Explicit Service Tools: Pre-configured, typed handlers for the most common services (ECS, VPC, RDS, RAM, ACK, SLB) to ensure rapid, error-free AI interactions.
Universal API Invoker: A dynamic tool built on @alicloud/pop-core that can invoke any of the 10,000+ API endpoints across all Alibaba Cloud services, giving you true 100% cloud management coverage.
🚀 Zero-Config Universal Management: Dynamically call any Alibaba Cloud RPC/ROA API.
📦 Explicit Typed Tools:
ECS: Manage Compute Instances (ecs_list_instances, ecs_start_instance)
VPC: Manage Networking (vpc_list, vpc_create)
RDS: Manage Databases (rds_list_instances)
RAM: Manage IAM & Security (ram_list_users)
ACK: Manage Kubernetes Clusters (ack_list_clusters)
SLB: Manage Load Balancers (slb_list)
🐳 Docker Ready: Run safely in an isolated container.
🛡️ Secure: Uses Zod for strict parameter validation and environment variables for credentials.
Related MCP server: MCP Cloud Services Server
Node.js 18+ (if running locally)
Docker (optional, for containerized execution)
Alibaba Cloud Access Key ID and Secret with appropriate IAM permissions.
Clone the repository and install dependencies:
npm installBuild the TypeScript source:
npm run buildCreate a .env file in the root directory:
ALIBABA_CLOUD_ACCESS_KEY_ID="your_access_key"
ALIBABA_CLOUD_ACCESS_KEY_SECRET="your_access_secret"
ALIBABA_CLOUD_REGION_ID="cn-hangzhou"Build the Docker image:
docker build -t alibaba-cloud-mcp .To integrate this server with Claude Desktop, add the following to your claude_desktop_config.json (usually located at %APPDATA%\Claude\claude_desktop_config.json on Windows or ~/Library/Application Support/Claude/claude_desktop_config.json on Mac):
If using Node.js locally:
{
"mcpServers": {
"alibaba-cloud": {
"command": "node",
"args": ["/absolute/path/to/Alibaba_cloud_MCP_server/dist/index.js"],
"env": {
"ALIBABA_CLOUD_ACCESS_KEY_ID": "your_access_key",
"ALIBABA_CLOUD_ACCESS_KEY_SECRET": "your_access_secret",
"ALIBABA_CLOUD_REGION_ID": "cn-hangzhou"
}
}
}
}If using Docker:
{
"mcpServers": {
"alibaba-cloud": {
"command": "docker",
"args": [
"run",
"-i",
"--rm",
"-e", "ALIBABA_CLOUD_ACCESS_KEY_ID",
"-e", "ALIBABA_CLOUD_ACCESS_KEY_SECRET",
"-e", "ALIBABA_CLOUD_REGION_ID",
"alibaba-cloud-mcp"
],
"env": {
"ALIBABA_CLOUD_ACCESS_KEY_ID": "your_access_key",
"ALIBABA_CLOUD_ACCESS_KEY_SECRET": "your_access_secret",
"ALIBABA_CLOUD_REGION_ID": "cn-hangzhou"
}
}
}
}Note: Restart Claude Desktop after updating the configuration.
⚠️ IMPORTANT: This MCP server is incredibly powerful, especially due to the
aliyun_invoke_apitool which can manage any resource. Always adhere to the Principle of Least Privilege. Ensure that the IAM/RAM user associated with your Access Keys only has the minimum permissions necessary for the tasks you intend the AI to perform.
Built using:
@modelcontextprotocol/sdk
@alicloud/pop-core
zod for validation
TypeScript
List Container Service for Kubernetes (ACK) clusters.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries full burden. It only states 'List' without disclosing read-only nature, pagination, permissions, or other behavioral traits. The description is insufficiently transparent.
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 concise sentence of 9 words, front-loaded with the core action. No unnecessary 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?
For a tool with no parameters and no output schema, the description is adequate but minimal. It does not clarify scope (e.g., region, account) or return structure, leaving some gaps for an agent.
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 no parameters, and schema description coverage is 100% (empty schema). The description adds no meaning beyond the schema, so baseline 3 applies.
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 explicitly states the verb 'List' and the resource 'Container Service for Kubernetes (ACK) clusters', making the tool's purpose very clear. It distinguishes from sibling tools which target different services (e.g., ecs, ram, rds).
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 vs alternatives is provided. The purpose is implied as it's a list tool for a specific service, but the description lacks when-not-to-use or exclusionary context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Invoke ANY Alibaba Cloud OpenAPI endpoint dynamically. This tool allows you to manage ALL of Alibaba Cloud. Use the OpenAPI documentation to find the correct endpoint, apiVersion, and action. Note: RPC requests are most common.
| Name | Required | Description | Default |
|---|---|---|---|
| endpoint | Yes | The API endpoint (e.g., 'https://ecs.aliyuncs.com' or 'https://vpc.aliyuncs.com') | |
| apiVersion | Yes | The API version (e.g., '2014-05-26') | |
| action | Yes | The action name (e.g., 'DescribeInstances', 'CreateVpc') | |
| parameters | No | The parameters for the action, as a JSON object. | |
| method | No | HTTP Method (POST/GET). Defaults to POST. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It only mentions 'RPC requests are most common' as a behavioral hint, but lacks details on authentication, rate limits, error handling, or response format. This is insufficient for a tool that can invoke any API across all of Alibaba Cloud.
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?
Three sentences efficiently convey the tool's purpose, scope, and key usage hint (RPC common). Every sentence earns its place with no redundancy or filler.
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 broad scope (all Alibaba Cloud) and no output schema, the description is somewhat incomplete. It does not explain return format, error handling, or complex parameter usage, but directs to OpenAPI docs. Adequate but not thorough for a tool of this scale.
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 100% coverage with descriptions for all 5 parameters. The description adds no new parameter semantics beyond directing users to use OpenAPI documentation, which is helpful but does not exceed the baseline expected from schema coverage alone.
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 'Invoke ANY Alibaba Cloud OpenAPI endpoint dynamically' and 'manage ALL of Alibaba Cloud', making the tool's purpose unmistakable. It distinguishes from sibling tools that are specific operations like ecs_list_instances or vpc_create.
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?
The description advises to 'Use the OpenAPI documentation to find the correct endpoint, apiVersion, and action', which implies when to use it—for APIs not covered by specific tools. However, it does not explicitly state when not to use it or provide alternative tools, missing some exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List Alibaba Cloud ECS instances in the current region.
| Name | Required | Description | Default |
|---|---|---|---|
| regionId | No | The region ID (e.g., 'cn-hangzhou'). Defaults to ALIBABA_CLOUD_REGION_ID. | |
| pageSize | No | Number of results per page. Default 10. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description must disclose behavior. It only says 'list' implying read-only but does not explicitly confirm safety, pagination details, or rate limits. The pagination parameter (pageSize) is not explained in terms of behavior.
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, no fluff. However, it lacks detail that could be added without sacrificing conciseness, such as mentioning pagination scope.
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 full schema coverage and no output schema, description is adequate but leaves gaps: no mention of pagination behavior, default region handling, or return format.
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?
Input schema provides 100% coverage for both parameters with descriptions. The tool description adds no additional semantic value beyond the schema, warranting baseline score.
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 verb (List) and resource (ECS instances) and specifies scope (current region). It effectively distinguishes from sibling tools like ack_list_clusters and rds_list_instances.
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, nor are prerequisites or context mentioned. Usage is purely inferred from the description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Start an Alibaba Cloud ECS instance.
| Name | Required | Description | Default |
|---|---|---|---|
| instanceId | Yes | The ID of the instance to start. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description only says 'start' without disclosing behavioral details like idempotency, state requirements, or error conditions.
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?
A single, direct sentence with no wasted words, fully front-loaded.
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?
For a simple start operation with one parameter and no output schema, the description is adequate but omits state prerequisites and outcome details.
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?
Schema coverage is 100% with one parameter 'instanceId' fully described. The description adds no extra meaning beyond the 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 verb 'Start' and the resource 'Alibaba Cloud ECS instance', distinguishing it from sibling tools like ecs_list_instances which list instances.
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 on when to use this tool versus alternatives, nor any preconditions (e.g., instance must be stopped) are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List IAM/RAM users.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It only states that it lists users, but does not mention any side effects, permissions needed, pagination, or other behavioral traits. This is insufficient for an agent to understand potential consequences.
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 concise sentence that directly states the tool's purpose. It is front-loaded and efficient, though it could potentially include more detail without losing conciseness.
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 is minimally sufficient. However, it lacks context about the output format or any filtering capabilities, which could be helpful for an agent. It is adequate but not comprehensive.
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 baseline is 4. The description adds no parameter-specific meaning beyond the empty schema, but this is acceptable as there are no parameters to describe.
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 action ('List') and the resource ('IAM/RAM users'), which distinguishes it from sibling tools like ecs_list_instances or rds_list_instances. The verb+resource combination is specific and unambiguous.
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. The description does not include any context about prerequisites, limitations, or scenarios where other tools would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List RDS instances.
| Name | Required | Description | Default |
|---|---|---|---|
| regionId | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behaviors itself. It only states it lists instances but lacks information on permissions, side effects, rate limits, or pagination. The read-only nature is implicit but not confirmed.
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 with no unnecessary words. It is maximally concise, though this brevity may sacrifice completeness.
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 simplicity (1 parameter, no output schema), the description is minimally adequate but omits critical context like output format, pagination details, or any filtering capabilities. It lacks completeness for effective use.
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 single parameter regionId has no description in the schema (coverage 0%) and is not explained in the tool description. The description adds no meaning beyond the parameter name.
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 'List RDS instances' is clear and specific: it identifies the verb 'List' and the resource 'RDS instances', which distinguishes it from sibling tools like ecs_list_instances or ack_list_clusters.
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?
The description provides no guidance on when to use this tool versus alternatives, such as ecs_list_instances. There is no mention of prerequisites, context, or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List Server Load Balancers (SLB).
| Name | Required | Description | Default |
|---|---|---|---|
| regionId | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. It merely states 'List' without mentioning safety, permissions, side effects, or limits such as pagination or default scope.
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 very short and front-loaded, which is good for quick scanning. However, it is too minimal; it could include region filtering information without adding much length.
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 has one optional parameter, no output schema, and no annotations, the description fails to explain the region parameter, return format, default behavior (list all or paginated), or any constraints. It is severely 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?
The input schema has one parameter (regionId) with 0% schema description coverage. The description does not mention this parameter or its purpose (filtering by region), leaving the agent without guidance on a critical aspect of usage.
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 action ('List') and the resource ('Server Load Balancers'), making the tool's purpose immediately understandable. However, it could be more specific by mentioning the optional region filtering, which would differentiate it from other list tools.
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 on when to use this tool versus alternatives like ecs_list_instances or ack_list_clusters. The agent has no context for selecting this over similar list operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a Virtual Private Cloud (VPC).
| Name | Required | Description | Default |
|---|---|---|---|
| regionId | No | ||
| cidrBlock | Yes | e.g. 192.168.0.0/16 | |
| vpcName | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must convey behavioral traits but only states the action 'create'. Missing critical details: idempotency, permissions required, potential overwrites, or error conditions (e.g., duplicate VPC names).
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 extremely short (5 words), but this underspecifies the tool. Conciseness should not sacrifice essential context; here it provides only the bare action.
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 3 parameters, no output schema, and no annotations, the description is grossly inadequate. It fails to explain parameter usage, return behavior, or any side effects, leaving the agent with minimal actionable guidance.
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?
Input schema coverage is just 33% (only cidrBlock has an example description). The tool description adds no parameter information, leaving regionId and vpcName completely unexplained.
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 'Create a Virtual Private Cloud (VPC)' uses a specific verb and resource, and distinguishes from sibling tools which are primarily list/describe operations (e.g., vpc_list) or other actions like ecs_start_instance.
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, prerequisites, or scenario-specific instructions. The description is purely functional.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List Virtual Private Clouds (VPCs).
| Name | Required | Description | Default |
|---|---|---|---|
| regionId | No | ||
| pageSize | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits such as read-only nature, pagination, or authentication requirements, leaving the agent uninformed beyond the basic operation.
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 extremely short (2 words of substance), which is concise but sacrifices essential information, making it less useful than a slightly longer but more complete explanation.
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?
For a simple list operation with optional filters, the description omits return format, parameter explanations, and any edge-case behavior, leaving significant gaps for effective agent use.
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?
With 0% schema description coverage and no parameter details in the description, the agent has no insight into the meaning, constraints, or usage of the two optional parameters (regionId, pageSize).
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 'List Virtual Private Clouds (VPCs)' uses a specific verb and resource, clearly distinguishing it from sibling tools like vpc_create and other resource-listing tools such as ecs_list_instances.
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?
The description provides no guidance on when to use this tool versus alternatives, nor does it mention prerequisites or contextual triggers.
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.
v1.0.0ack_list_clustersaliyun_invoke_apiecs_list_instancesecs_start_instanceram_list_usersrds_list_instancesslb_listvpc_createvpc_listMost tools target distinct services (ECS, VPC, RDS, etc.), but the generic 'aliyun_invoke_api' can overlap with any specific tool, causing potential confusion. Within services, actions like 'ecs_list_instances' and 'ecs_start_instance' are clearly distinct.
Tools generally follow a service_verb_noun pattern (e.g., ecs_list_instances), but some omit the resource noun (slb_list, vpc_create) and 'aliyun_invoke_api' uses a different format, leading to inconsistency.
9 tools for a cloud provider is reasonable; the generic API invocation tool extends capability. However, the scope is broad, and a few more targeted tools could improve coverage without being excessive.
The tool set is very incomplete for most services—only list operations for RAM, RDS, SLB; no update, delete, or advanced actions. The generic API tool is a workaround but indicates significant gaps in native coverage.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Unified API to query AWS, GCP, Azure and generate Terraform/CLI execution kits for AI agents.
Deploy, monitor, and manage your OpenClaw AI assistants via natural language.
Provides capabilities that let LLM agents perform a range of infrastructure management tasks.
Give your AI agents the tools to build, manage, and run automation workflows.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/ahmedselimmansor-ctrl/Alibaba_cloud_MCP_server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
