env0
OfficialServer Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| ENV0_API_KEY | Yes | Your env0 API Key ID | |
| ENV0_API_SECRET | Yes | Your env0 API Key Secret | |
| ENV0_ORGANIZATION_ID | No | Your env0 Organization ID (required if you have multiple organizations) |
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 |
|---|---|
| get-cloud-configurationsC | Get the compass cloud configurations |
| get-environmentsD | Get the environments from env0 |
| get-projectsC | Get the projects from env0 |
| approve-environmentC | Approve an environment |
| cancel-environmentA | Cancel an environment's latest deployment while it is still queued or waiting for user approval. No changes are applied. To stop a deployment that is already in progress, use abort-environment instead. |
| abort-environmentA | Forcefully stop an environment's latest deployment while it is in progress. To cancel a deployment that is still queued or waiting for user approval, use cancel-environment instead. |
| get-cloud-resourcesC | Get cloud resources from env0 |
| generate-iacA | Generate Infrastructure as Code (IaC) for cloud resources. This tool initiates a long-running job and returns a job ID for tracking progress. |
| check-iac-job-statusA | Check the status and retrieve results of an Infrastructure as Code generation job. Use this tool after calling generate-iac to monitor progress and get results. Could take up to around 1 minute to get results. |
| deploy-environmentA | This tool creates a new deployment for an existing env0 environment. You can use the "get-environments" or "get-environment" tool to find the environment ID of the environment you are looking for. This action ALWAYS requires approval from the user before execution. |
| get-plan-logsA | Get plan logs for the latest deployment of a specific environment from env0. For historical deployments use get-deployment-context instead. For full plan see env0 console. |
| get-error-analysisA | Analyzes errors in the latest deployment of an environment. For historical deployments use get-deployment-context instead. |
| search-deploymentsA | Find recent deployments for an environment, optionally filtered by status. Use this to pick a deploymentLogId for follow-up debug via get-deployment-context. Use when: user asks for deployment history, wants to find a failed deployment, or needs to pick among multiple recent deployments. Do NOT use for the latest deployment alone — get-plan-logs or get-error-analysis already cover that without needing an ID. Returns up to 10 deployments by default (raise limit to 25 max). Sorted newest-first. Each entry includes: id, status, type, queuedAt, startedAt, finishedAt, triggerName, comment, resourceCount, blueprintRevision, blueprintName, blueprintType, prNumber, gitMetadata, planSummary, failedCommand. Set hasMore=true means another page exists. Prefer filtering via 'statuses' over paging with 'offset'. |
| get-deployment-contextA | Fetch debug context for one specific deployment: metadata, all step statuses, and the log of the first failed step (auto-picked: status FAIL or TIMEOUT). Returns log:null on clean success — pass an explicit stepName to inspect a successful step. Use when: user asks why a past deployment failed, names a deploymentLogId, or wants to inspect a specific step (apply, destroy, custom flow) of a historical deployment. Do NOT use for the latest deployment's plan log — use get-plan-logs (no deploymentLogId needed, cheaper). For an error summary use get-error-analysis. deploymentLogId is REQUIRED. Use search-deployments first to find one. Returns { deployment, steps, log }. log is { stepName, events, truncated } or null when no failed step exists and no stepName was given. Step names look like 'tf:plan', 'tf:apply', 'opentofu:plan', 'terragrunt:plan', 'pulumi:preview', 'helm:diff', 'k8s:apply', 'git:clone', 'spec:load'. Targeting a NOT_STARTED step returns 400. Example chain: search-deployments(envId, statuses="FAILURE") → get-deployment-context(deploymentLogId=) |
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 14 tools
Most tools have distinct, well-documented purposes, with cancel-environment/abort-environment and get-plan-logs/get-error-analysis/get-deployment-context explicitly differentiated in their descriptions. The only fuzzy pair is get-cloud-resources vs get-cloud-configurations, whose boundary is not clearly explained.
All 14 tools follow a consistent verb_noun pattern in kebab-case (get-plan-logs, search-deployments, cancel-environment, generate-iac, etc.), with predictable verbs like get/search/check/deploy/approve.
14 tools is well within the ideal range and each tool covers a distinct slice of the env0 domain (environments, deployments, projects, cloud resources, IaC generation), so no tool feels redundant or filler.
Coverage is read-heavy: environments and projects support get/deploy/cancel/abort/approve but there is no create/update/delete for environments or projects, and the deploy-environment description references a get-environment tool that is not present in the set. Core deployment-debug workflows are complete, but lifecycle CRUD has notable gaps.