Skip to main content
Glama
severity1

terraform-cloud-mcp

create_run

Trigger Terraform Cloud runs to deploy infrastructure, apply configuration changes, or destroy resources by executing plan and apply operations in a workspace.

Instructions

Create a run in a workspace

Creates a new Terraform run to trigger infrastructure changes through Terraform Cloud, representing a single execution of plan and apply operations. The run queues in the workspace and executes based on the workspace's execution mode and settings. Use this to deploy new infrastructure, apply configuration changes, or destroy resources.

API endpoint: POST /runs

Args: workspace_id: The workspace ID to execute the run in (format: "ws-xxxxxxxx") params: Optional run configuration with: - message: Description of the run's purpose - is_destroy: Whether to destroy all resources managed by the workspace - auto_apply: Whether to auto-apply after a successful plan - refresh: Whether to refresh Terraform state before planning - refresh_only: Only refresh the state without planning changes - plan_only: Create a speculative plan without applying - allow_empty_apply: Allow applying when there are no changes - target_addrs: List of resource addresses to specifically target - replace_addrs: List of resource addresses to force replacement - variables: Run-specific variables that override workspace variables - terraform_version: Specific Terraform version to use for this run - save_plan: Save the plan for later execution - debugging_mode: Enable extended debug logging

Returns: The created run details with ID, status, configuration information, workspace relationship, and links to associated resources

See: docs/tools/run.md for reference documentation

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
workspace_idYes
paramsNo

Implementation Reference

  • The main handler function for the 'create_run' tool. It creates a new Terraform run in the specified workspace using the Terraform Cloud API, handling parameters, payload construction, relationships, and variables.
    @handle_api_errors
    async def create_run(
        workspace_id: str,
        params: Optional[RunParams] = None,
    ) -> APIResponse:
        """Create a run in a workspace
    
        Creates a new Terraform run to trigger infrastructure changes through Terraform Cloud,
        representing a single execution of plan and apply operations. The run queues in the
        workspace and executes based on the workspace's execution mode and settings. Use this
        to deploy new infrastructure, apply configuration changes, or destroy resources.
    
        API endpoint: POST /runs
    
        Args:
            workspace_id: The workspace ID to execute the run in (format: "ws-xxxxxxxx")
            params: Optional run configuration with:
                - message: Description of the run's purpose
                - is_destroy: Whether to destroy all resources managed by the workspace
                - auto_apply: Whether to auto-apply after a successful plan
                - refresh: Whether to refresh Terraform state before planning
                - refresh_only: Only refresh the state without planning changes
                - plan_only: Create a speculative plan without applying
                - allow_empty_apply: Allow applying when there are no changes
                - target_addrs: List of resource addresses to specifically target
                - replace_addrs: List of resource addresses to force replacement
                - variables: Run-specific variables that override workspace variables
                - terraform_version: Specific Terraform version to use for this run
                - save_plan: Save the plan for later execution
                - debugging_mode: Enable extended debug logging
    
        Returns:
            The created run details with ID, status, configuration information,
            workspace relationship, and links to associated resources
    
        See:
            docs/tools/run.md for reference documentation
        """
        # Convert optional params to dictionary
        param_dict = params.model_dump(exclude_none=True) if params else {}
    
        # Create validated request object
        request = RunCreateRequest(workspace_id=workspace_id, **param_dict)
    
        # Extract variables for special handling
        variables = request.variables
    
        # Create API payload using utility function
        payload = create_api_payload(
            resource_type="runs",
            model=request,
            exclude_fields={"workspace_id", "variables"},  # Fields handled separately
        )
    
        # Add workspace relationship
        add_relationship(
            payload=payload,
            relation_name="workspace",
            resource_type="workspaces",
            resource_id=workspace_id,
        )
    
        # Add optional configuration version relationship
        if request.configuration_version_id:
            add_relationship(
                payload=payload,
                relation_name="configuration-version",
                resource_type="configuration-versions",
                resource_id=request.configuration_version_id,
            )
    
        # Transform variables to key-value format required by API
        if variables:
            payload["data"]["attributes"]["variables"] = [
                {"key": var.key, "value": var.value} for var in variables
            ]
    
        return await api_request("runs", method="POST", data=payload)
  • Registration of the 'create_run' tool using FastMCP's mcp.tool decorator, with write permissions configuration.
    mcp.tool(**write_tool_config)(runs.create_run)
  • Pydantic model defining the input parameters (schema) for the create_run tool, including fields like message, is_destroy, auto_apply, variables, etc., inherited from BaseRunRequest.
    class RunParams(BaseRunRequest):
        """Parameters for run operations without routing fields.
    
        This model provides all optional parameters that can be used when creating runs,
        reusing the field definitions from BaseRunRequest.
    
        Reference: https://developer.hashicorp.com/terraform/cloud-docs/api-docs/run#create-a-run
    
        Note:
            All fields are inherited from BaseRunRequest.
    
        See:
            docs/models/run.md for reference
        """
    
        # Inherits model_config and all fields from BaseRunRequest
  • Internal Pydantic model used by the create_run handler for API request validation, extending RunParams with workspace_id and configuration_version_id.
    class RunCreateRequest(BaseRunRequest):
        """Request model for creating a Terraform Cloud run.
    
        Validates and structures the request according to the Terraform Cloud API
        requirements for creating runs. The model inherits common run attributes from
        BaseRunRequest and adds workspace_id as a required parameter.
    
        Reference: https://developer.hashicorp.com/terraform/cloud-docs/api-docs/run#create-a-run
    
        Note:
            This inherits all configuration fields from BaseRunRequest
            and adds workspace_id as a required parameter.
            This model is typically used internally by the create_run tool function,
            which accepts parameters directly and constructs the request object.
    
        See:
            docs/models/run.md for reference
        """
    
        # Required fields
        workspace_id: str = Field(
            ...,
            # No alias needed as field name matches API field name
            description="The workspace ID to execute the run in (required)",
            pattern=r"^ws-[a-zA-Z0-9]{16}$",  # Standardized workspace ID pattern
        )
    
        # Optional fields specific to run creation
        configuration_version_id: Optional[str] = Field(
            None,
            alias="configuration-version-id",
            description="The configuration version ID to use",
            pattern=r"^cv-[a-zA-Z0-9]{16}$",
        )
