Skip to main content
Glama

List Deploy Runs

tfruns
Read-only

INSPECTION: List all Terraform deployment runs for a session Returns job IDs, statuses, types (apply/destroy), and timestamps for every run. Use this to see deployment history, find job IDs for log inspection, or check which deployments succeeded or failed.

REQUIRES: session_id from convoopen response (format: sess_v2_...).

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "session_id": "<session_id>"
    },
    "name": "tfruns"
  }
}

Input Schema

NameRequiredDescriptionDefault
session_idYesSession ID from convoopen — pass back EXACTLY as returned, including the ?token=... suffix (format: sess_v2_*?token=*). The suffix is part of the session credential; never strip it when summarizing. Returns the deployment-job history (apply / destroy / plan / drift) for this session.

Output Schema

NameRequiredDescriptionDefault
runsNoDeploy job history, newest first.
countNoNumber of runs the backend reported.
hintsNoGuidance for the calling agent: what to do next and which tools relate to this result.
session_idNoSession ID these runs belong to.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
      +  "properties": {
      +    "count": {
      +      "description": "Number of runs the backend reported.",
      +      "type": "integer"
      +    },
      +    "hints": {
      +      "description": "Guidance for the calling agent: what to do next and which tools relate to this result.",
      +      "properties": {
      +        "next_actions": {
      +          "description": "Suggested next steps, in order, often as ready-to-run tool calls.",
      +          "items": {
      +            "description": "One suggested next step.",
      +            "type": "string"
      +          },
      +          "type": [
      +            "null",
      +            "array"
      +          ]
      +        },
      +        "related_tools": {
      +          "description": "Names of tools that are useful after this result.",
      +          "items": {
      +            "description": "A tool name.",
      +            "type": "string"
      +          },
      +          "type": [
      +            "null",
      +            "array"
      +          ]
      +        }
      +      },
      +      "type": [
      +        "null",
      +        "object"
      +      ]
      +    },
      +    "runs": {
      +      "description": "Deploy job history, newest first.",
      +      "items": {
      +        "description": "One deploy job.",
      +        "properties": {
      +          "cloud": {
      +            "description": "Cloud provider the job ran against.",
      +            "type": "string"
      +          },
      +          "created_at": {
      +            "description": "Job creation time (RFC 3339).",
      +            "type": "string"
      +          },
      +          "job_id": {
      +            "description": "Job ID. Pass it to tfstatus, tflogs or tfoutputs.",
      +            "type": "string"
      +          },
      +          "job_key": {
      +            "description": "Job type key.",
      +            "type": "string"
      +          },
      +          "job_type": {
      +            "description": "Job type: apply, destroy, plan or drift.",
      +            "type": "string"
      +          },
      +          "project_id": {
      +            "description": "Deploy runner project ID.",
      +            "type": "string"
      +          },
      +          "status": {
      +            "description": "Job status.",
      +            "type": "string"
      +          },
      +          "updated_at": {
      +            "description": "Time of the job's last status change (RFC 3339).",
      +            "type": "string"
      +          },
      +          "version_id": {
      +            "description": "ID of the stack version the job ran.",
      +            "type": "string"
      +          }
      +        },
      +        "type": [
      +          "null",
      +          "object"
      +        ]
      +      },
      +      "type": [
      +        "null",
      +        "array"
      +      ]
      +    },
      +    "session_id": {
      +      "description": "Session ID these runs belong to.",
      +      "type": "string"
      +    }
      +  },
      +  "type": "object"
      +}
  2. Changed2 schema fields changed
    • addedInput schema / properties / session_id / description
      Added value: +"Session ID from convoopen — pass back EXACTLY as returned, including the ?token=... suffix (format: sess_v2_*?token=*). The suffix is part of the session credential; never strip it when summarizing. Returns the deployment-job history (apply / destroy / plan / drift) for this session."
    • addedInput schema / properties / session_id / pattern
      Added value: +"^sess_v2_[0-9A-Za-z]+\\?token=[0-9a-f]+$"
  3. First observed

TDQS

A3.9/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds useful behavior beyond that: the returned field set and the credential requirement ('REQUIRES: session_id from convoopen response'). One minor discrepancy: it says types are 'apply/destroy' while the schema lists apply/destroy/plan/drift.

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?

Front-loaded with an INSPECTION label, then purpose, return fields, usage, and prerequisites in clearly separated blocks. Slightly longer than necessary given an output schema exists, but every sentence is relevant and scannable.

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?

With an output schema present, explaining return values is optional, yet the description still covers purpose, usage, and the required credential format, leaving no gap for an agent to call it correctly. The only shortfall is the minor type-list mismatch with the schema.

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%, so the parameter's format and token-suffix warning are already fully documented in the schema. The description only restates the source tool (convoopen) and a truncated format hint, adding little beyond what the schema provides — the baseline of 3 is appropriate.

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?

States a specific verb and resource ('List all Terraform deployment runs for a session') and names the exact fields returned (job IDs, statuses, types, timestamps). It is clearly distinguishable from log- or status-oriented siblings, though it never names a sibling explicitly.

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?

Gives three concrete use cases — viewing deployment history, finding job IDs for log inspection, and checking success/failure — which routes the agent well. It does not, however, state when to prefer another tool (e.g. tflogs or tfstatus) or any exclusion.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources