Skip to main content
Glama
env0

env0

Official
by env0
OverviewSchemaRelated ServersScoreDiscussions
TypeScript
Remote

Env0's MCP Server

The Env0 MCP Server connects AI tools Env0's platform. This gives AI agents, assistants, and chatbots the ability to interact with environments in Env0's platform (for example, deploying, canceling and getting the logs of environments), as well as getting the resources from Env0's Cloud Compass. All through natural language interactions.

🛠️ Installation

Requirements

  • Docker - Required to run the MCP server container

  • MCP Client - One of the following AI coding assistants:

    • Cursor, Claude Code, VSCode, Windsurf, Cline, Zed, JetBrains AI Assistant, or another MCP-compatible client

  • Env0 API Credentials - You'll need to gather the following from your env0 account:

🔑 API Key and Secret

Create an API key and secret by following the env0 API Keys guide.

🏢 Organization ID

Find your organization ID in the env0 dashboard:

  1. Click on your organization icon in the bottom left corner

  2. Select Settings from the left side panel

  3. Go to the General tab under Organization Settings

  4. Copy the Organization ID

For detailed instructions, see the env0 Organizations documentation.

Note: The Organization ID is required if you belong to multiple organizations. If you only have access to one organization, this step ensures the MCP server connects to the correct one.

Go to: Settings -> Cursor Settings -> MCP & Integrations -> New MCP Server

Pasting the following configuration into your Cursor ~/.cursor/mcp.json file is the recommended approach. You may also install in a specific project by creating .cursor/mcp.json in your project folder. See Cursor MCP docs for more info.

{
  "mcpServers": {
    "env0": {
      "command": "docker",
      "args": [
        "run", "-i", "--rm",
        "-e", "ENV0_API_KEY=your-api-key-here",
        "-e", "ENV0_API_SECRET=your-api-secret-here",
        "-e", "ENV0_ORGANIZATION_ID=your-org-id-here",
        "env0/mcp-server"
      ]
    }
  }
}

Run this command. See Claude Code MCP docs for more info.

claude mcp add env0 -- docker run -i --rm -e ENV0_API_KEY=your-api-key-here -e ENV0_API_SECRET=your-api-secret-here -e ENV0_ORGANIZATION_ID=your-org-id-here env0/mcp-server

Add this to your Windsurf MCP raw config file. See Windsurf MCP docs for more info.

{
  "mcpServers": {
    "env0": {
      "command": "docker",
      "args": [
        "run", "-i", "--rm",
        "-e", "ENV0_API_KEY=your-api-key-here",
        "-e", "ENV0_API_SECRET=your-api-secret-here",
        "-e", "ENV0_ORGANIZATION_ID=your-org-id-here",
        "env0/mcp-server"
      ]
    }
  }
}

Add this to your VS Code MCP config file. See VS Code MCP docs for more info.

{
  "mcp": {
    "servers": {
      "env0": {
        "type": "stdio",
        "command": "docker",
        "args": [
          "run", "-i", "--rm",
          "-e", "ENV0_API_KEY=your-api-key-here",
          "-e", "ENV0_API_SECRET=your-api-secret-here",
          "-e", "ENV0_ORGANIZATION_ID=your-org-id-here",
          "env0/mcp-server"
        ]
      }
    }
  }
}

  1. Open Cline.

  2. Click the hamburger menu (☰) to open the side menu.

  3. Go to the MCP Servers section.

  4. Switch to the Installed tab.

  5. Click on Configure MCP Servers.

  6. Add the env0 MCP server to your configuration:

{
  "mcpServers": {
    "env0": {
      "command": "docker",
      "args": [
        "run", "-i", "--rm",
        "-e", "ENV0_API_KEY=your-api-key-here",
        "-e", "ENV0_API_SECRET=your-api-secret-here",
        "-e", "ENV0_ORGANIZATION_ID=your-org-id-here",
        "env0/mcp-server"
      ]
    }
  }
}

Add this to your Zed settings.json. See Zed Context Server docs for more info.

{
  "context_servers": {
    "env0": {
      "command": {
        "path": "docker",
        "args": [
          "run", "-i", "--rm",
          "-e", "ENV0_API_KEY=your-api-key-here",
          "-e", "ENV0_API_SECRET=your-api-secret-here",
          "-e", "ENV0_ORGANIZATION_ID=your-org-id-here",
          "env0/mcp-server"
        ]
      },
      "settings": {}
    }
  }
}

To configure the env0 MCP server in Augment Code, you can use either the graphical interface or manual configuration.

A. Using the Augment Code UI

  1. Click the hamburger menu.

  2. Select Settings.

  3. Navigate to the Tools section.

  4. Click the + Add MCP button.

  5. Enter the following command:

    docker run -i --rm -e ENV0_API_KEY=your-api-key-here -e ENV0_API_SECRET=your-api-secret-here -e ENV0_ORGANIZATION_ID=your-org-id-here env0/mcp-server

  6. Name the MCP: env0.

  7. Click the Add button.

B. Manual Configuration

  1. Press Cmd/Ctrl Shift P or go to the hamburger menu in the Augment panel

  2. Select Edit Settings

  3. Under Advanced, click Edit in settings.json

  4. Add the server configuration to the mcpServers array in the augment.advanced object

