Skip to main content
Glama
severity1

terraform-cloud-mcp

get_plan_logs

Retrieve detailed execution logs from Terraform Cloud plans to analyze infrastructure changes and troubleshoot deployment issues.

Instructions

Retrieve logs from a plan.

Gets the raw log output from a Terraform Cloud plan operation, providing detailed information about the execution plan.

API endpoint: Uses the log-read-url from GET /plans/{plan_id}

Args: plan_id: The ID of the plan to retrieve logs for (format: "plan-xxxxxxxx")

Returns: The raw logs from the plan operation. The redirect to the log file is automatically followed.

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

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
plan_idYes

Implementation Reference

  • The async handler function that implements the core logic of the get_plan_logs tool. It validates the plan_id, fetches plan details to extract the log-read-url, and retrieves the raw logs.
    @handle_api_errors
    async def get_plan_logs(plan_id: str) -> APIResponse:
        """Retrieve logs from a plan.
    
        Gets the raw log output from a Terraform Cloud plan operation,
        providing detailed information about the execution plan.
    
        API endpoint: Uses the log-read-url from GET /plans/{plan_id}
    
        Args:
            plan_id: The ID of the plan to retrieve logs for (format: "plan-xxxxxxxx")
    
        Returns:
            The raw logs from the plan operation. The redirect to the log file
            is automatically followed.
    
        See:
            docs/tools/plan.md for reference documentation
        """
        # Validate parameters using existing model
        params = PlanRequest(plan_id=plan_id)
    
        # First get plan details to get the log URL
        plan_details = await api_request(f"plans/{params.plan_id}")
    
        # Extract log read URL
        log_read_url = (
            plan_details.get("data", {}).get("attributes", {}).get("log-read-url")
        )
        if not log_read_url:
            return {"error": "No log URL available for this plan"}
    
        # Use the enhanced api_request to fetch logs from the external URL
        return await api_request(log_read_url, external_url=True, accept_text=True)
  • Pydantic-based input schema model (PlanRequest) used for validating the plan_id parameter in the get_plan_logs handler.
    class PlanRequest(APIRequest):
        """Request model for retrieving a plan.
    
        Used to validate the plan ID parameter for API requests.
    
        Reference: https://developer.hashicorp.com/terraform/cloud-docs/api-docs/plans#show-a-plan
    
        See:
            docs/models/plan.md for reference
        """
    
        plan_id: str = Field(
            ...,
            # No alias needed as field name matches API parameter
            description="The ID of the plan to retrieve",
            pattern=r"^plan-[a-zA-Z0-9]{16}$",  # Standard plan ID pattern
        )
  • Tool registration in the MCP server using FastMCP's mcp.tool() decorator, linking to the handler in plans module.
    mcp.tool()(plans.get_plan_logs)
Behavior3/5

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

With no annotations provided, the description carries the full burden. It discloses that the tool 'retrieves' (read operation) and mentions automatic following of redirects to log files, which is useful behavioral context. However, it doesn't cover important aspects like authentication requirements, rate limits, error handling, or whether logs might be large/paginated. The API endpoint reference adds some transparency but isn't comprehensive.

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 statement, API context, Args, Returns, and reference. Each sentence adds value without redundancy. It could be slightly more concise by integrating the API endpoint into the main description rather than as a separate line, but overall it's efficiently organized.

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 single-parameter read tool with no annotations and no output schema, the description provides adequate basics: purpose, parameter details, and return behavior. However, it lacks context about the log format (text, JSON, size), error scenarios, or how this fits into broader Terraform Cloud workflows. The documentation reference helps but doesn't substitute for self-contained completeness.

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 for the single parameter, the description compensates well by explaining 'plan_id: The ID of the plan to retrieve logs for (format: "plan-xxxxxxxx")'. This provides clear semantic meaning and format guidance beyond the bare schema. However, it doesn't explain where to obtain this ID or validate the format pattern.

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 clearly states the tool's purpose: 'Retrieve logs from a plan' with specific context about Terraform Cloud plan operations. It distinguishes this from sibling tools like 'get_plan_details' or 'get_plan_json_output' by focusing on raw log retrieval rather than plan metadata or structured output. However, it doesn't explicitly contrast with 'get_apply_logs' which might retrieve logs from apply operations.

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

Usage Guidelines3/5

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

The description implies usage context by mentioning it retrieves logs from 'plan operations' and references an API endpoint, suggesting it's for accessing execution plan details. It doesn't provide explicit when-to-use guidance versus alternatives like 'get_plan_json_output' for structured data or 'get_apply_logs' for apply operation logs. The 'See' reference to documentation offers potential guidance but isn't direct.

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