Skip to main content
Glama
severity1

terraform-cloud-mcp

discard_run

Cancel a paused Terraform Cloud run without applying changes, unlocking the workspace for new runs when plans show undesired modifications.

Instructions

Discard a run that is paused waiting for confirmation

Cancels a run without applying its changes, typically used when the plan shows undesired changes or after reviewing and rejecting a plan. This action removes the run from the queue and unlocks the workspace for new runs.

API endpoint: POST /runs/{run_id}/actions/discard

Args: run_id: The ID of the run to discard (format: "run-xxxxxxxx") comment: An optional explanation for why the run was discarded

Returns: Run status update with discarded state information, timestamp of the discard action, and user information

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

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
run_idYes
commentNo

Implementation Reference

  • The main handler function that executes the discard_run tool by POSTing to the Terraform Cloud API /runs/{run_id}/actions/discard endpoint with optional comment payload.
    @handle_api_errors
    async def discard_run(run_id: str, comment: str = "") -> APIResponse:
        """Discard a run that is paused waiting for confirmation
    
        Cancels a run without applying its changes, typically used when the plan
        shows undesired changes or after reviewing and rejecting a plan. This action
        removes the run from the queue and unlocks the workspace for new runs.
    
        API endpoint: POST /runs/{run_id}/actions/discard
    
        Args:
            run_id: The ID of the run to discard (format: "run-xxxxxxxx")
            comment: An optional explanation for why the run was discarded
    
        Returns:
            Run status update with discarded state information, timestamp of the
            discard action, and user information
    
        See:
            docs/tools/run.md for reference documentation
        """
        request = RunActionRequest(run_id=run_id, comment=comment)
    
        # Create payload if comment is provided
        payload = {}
        if request.comment:
            payload = {"comment": request.comment}
    
        # Make API request
        return await api_request(
            f"runs/{run_id}/actions/discard", method="POST", data=payload
        )
  • Pydantic model defining the input schema (run_id and optional comment) used by the discard_run handler for validation.
    class RunActionRequest(APIRequest):
        """Base request model for run actions like apply, discard, cancel, etc.
    
        This model provides common fields used in run action requests such as
        applying, discarding, or canceling runs. It includes the run ID and
        an optional comment field that can be included with the action.
    
        Reference: https://developer.hashicorp.com/terraform/cloud-docs/api-docs/run#apply-a-run
    
        Note:
            This model is used for multiple run action endpoints that share the
            same basic structure but perform different operations on the run.
    
        See:
            docs/models/run.md for reference
        """
    
        run_id: str = Field(
            ...,
            # No alias needed as field name matches API field name
            description="The ID of the run to perform an action on",
            pattern=r"^run-[a-zA-Z0-9]{16}$",
        )
        comment: Optional[str] = Field(
            None,
            # No alias needed as field name matches API field name
            description="An optional comment about the run",
        )
  • MCP tool registration for discard_run using FastMCP's mcp.tool decorator with write permissions configuration.
    mcp.tool(**write_tool_config)(runs.discard_run)
Behavior4/5

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

Annotations indicate readOnlyHint=false (non-read-only), which aligns with the destructive action described. The description adds valuable behavioral context beyond annotations: it explains that the action 'removes the run from the queue and unlocks the workspace for new runs,' discloses it's a POST API call, and mentions the return format. No contradiction with annotations.

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 appropriately sized and front-loaded with the core purpose in the first sentence. However, it includes some redundant information like the API endpoint and 'See:' reference, which could be trimmed for better conciseness without losing essential guidance.

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?

Given the tool's complexity (destructive action, 2 parameters, no output schema), the description is quite complete: it covers purpose, usage, parameters, behavior, and return values. The main gap is lack of explicit error handling or prerequisites, but it provides sufficient context for safe invocation.

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?

With 0% schema description coverage, the description compensates well by explaining both parameters: 'run_id' is described as 'The ID of the run to discard' with format details, and 'comment' as 'An optional explanation for why the run was discarded.' This adds clear meaning beyond the bare 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?

The description clearly states the specific action ('discard a run that is paused waiting for confirmation') and distinguishes it from siblings like 'cancel_run' and 'force_cancel_run' by specifying it's for runs that are paused and waiting for confirmation, without applying changes. It explicitly mentions the resource ('run') and the verb ('discard').

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?

The description provides explicit guidance on when to use this tool ('typically used when the plan shows undesired changes or after reviewing and rejecting a plan') and what it does ('Cancels a run without applying its changes'). It distinguishes from alternatives by specifying it's for 'paused waiting for confirmation' runs, unlike 'cancel_run' which might apply to other run states.

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