{
  "augment.advanced": {
    "mcpServers": [
      {
        "name": "env0",
        "command": "docker",
        "args": [
          "run", "-i", "--rm",
          "-e", "ENV0_API_KEY=your-api-key-here",
          "-e", "ENV0_API_SECRET=your-api-secret-here",
          "-e", "ENV0_ORGANIZATION_ID=your-org-id-here",
          "env0/mcp-server"
        ]
      }
    ]
  }
}

Once the MCP server is added, restart your editor.

Add this to your Roo Code MCP configuration file. See Roo Code MCP docs for more info.

{
  "mcpServers": {
    "env0": {
      "command": "docker",
      "args": [
        "run", "-i", "--rm",
        "-e", "ENV0_API_KEY=your-api-key-here",
        "-e", "ENV0_API_SECRET=your-api-secret-here",
        "-e", "ENV0_ORGANIZATION_ID=your-org-id-here",
        "env0/mcp-server"
      ]
    }
  }
}

See Gemini CLI Configuration for details.

  1. Open the Gemini CLI settings file. The location is ~/.gemini/settings.json (where ~ is your home directory).

  2. Add the following to the mcpServers object in your settings.json file:

{
  "mcpServers": {
    "env0": {
      "command": "docker",
      "args": [
        "run", "-i", "--rm",
        "-e", "ENV0_API_KEY=your-api-key-here",
        "-e", "ENV0_API_SECRET=your-api-secret-here",
        "-e", "ENV0_ORGANIZATION_ID=your-org-id-here",
        "env0/mcp-server"
      ]
    }
  }
}

If the mcpServers object does not exist, create it.

Open Claude Desktop developer settings and edit your claude_desktop_config.json file to add the following configuration. See Claude Desktop MCP docs for more info.

{
  "mcpServers": {
    "env0": {
      "command": "docker",
      "args": [
        "run", "-i", "--rm",
        "-e", "ENV0_API_KEY=your-api-key-here",
        "-e", "ENV0_API_SECRET=your-api-secret-here",
        "-e", "ENV0_ORGANIZATION_ID=your-org-id-here",
        "env0/mcp-server"
      ]
    }
  }
}

Add this to your Opencode configuration file. See Opencode MCP docs for more info.

{
  "mcp": {
    "env0": {
      "type": "local",
      "command": [
        "docker", "run", "-i", "--rm",
        "-e", "ENV0_API_KEY=your-api-key-here",
        "-e", "ENV0_API_SECRET=your-api-secret-here",
        "-e", "ENV0_ORGANIZATION_ID=your-org-id-here",
        "env0/mcp-server"
      ],
      "enabled": true
    }
  }
}

See OpenAI Codex for more information.

Add the following configuration to your OpenAI Codex MCP server settings:

[mcp_servers.env0]
command = "docker"
args = [
  "run", "-i", "--rm",
  "-e", "ENV0_API_KEY=your-api-key-here",
  "-e", "ENV0_API_SECRET=your-api-secret-here",
  "-e", "ENV0_ORGANIZATION_ID=your-org-id-here",
  "env0/mcp-server"
]

See JetBrains AI Assistant Documentation for more details.

  1. In JetBrains IDEs go to Settings -> Tools -> AI Assistant -> Model Context Protocol (MCP)

  2. Click + Add.

  3. Click on Command in the top-left corner of the dialog and select the As JSON option from the list

  4. Add this configuration and click OK

{
  "mcpServers": {
    "env0": {
      "command": "docker",
      "args": [
        "run", "-i", "--rm",
        "-e", "ENV0_API_KEY=your-api-key-here",
        "-e", "ENV0_API_SECRET=your-api-secret-here",
        "-e", "ENV0_ORGANIZATION_ID=your-org-id-here",
        "env0/mcp-server"
      ]
    }
  }
}

  1. Click Apply to save changes.

  2. The same way env0 could be added for JetBrains Junie in Settings -> Tools -> Junie -> MCP Settings

See Kiro Model Context Protocol Documentation for details.

  1. Navigate Kiro > MCP Servers

  2. Add a new MCP server by clicking the + Add button.

  3. Paste the configuration given below:

{
  "mcpServers": {
    "env0": {
      "command": "docker",
      "args": [
        "run", "-i", "--rm",
        "-e", "ENV0_API_KEY=your-api-key-here",
        "-e", "ENV0_API_SECRET=your-api-secret-here",
        "-e", "ENV0_ORGANIZATION_ID=your-org-id-here",
        "env0/mcp-server"
      ],
      "env": {},
      "disabled": false,
      "autoApprove": []
    }
  }
}

  1. Click Save to apply the changes.

Use the Add manually feature and fill in the JSON configuration information for that MCP server. For more details, visit the Trae documentation.

{
  "mcpServers": {
    "env0": {
      "command": "docker",
      "args": [
        "run", "-i", "--rm",
        "-e", "ENV0_API_KEY=your-api-key-here",
        "-e", "ENV0_API_SECRET=your-api-secret-here",
        "-e", "ENV0_ORGANIZATION_ID=your-org-id-here",
        "env0/mcp-server"
      ]
    }
  }
}

Add this to your Amazon Q Developer CLI configuration file. See Amazon Q Developer CLI docs for more details.

{
  "mcpServers": {
    "env0": {
      "command": "docker",
      "args": [
        "run", "-i", "--rm",
        "-e", "ENV0_API_KEY=your-api-key-here",
        "-e", "ENV0_API_SECRET=your-api-secret-here",
        "-e", "ENV0_ORGANIZATION_ID=your-org-id-here",
        "env0/mcp-server"
      ]
    }
  }
}

