CloudPulse MCP Server
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| AWS_REGION | No | AWS region (e.g., 'us-east-1') for AWS operations | |
| AWS_PROFILE | No | AWS CLI profile name (e.g., 'default') for AWS access | |
| VERCEL_TOKEN | No | Personal access token from vercel.com/account/tokens for Vercel access | |
| VERCEL_TEAM_ID | No | Optional Vercel team ID for team-specific access | |
| AWS_ACCESS_KEY_ID | No | AWS access key ID for AWS access | |
| CLOUDFLARE_API_TOKEN | No | Cloudflare API token for Cloudflare access | |
| AWS_SECRET_ACCESS_KEY | No | AWS secret access key for AWS access | |
| CLOUDFLARE_ACCOUNT_ID | No | Cloudflare account ID for Cloudflare access | |
| GOOGLE_APPLICATION_CREDENTIALS | No | Path to GCP service account key file for GCP access |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| list_cloud_topologyA | Scan all configured cloud platforms (AWS, Vercel, GCP, Cloudflare) and return a unified topology of active services including their endpoints and regions. Run this first to understand the infrastructure landscape. |
| get_correlated_logsA | Fetch logs from multiple cloud platforms (AWS CloudWatch + Vercel) for a given time window and optional trace ID, then merge them into a single chronological timeline. Use this to correlate errors across frontend and backend services. |
| diagnose_service_linkA | Diagnose connectivity issues between a source service and a target resource. Checks Vercel environment variables, AWS Security Group inbound rules on the required port, and external API reachability. Returns a list of diagnostic results with actionable messages. |
| check_resource_limitsA | Query quota limits and current usage across configured cloud platforms. Highlights resources approaching or exceeding their limits (default warning threshold: 80%). Use this to proactively catch Lambda concurrency limits, Vercel plan caps, and similar issues before they cause outages. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 4 tools
Each tool has a clearly distinct purpose with no overlap: check_resource_limits focuses on quota monitoring, diagnose_service_link on connectivity diagnostics, get_correlated_logs on log aggregation, and list_cloud_topology on infrastructure discovery. The descriptions reinforce unique scopes, making misselection unlikely.
All tool names follow a consistent verb_noun pattern (e.g., check_resource_limits, diagnose_service_link), using snake_case uniformly. This predictability aids agent understanding and tool selection without confusion.
Four tools is a reasonable count for a cloud monitoring server, covering key areas like limits, diagnostics, logs, and topology. It feels slightly lean but well-scoped, as each tool addresses a distinct monitoring need without bloat.
The toolset covers core cloud monitoring workflows: proactive limits checking, connectivity diagnosis, log correlation, and topology mapping. Minor gaps exist, such as lack of alerting or remediation tools, but agents can work around these with the provided diagnostic and data-fetching capabilities.