Behavior4/5

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

The description adds valuable behavioral context beyond the readOnlyHint=false annotation. It explains that the run 'queues in the workspace and executes based on the workspace's execution mode and settings,' describes the API endpoint, and provides a detailed returns section. However, it doesn't mention rate limits, authentication 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.

Conciseness4/5

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

The description is well-structured with clear sections (purpose, usage, API endpoint, args, returns, reference). While comprehensive, some sentences could be more concise, and the detailed param list makes it longer than minimal.

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 complex mutation tool with no output schema, the description provides substantial context: purpose, usage, parameters, return values, and API reference. It covers the essential aspects but could benefit from more behavioral details about error handling or execution constraints.

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

Parameters5/5

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

With 0% schema description coverage, the description fully compensates by providing comprehensive parameter documentation. It explains workspace_id format and details 14 specific params with clear explanations of their purposes, going far beyond what the bare schema 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?

The description clearly states the tool creates a new Terraform run to trigger infrastructure changes, specifying it represents a single execution of plan and apply operations. It distinguishes from siblings by focusing on run creation rather than management operations like cancel_run or apply_run.

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 provides clear context for when to use this tool: 'to deploy new infrastructure, apply configuration changes, or destroy resources.' It mentions the run queues in the workspace and executes based on workspace settings, but doesn't explicitly state when NOT to use it or name specific alternatives among sibling tools.

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

Install Server

Other Tools

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/severity1/terraform-cloud-mcp'

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