See Warp Model Context Protocol Documentation for details.

  1. Navigate Settings > AI > Manage MCP servers.

  2. Add a new MCP server by clicking the + Add button.

  3. Paste the configuration given below:

{
  "env0": {
    "command": "docker",
    "args": [
      "run", "-i", "--rm",
      "-e", "ENV0_API_KEY=your-api-key-here",
      "-e", "ENV0_API_SECRET=your-api-secret-here",
      "-e", "ENV0_ORGANIZATION_ID=your-org-id-here",
      "env0/mcp-server"
    ],
    "env": {},
    "working_directory": null,
    "start_on_launch": true
  }
}

  1. Click Save to apply the changes.

See LM Studio MCP Support for more information.

  1. Navigate to Program (right side) > Install > Edit mcp.json.

  2. Paste the configuration given below:

{
  "mcpServers": {
    "env0": {
      "command": "docker",
      "args": [
        "run", "-i", "--rm",
        "-e", "ENV0_API_KEY=your-api-key-here",
        "-e", "ENV0_API_SECRET=your-api-secret-here",
        "-e", "ENV0_ORGANIZATION_ID=your-org-id-here",
        "env0/mcp-server"
      ]
    }
  }
}

  1. Click Save to apply the changes.

  2. Toggle the MCP server on/off from the right hand side, under Program, or by clicking the plug icon at the bottom of the chat box.

You can configure the env0 MCP server in Visual Studio 2022 by following the Visual Studio MCP Servers documentation.

Add this to your Visual Studio MCP config file (see the Visual Studio docs for details):

{
  "mcp": {
    "servers": {
      "env0": {
        "type": "stdio",
        "command": "docker",
        "args": [
          "run", "-i", "--rm",
          "-e", "ENV0_API_KEY=your-api-key-here",
          "-e", "ENV0_API_SECRET=your-api-secret-here",
          "-e", "ENV0_ORGANIZATION_ID=your-org-id-here",
          "env0/mcp-server"
        ]
      }
    }
  }
}

For more information and troubleshooting, refer to the Visual Studio MCP Servers documentation.

Add this to your Crush configuration file. See Crush MCP docs for more info.

{
  "$schema": "https://charm.land/crush.json",
  "mcp": {
    "env0": {
      "type": "stdio",
      "command": "docker",
      "args": [
        "run", "-i", "--rm",
        "-e", "ENV0_API_KEY=your-api-key-here",
        "-e", "ENV0_API_SECRET=your-api-secret-here",
        "-e", "ENV0_ORGANIZATION_ID=your-org-id-here",
        "env0/mcp-server"
      ]
    }
  }
}

Open the "Settings" page of the app, navigate to "Plugins," and enter the following JSON:

{
  "mcpServers": {
    "env0": {
      "command": "docker",
      "args": [
        "run", "-i", "--rm",
        "-e", "ENV0_API_KEY=your-api-key-here",
        "-e", "ENV0_API_SECRET=your-api-secret-here",
        "-e", "ENV0_ORGANIZATION_ID=your-org-id-here",
        "env0/mcp-server"
      ]
    }
  }
}

More information is available on BoltAI's Documentation site. For BoltAI on iOS, see this guide.

Edit your Rovo Dev CLI MCP config by running the command below:

acli rovodev mcp

Add this configuration:

{
  "mcpServers": {
    "env0": {
      "command": "docker",
      "args": [
        "run", "-i", "--rm",
        "-e", "ENV0_API_KEY=your-api-key-here",
        "-e", "ENV0_API_SECRET=your-api-secret-here",
        "-e", "ENV0_ORGANIZATION_ID=your-org-id-here",
        "env0/mcp-server"
      ]
    }
  }
}

To configure the env0 MCP server in Zencoder, follow these steps:

  1. Go to the Zencoder menu (...)

  2. From the dropdown menu, select Agent tools

  3. Click on the Add custom MCP

  4. Add the name and server configuration from below, and make sure to hit the Install button

{
  "command": "docker",
  "args": [
    "run", "-i", "--rm",
    "-e", "ENV0_API_KEY=your-api-key-here",
    "-e", "ENV0_API_SECRET=your-api-secret-here",
    "-e", "ENV0_ORGANIZATION_ID=your-org-id-here",
    "env0/mcp-server"
  ]
}

Once the MCP server is added, you can easily continue using it.

See Qodo Gen docs for more details.

  1. Open Qodo Gen chat panel in VSCode or IntelliJ.

  2. Click Connect more tools.

  3. Click + Add new MCP.

  4. Add the following configuration:

Qodo Gen Docker Connection

{
  "mcpServers": {
    "env0": {
      "command": "docker",
      "args": [
        "run", "-i", "--rm",
        "-e", "ENV0_API_KEY=your-api-key-here",
        "-e", "ENV0_API_SECRET=your-api-secret-here",
        "-e", "ENV0_ORGANIZATION_ID=your-org-id-here",
        "env0/mcp-server"
      ]
    }
  }
}

See Local and Remote MCPs for Perplexity for more information.

  1. Navigate Perplexity > Settings

  2. Select Connectors.

  3. Click Add Connector.

  4. Select Advanced.

  5. Enter Server Name: env0

  6. Paste the following JSON in the text area:

{
  "args": [
    "run", "-i", "--rm",
    "-e", "ENV0_API_KEY=your-api-key-here",
    "-e", "ENV0_API_SECRET=your-api-secret-here",
    "-e", "ENV0_ORGANIZATION_ID=your-org-id-here",
    "env0/mcp-server"
  ],
  "command": "docker",
  "env": {}
}

  1. Click Save.

Related MCP server: Cloud Pilot MCP

🔧 Available Tools

The Env0 MCP Server provides a comprehensive set of tools to interact with Env0's platform through natural language. These tools are organized into the following categories:

get-projects

Retrieve all projects from your Env0 organization.

  • Description: Get the projects from env0

  • Parameters: None required

  • Usage: "Show me all my projects" or "List projects"

get-environments

Retrieve environments from Env0, with optional filtering.

  • Description: Get the environments from env0

  • Parameters:

    • environmentId (optional): Get a specific environment by ID

    • name (optional): Filter by environment name

    • projectId (optional): Filter by project ID

    • limit (optional): Maximum number of environments to return

    • offset (optional): Pagination offset

  • Usage: "Show me all environments" or "Get environment with ID xyz"

deploy-environment

Create a new deployment for an existing environment.

  • Description: Creates a new deployment for an existing env0 environment. Always requires user to approve the deployment in env0.

  • Parameters:

    • environmentId (required): The environment ID to deploy

    • comment (optional): Deployment comment

    • revision (optional): Specific revision to deploy

  • ⚠️ Important: This action ALWAYS requires user approval before execution

  • Usage: "Deploy environment xyz" or "Deploy the latest version of my staging environment"

abort-environment

Abort a running environment's deployment.

  • Description: Abort an environment's current deployment

  • Parameters:

    • environmentId (required): The environment ID to abort

  • Usage: "Abort the deployment of environment xyz"

approve-environment

Approve an environment plan, pending approval for applying.

  • Description: Approve an environment plan, pending approval for applying.

  • Parameters:

    • environmentId (required): The environment ID to approve

  • Usage: "Approve environment xyz"

cancel-environment

Cancel an environment plan, pending user approval.

  • Description: Cancel an environment plan that is pending user approval.

  • Parameters:

    • environmentId (required): The environment ID to cancel

  • Usage: "Cancel environment xyz"

get-plan-logs

