Skip to main content
Glama

Compare Stack Versions

stackdiff
Read-only

Structured diff showing what would be deployed if the user ran tfdeploy now. Returns component-level changes (added/removed/modified), field-level details, and pricing deltas.

Defaults (#1392): with no version arguments, compares the LAST SUCCESSFULLY DEPLOYED version against the user's CURRENT LIVE DESIGN (the same data the UI shows). Empty baseline if nothing has been deployed or after a destroy. Pending drafts are NOT used as the target — they go stale once the user edits past them; live IR via chat history is always current.

Pass explicit from_version and/or to_version integers to compare any two saved versions (e.g. v3 → v5).

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": "stackdiff"
  }
}

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.
to_versionNoEnding stack version number for the diff. Defaults to the current draft.
from_versionNoStarting stack version number for the diff. Defaults to the latest applied version.

Output Schema

NameRequiredDescriptionDefault
hintsNoGuidance for the calling agent: what to do next and which tools relate to this result.
summaryNoSummary of the differences.
componentsNoChanged components, each with key, change and per-field from/to values.
to_versionNoVersion number the diff ends at.
from_versionNoVersion number the diff starts from.
pricing_deltaNoMonthly cost before and after (from_total, to_total).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
      +  "properties": {
      +    "components": {
      +      "description": "Changed components, each with key, change and per-field from/to values.",
      +      "items": {
      +        "description": "One changed component.",
      +        "type": [
      +          "null",
      +          "object"
      +        ]
      +      },
      +      "type": [
      +        "null",
      +        "array"
      +      ]
      +    },
      +    "from_version": {
      +      "description": "Version number the diff starts from."
      +    },
      +    "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"
      +      ]
      +    },
      +    "pricing_delta": {
      +      "description": "Monthly cost before and after (from_total, to_total).",
      +      "type": [
      +        "null",
      +        "object"
      +      ]
      +    },
      +    "summary": {
      +      "description": "Summary of the differences."
      +    },
      +    "to_version": {
      +      "description": "Version number the diff ends at."
      +    }
      +  },
      +  "type": "object"
      +}
  2. Changed4 schema fields changed
    • addedInput schema / properties / from_version / description
      Added value: +"Starting stack version number for the diff. Defaults to the latest applied version."
    • 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."
    • addedInput schema / properties / session_id / pattern
      Added value: +"^sess_v2_[0-9A-Za-z]+\\?token=[0-9a-f]+$"
    • addedInput schema / properties / to_version / description
      Added value: +"Ending stack version number for the diff. Defaults to the current draft."
  3. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Annotations already mark this as read-only and open-world, and the description adds substantial non-obvious behavior: the default comparison target, empty baseline after a destroy, staleness of pending drafts, and the fact that live IR via chat history is always current. These details materially affect how the agent interprets the diff.

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-loads the core output description, then groups default behavior, explicit-version usage, and session prerequisite in short paragraphs. Every sentence contributes, though the chat-history justification and format repetition add some length beyond the minimum.

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 the tool's complexity and the presence of an output schema plus read-only annotations, the description provides all missing context: prerequisite session credential, default behavior, explicit-version semantics, and edge cases like empty baselines. Nothing needed to call it correctly is absent.

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% and already documents session_id format and version parameters, but the description adds meaning by correcting the default target (live design, not pending draft) and by stating that explicit integers compare any two saved versions. Some session_id format detail is repeated from the schema, keeping this from a 5.

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?

Names a specific verb (compare/diff) and resource (stack versions), states the output is a structured diff of what tfdeploy would deploy now, and implicitly separates it from sibling stackversions/tfplan by focusing on version-to-version comparison. An agent can identify the operation without opening the schema.

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?

Explains when to rely on default behavior (no version arguments compare the last successfully deployed version against the current live design) and when to pass explicit from_version/to_version integers to compare saved versions. It adds important caveats about pending drafts and empty baselines, but does not explicitly name sibling alternatives such as using stackversions to list versions first.

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