Retrieve Terraform/OpenTofu plan logs (or any other IaC's dry runs results) for an environment.

  • Description: Get plan logs for a specific environment from env0

  • Parameters:

    • environmentId (required): The environment ID to get logs for

  • Note: For full plan details, see the env0 console

  • Usage: "Show me the plan logs for environment xyz"

get-error-analysis

Analyze errors from the last environment deployment.

  • Description: Analyzes errors in the last environment's deployment

  • Parameters:

    • environmentId (required): The environment ID to analyze errors for

  • Usage: "Analyze errors for environment xyz" or "What went wrong with my last deployment?"

get-deployment-context

Fetch full debug context for one specific (historical) deployment: metadata, all step statuses, and the log of the most relevant step (auto-picks the failed step; falls back to the plan step on success).

  • Description: Debug a past deployment by ID — metadata + steps + auto-picked step log

  • Parameters:

    • deploymentLogId (required): The deployment to inspect. Use search-deployments first to find one.

    • stepName (optional): Inspect a specific step (e.g., tf:apply, tf:destroy). Omit to auto-pick (failed step preferred, falls back to plan step).

  • Note: For the latest deployment's plan log, prefer get-plan-logs (no ID needed). For an error summary, prefer get-error-analysis. state:get is blocked.

  • Usage: "Why did the deployment from yesterday on env X fail?" → chain via search-deployments then this tool.

get-cloud-configurations

Retrieve cloud configurations from Env0's Cloud Compass.

  • Description: Get the compass cloud configurations

  • Parameters: None required

  • Usage: "Show me my cloud configurations"

get-cloud-resources

Retrieve cloud resources with advanced filtering capabilities.

  • Description: Get cloud resources from env0

  • Parameters: Complex filtering options including:

    • filters (required): Object with various filter options:

      • cloudProvider: Filter by cloud provider (AWS, GCP, AzureLAW)

      • cloudConfigurationId: Filter by cloud configuration ID

      • environmentId: Filter by environment ID

      • resourceId: Filter by resource ID

      • name: Filter by resource name

      • type: Filter by resource type

      • region: Filter by region

      • service: Filter by service

      • managementType: Filter by management type

      • driftStatus: Filter by drift status

      • severity: Filter by severity (High, Medium, Low, Optimal, Ignored, Reset)

      • searchBy: General search term

    • paging: Pagination options (limit, offset)

    • orderBy: Sorting options

  • Usage: "Show me all AWS resources" or "Find resources with high severity drift"

generate-iac

Generate Infrastructure as Code (Terraform/OpenTofu) from existing cloud resources.

  • Description: Generate Infrastructure as Code (IaC) for cloud resources

  • Parameters:

    • cloudResourceIds (required): Array of cloud resource IDs to generate IaC for

    • iacType (required): Type of IaC to generate ("OpenTofu" or "Terraform")

  • Returns: Job ID for tracking progress

  • Usage: "Generate Terraform code for these resources" or "Create OpenTofu configuration for resource xyz"

check-iac-job-status

Monitor the progress of IaC generation jobs.

  • Description: Check the status and retrieve results of an Infrastructure as Code generation job

  • Parameters:

    • jobId (required): Job ID returned from generate-iac request

  • Note: Jobs can take up to around 1 minute to complete

  • Usage: "Check the status of job abc123" or "Is my IaC generation ready?"

💡 Usage Examples

Here are some example natural language queries you can use with the MCP server:

Project & Environment Management:

  • "Show me all my projects"

  • "List environments in project xyz"

  • "Get details for environment abc123"

  • "Do I have any environments in project xyz that require my attention?"

Deployments:

  • "Deploy my staging environment"

  • "Deploy environment xyz with comment 'hotfix deployment'"

  • "Abort the running deployment for environment xyz"

Monitoring:

  • "Show me the plan logs for my production environment"

  • "What's the status of environment abc123?"

  • "Analyze errors for environment xyz" or "What went wrong with my last deployment?"

  • "Why did the deployment from yesterday on env xyz fail?" (chains search-deployments → get-deployment-context)

  • "Show me the apply log for deployment abc123"

Cloud Resources:

  • "Show me all my AWS resources"

  • "Find resources with drift issues"

  • "List all S3 buckets in us-east-1 in AWS account xyz"

  • "Generate Terraform code for resource xyz from AWS account xyz"

  • "Check if my IaC generation job is complete"

For Development of the MCP Server

To set up the development environment and test the server:

  1. Clone and install dependencies:

    git clone <repository-url>
cd mcp-server
npm install

  2. Run the server:

    npm start

  3. Test with MCP Inspector:

    Use the MCP Inspector tool for testing and debugging:

    npx @modelcontextprotocol/inspector npx tsx src/cli.ts

    This will open a web interface at http://localhost:6274 where you can interact with the MCP server and test its capabilities.

Authentication

To allow the MCP server to connect to Env0's platform, you need to provide your API credentials. To create a new API key, please follow (this guide)[https://docs.env0.com/docs/api-keys]

Once you have your API credentials, you can configure them in the MCP server by setting the following environment variables:

export ENV0_API_KEY="your-api-key-id"
export ENV0_API_SECRET="your-api-key-secret"
export ENV0_ORGANIZATION_ID="your-organization-id"

You can also create a .env file like our example .env.example and fill in the values:

# Required: Your env0 API Key ID (Get this from the Env0 site using the guide above)
ENV0_API_KEY=your-api-key-id-here

# Required: Your env0 API Key Secret (Get this from the Env0 site using the guide above)
ENV0_API_SECRET=your-api-key-secret-here

# Your env0 Organization ID (found in your env0 organization settings). This is required if you have multiple organizations
ENV0_ORGANIZATION_ID=your-organization-id-here

Docker Configuration

The env0 MCP server supports Docker deployment, making it easy to run in containerized environments and integrate with MCP clients.

Building the Docker Image

  1. Build the Docker image:

    docker build -t env0/mcp-server .

  2. Test the container:

    docker run --rm -e ENV0_API_KEY=your-api-key -e ENV0_API_SECRET=your-api-secret -e ENV0_ORGANIZATION_ID=your-org-id env0/mcp-server

Docker Transport Modes

The container supports both MCP transport modes:

1. Stdio Transport (Default)

  • Used by most MCP clients (Claude Desktop, Windsurf)

  • Communication via stdin/stdout

  • Use -i flag for interactive mode

2. HTTP Transport

  • For remote MCP server access

  • Set MCP_TRANSPORT environment variable to http to enable

docker run -d -p 3000:3000 -e PORT=3000 -e MCP_TRANSPORT=http env0/mcp-server

Then, configure your MCP client to use the HTTP transport mode:

{
  "mcpServers": {
    "env0": {
      "serverUrl": "http://localhost:3000/mcp"
    }
  }
}

Available Tools

14 tools
abort-environmentAbort EnvironmentC

Abort an environment

ParametersJSON Schema
NameRequiredDescriptionDefault
environmentIdYesThe ID of the environment to abort

TDQS

C2.5/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, and the description does not disclose what 'abort' entails (e.g., whether it stops, deletes, or reverts resources, or if it's reversible). Minimal behavioral context for a mutation tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence, concise but lacking depth. While brevity is positive, it omits necessary details for effective tool selection.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity and the presence of similar sibling tools, the description is incomplete. It does not differentiate 'abort' from 'cancel' or explain the effect on the environment.

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 100%; the sole parameter 'environmentId' is documented in the schema. The tool description adds no additional parameter information beyond the schema, meeting the baseline.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The title 'Abort Environment' and description 'Abort an environment' state the verb and resource, but 'abort' is vague and not differentiated from sibling 'cancel-environment'. The purpose is clear but lacks specificity and sibling distinction.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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 'cancel-environment'. Missing context for prerequisites or typical use cases.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

approve-environmentApprove EnvironmentC

Approve an environment

ParametersJSON Schema
NameRequiredDescriptionDefault
environmentIdYesThe ID of the environment to approve

TDQS

C2.2/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations exist, so the description solely bears the burden of behavioral disclosure. It only states the action 'Approve' without explaining side effects, reversibility, permissions, or consequences of the approval.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

While the description is short (one sentence), it sacrifices substance for brevity. It fails to provide enough context to be useful, making it under-specified rather than appropriately concise.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple one-parameter tool, the description omits critical context such as what happens after approval, required prior steps, or return values. It is incomplete even given the tool's low complexity.

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 coverage is 100% with a clear description for 'environmentId'. The tool description adds no extra meaning beyond what the schema already provides, meeting the baseline expectation.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose2/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'Approve an environment' is a tautology that restates the tool name with no added specificity. It does not elaborate on what approval entails or distinguish it from sibling tools like 'deploy-environment' or 'cancel-environment'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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 such as 'deploy-environment' or 'cancel-environment'. The description lacks context about prerequisites or triggers for approval.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

cancel-environmentCancel EnvironmentC

Cancel an environment

ParametersJSON Schema
NameRequiredDescriptionDefault
environmentIdYesThe ID of the environment to cancel

TDQS

C2.4/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided; description does not disclose behavioral traits such as state transitions, reversibility, permissions, or side effects. For a cancellation tool, this is insufficient.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Extremely concise but under-specified. The single sentence does not earn its place as it lacks necessary context for safe use.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema, no annotations, only one parameter. The description is inadequate for a destructive action, especially given sibling tools that require differentiation.

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 coverage is 100%; the single parameter 'environmentId' is described in the schema. The description adds no additional meaning beyond what the schema provides.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'Cancel an environment' is clear but lacks distinction from sibling 'abort-environment', which suggests similar functionality. It meets the minimum viable clarity but does not differentiate.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance provided on when to use this tool versus alternatives like 'abort-environment'. The description does not specify context or prerequisites.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

check-iac-job-statusCheck 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.

ParametersJSON Schema
NameRequiredDescriptionDefault
jobIdYesJob ID returned from generate IaC request

TDQS

A4.2/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, description indicates it checks status and retrieves results, and mentions potential delay. Does not disclose polling behavior, idempotency, or error handling, but covers essential behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, front-loaded with purpose, efficient and no wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple monitoring tool with one parameter, description covers purpose, usage sequence, and timing. Lacks output format but acceptable given no output schema and low complexity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% for 'jobId'. Description adds context by specifying 'Job ID returned from generate IaC request', linking to sibling tool and clarifying origin beyond schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states the verb 'check' and resource 'status and results of an Infrastructure as Code generation job'. It differentiates from sibling 'generate-iac' by indicating this tool is used to monitor a previously initiated job.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly states to use after calling 'generate-iac' to monitor progress and get results, including a time estimate of up to 1 minute. Lacks exclusions or alternatives but provides clear context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

deploy-environmentDeploy 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.

ParametersJSON Schema
NameRequiredDescriptionDefault
commentNo
revisionNo
environmentIdYes

TDQS

A3.5/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description must disclose behavioral traits. It only states that approval is always required, which is useful but insufficient. It does not describe whether the deployment is destructive, what permissions are needed, or any side effects, leaving significant gaps for a mutation operation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise with three sentences, each serving a purpose: defining the action, providing a prerequisite step, and noting a critical requirement. No extraneous words, and the key information is front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given that there is no output schema, the description does not explain what the tool returns, whether it is idempotent, or what happens after creation (e.g., success/failure). It only covers the approval requirement, which is helpful but leaves the agent underinformed about the overall behavior.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description does not mention any parameters explicitly. While it implies that environmentId refers to the environment ID (via the suggestion to use get-environments), revision and comment are completely unexplained. Since schema description coverage is 0%, more parameter guidance is needed.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool creates a new deployment for an existing env0 environment, specifying the verb ('creates') and resource ('deployment for environment'). This distinguishes it from sibling tools like abort, approve, or cancel, which serve different purposes.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description advises using get-environments or get-environment to find the environment ID, providing a clear usage context. It also emphasizes that user approval is always required. However, it does not explicitly list when not to use this tool or mention alternative tools, which slightly reduces clarity.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

generate-iacGenerate Infrastructure as CodeA

Generate Infrastructure as Code (IaC) for cloud resources. This tool initiates a long-running job and returns a job ID for tracking progress.

ParametersJSON Schema
NameRequiredDescriptionDefault
iacTypeYesType of IaC to generate
cloudResourceIdsYesArray of cloud resource IDs to generate IaC for, use get-cloud-resources to find ids

TDQS

A3.8/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Discloses it initiates a long-running job and returns a job ID, which is key behavioral info. But with no annotations, it doesn't cover destructive nature, permissions, or failure modes.

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?

Two clear sentences with no fluff. Could add more context (e.g., response format) without losing conciseness.

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?

Covers purpose and async behavior adequately but lacks return value details and error scenarios. With no output schema, description is minimally sufficient.

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 covers 100% with clear descriptions for both parameters, including a cross-reference to get-cloud-resources. Description adds no extra parameter info, so baseline 3.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states the specific action 'Generate Infrastructure as Code' and the resource type 'cloud resources'. Distinguishes from siblings like check-iac-job-status by noting it initiates a long-running job and returns a job ID for tracking.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Mentions it returns a job ID for tracking, implying use with check-iac-job-status, and references get-cloud-resources for finding IDs. However, lacks explicit 'when not to use' or alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get-cloud-configurationsGet Cloud ConfigurationsC

Get the compass cloud configurations

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

C2.8/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations exist, so the description carries full burden for behavioral disclosure. It only states 'Get', implying read-only, but does not disclose any side effects, authorization requirements, or response characteristics.

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 a single short sentence with no extraneous text. It is concise, though the sentence is minimally informative.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a zero-parameter tool, the description is minimal. With no output schema and no usage guidance, it lacks completeness. A more detailed description would help an agent understand what 'compass cloud configurations' entails.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters, so the schema provides all needed semantics. Per guidelines, baseline is 4. The description adds no value beyond the name, but no parameters require explanation.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'Get the compass cloud configurations' clearly specifies a verb and a resource, indicating a read operation on cloud configurations. However, the phrase 'compass cloud configurations' is vague and does not differentiate from other related tools like 'get-cloud-resources' or 'get-deployment-context', limiting clarity.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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 siblings. With 13 sibling tools including get-cloud-resources and get-deployment-context, explicit usage context is needed but absent.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get-cloud-resourcesGet Cloud ResourcesC

Get cloud resources from env0

ParametersJSON Schema
NameRequiredDescriptionDefault
pagingNo
filtersYes
orderByNo

TDQS

C2.1/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so the description carries the full burden. 'Get' implies a read operation, but the description does not confirm read-only behavior, nor does it disclose pagination (though paging param exists), required filters, or any side effects. The behavioral traits are under-communicated.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is very short (one sentence), which is concise, but it sacrifices informativeness. It does not convey essential details about the tool's behavior. It is minimal but not efficiently helpful.

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?

Given the complexity (3 parameters, many filter subfields, no output schema, no annotations), the description is severely inadequate. It fails to explain the resource type, filtering logic, ordering, pagination, or return format. The agent would struggle to use this tool correctly.

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?

Schema description coverage is 0% – the description does not mention any parameters or their roles. The input schema has complex nested objects (filters, paging) but the description adds zero value beyond the schema. For a tool with 3 parameters and low schema documentation in description, this is insufficient.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'Get cloud resources from env0' specifies the verb and resource, but is vague. It does not differentiate from sibling tools like get-cloud-configurations, which also retrieves cloud-related data. The purpose is somewhat clear but lacks specificity.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool vs. alternatives. The description does not mention any prerequisites, exclusions, or comparative context with sibling tools like get-cloud-configurations. The agent must infer usage from the schema alone.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get-deployment-contextGet 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=)

ParametersJSON Schema
NameRequiredDescriptionDefault
stepNameNoOmit to auto-pick the first failed step (status FAIL or TIMEOUT); returns log:null if no failure. Common values: 'tf:plan', 'tf:apply', 'opentofu:plan', 'terragrunt:plan', 'pulumi:preview', 'helm:diff', 'k8s:apply', 'cf:change-set', 'ansible:playbook', 'git:clone', 'spec:load'. Cannot target a NOT_STARTED step.
deploymentLogIdYesRequired. The deployment to inspect. If you don't have one, call search-deployments first. For the latest deployment's plan log, prefer get-plan-logs — it doesn't require an ID.

TDQS

A4.7/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Discloses auto-picking of first failed step, return format ({deployment, steps, log}), log structure, error condition (400 for NOT_STARTED step). No annotations provided, so description carries burden; it does well but could explicitly state read-only.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Concise yet comprehensive: purpose, usage guidelines, parameter details, return format, error note, and example chain. No extra words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema and no annotations, the description covers all necessary aspects: purpose, usage, parameters, return structure, error scenario, and common step names. No gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema covers both parameters (100%). Description adds context: stepName omitted auto-picks failure, lists common values, cannot target NOT_STARTED; deploymentLogId is required and suggests search-deployments. Adds value beyond schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states the tool fetches debug context for a deployment: metadata, step statuses, log from first failed step (or specified step). It distinguishes from siblings like get-plan-logs and get-error-analysis.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly says when to use (user asks why deployment failed, has deploymentLogId, inspects specific step) and when not to use (latest plan log, error summary). Recommends search-deployments first and gives alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get-environmentsGet EnvironmentsD

Get the environments from env0

ParametersJSON Schema
NameRequiredDescriptionDefault
nameNoThe name of the environment to get
limitNoThe maximum number of environments to return
offsetNo
projectIdNoThe ID of the project to get environments for
environmentIdNoThe ID of the environment to get, if specified will ignore other parameters

TDQS

D1.7/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Without annotations, the description carries the full burden of behavioral disclosure. It only states 'Get', implying a read operation, but fails to specify return format, pagination behavior, or whether it requires authentication. No detail on what happens if parameters conflict (e.g., environmentId vs name).

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?

The description is extremely short but not concise—it is under-specified. Every word should earn its place, but here 'from env0' is redundant. The description fails to convey essential information.

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?

Given five parameters (at least one likely required per logic, though none marked required) and no output schema, the description is woefully incomplete. It does not explain what the tool returns, how pagination works, or the meaning of the response. The tool's purpose is unclear, making it difficult for an AI agent to invoke correctly.

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 80%, so the schema already documents most parameters. The description adds no value beyond the schema; it does not explain how parameters interact (e.g., environmentId overrides others). Baseline score of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose2/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'Get the environments from env0' is vague and essentially restates the tool name. It does not clarify what 'environments' refers to in the context of env0 (e.g., deployment environments, cloud configurations) and fails to distinguish this tool from sibling tools like get-cloud-configurations or get-projects.

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?

No guidance is provided on when to use this tool versus the many sibling tools. There is no mention of scenarios (e.g., listing environments for a project), prerequisites (e.g., projectId may be needed), or situations where this tool should not be used.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get-error-analysisGet Error AnalysisA

Analyzes errors in the latest deployment of an environment. For historical deployments use get-deployment-context instead.

ParametersJSON Schema
NameRequiredDescriptionDefault
environmentIdYesThe ID of the environment to get error analysis for

TDQS

A3.9/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided; description lacks details on behavior (e.g., output format, side effects, permissions). Minimal disclosure for a tool that analyzes errors.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two concise sentences, front-loaded with purpose, no unnecessary words.

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?

Basic context provided, but missing output expectations and behavioral details. Adequate given low complexity but could be more complete.

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 coverage is 100% and only one parameter; description adds no extra meaning beyond schema. Baseline score applies as no additional value.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states it analyzes errors in the latest deployment, distinguishing from historical deployments via sibling tool reference.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly tells when to use this tool (latest deployment) and when to use alternative (get-deployment-context for historical).

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get-plan-logsGet 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.

ParametersJSON Schema
NameRequiredDescriptionDefault
environmentIdYesThe ID of the environment to get plan logs for

TDQS

A3.9/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided; description does not disclose any behavioral traits such as side effects, authentication needs, rate limits, or what happens if no plan logs exist. This is insufficient for a tool with no annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three concise sentences with no unnecessary words. All information is relevant and well-structured.

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?

For a simple retrieval tool with one parameter and no output schema, the description is adequate but lacks behavioral context. It covers purpose and usage but not transparency.

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 coverage is 100%, so baseline is 3. Description adds no extra meaning to the 'environmentId' parameter beyond what schema already provides.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states verb 'Get', resource 'plan logs', and scope 'latest deployment of a specific environment'. Differentiates from sibling 'get-deployment-context' by specifying it is for historical deployments.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly says when to use (latest deployment) and when not to (historical deployments, use alternative). Also advises to see env0 console for full plan.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get-projectsGet ProjectsC

Get the projects from env0

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

C2.9/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, and the description does not disclose any behavioral traits such as read-only nature, authentication requirements, or side effects. The description is too brief to inform the agent about expected 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 a single sentence, very concise, and front-loaded. However, it could be slightly improved by adding a brief note on the output or typical use case. Overall it is efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no parameters, no output schema, and no annotations, the description is minimal. It does not explain what projects are returned, in what format, or if any filtering is possible. The tool lacks sufficient context for an agent to fully understand its outcome.

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?

There are no parameters, so the input schema covers all (100%). The description does not add extra meaning beyond the operation name, but as per guidelines, 0 parameters yields a baseline of 4, reduced to 3 because no additional context is provided.

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 'Get the projects from env0' clearly states the verb (get) and the resource (projects), distinguishing it from sibling tools that deal with environments and deployments. It adds no detail beyond the name but is not misleading.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No when-to-use or when-not-to-use guidance is provided. There is no context about prerequisites, alternatives, or when this tool is appropriate vs. siblings.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

search-deploymentsSearch 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'.

ParametersJSON Schema
NameRequiredDescriptionDefault
limitNoMaximum number of deployments to return. Defaults to 10, max 25.
offsetNoNumber of deployments to skip from the start (newest-first). Use sparingly — prefer filtering via `statuses` first. Helpful only when you need to dig past the most recent page.
statusesNoComma-separated deployment statuses to filter by. Common values: SUCCESS, FAILURE, IN_PROGRESS, CANCELLED, ABORTED, WAITING_FOR_USER, TIMEOUT.
environmentIdYesThe ID of the environment to list deployments for

TDQS

A4.7/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Discloses default limit (10), max limit (25), sorting (newest-first), returned fields, and hasMore flag. No annotations provided, so description takes full burden; could add rate limits or auth requirements, but it's still thorough.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Concise yet informative; front-loaded with main purpose and usage. Every sentence adds value without redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Provides complete context for a list operation: covers filtering, pagination, returned fields, and guidance for follow-up actions (picking deploymentLogId). Sufficient for agent to select and invoke correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema covers all 4 parameters with descriptions. Description adds value by recommending filtering via 'statuses' over paging and stating default/max for limit, which is helpful contextual guidance.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it finds recent deployments for an environment with optional status filtering. It explicitly distinguishes from sibling tools by mentioning get-plan-logs and get-error-analysis for different use cases.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides explicit when-to-use scenarios (deployment history, finding failed deployments, picking among multiple) and when-not-to-use (latest deployment alone), naming alternative tools.

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

B3.2/5.0
Disambiguation5/5

Each tool has a clear, distinct purpose, with descriptions that explicitly differentiate similar tools like get-plan-logs vs. get-deployment-context (latest vs. historical) and get-error-analysis vs. get-deployment-context. No overlapping functionality.

Naming Consistency5/5

All tools follow a consistent verb_noun pattern in lowercase snake_case (e.g., abort-environment, get-plan-logs, search-deployments). No mixing of conventions.

Tool Count5/5

14 tools is well-scoped for the domain of environment and deployment management, covering lifecycle actions, inspection, and configuration retrieval without being excessive.

Completeness3/5

Missing environment creation and update tools; only deploy, abort, approve, cancel exist. Also no delete. This creates gaps in the full lifecycle, though deployment inspection and IaC generation are well-covered.

Maintenance

ActivityMaintained
ResponsivenessSyncing

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

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

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

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/env0/mcp-server'

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