Skip to main content
Glama
ginkida

portainer-mcp

by ginkida

portainer_stack_update

Update or redeploy a Docker stack while preserving env vars. Supports new compose content, env changes, forced image pull, and service pruning.

Instructions

Update (redeploy) an existing stack.

The stack's stored Env variables are always preserved: Portainer replaces the whole Env list on every update, so this tool reads the current list first and merges your changes into it. Omit every optional argument to simply redeploy the stack as it is.

To pick up a newly pushed build of a :latest image, pass pull_image=true — a plain redeploy reuses the image already on the nodes.

Args: stack_id: The ID of the stack to update compose_content: New Docker Compose content (YAML). If omitted, the stored file is redeployed unchanged. Must not contain [REDACTED] (inspect with reveal_env=true first). env: Env variables to add or overwrite, e.g. {"TAG": "v2"} env_remove: Names of Env variables to delete prune: Remove services no longer in the compose file (Swarm only). Defaults to the stack's current setting. pull_image: Force re-pulling images before redeploying (Portainer's "Re-pull image and redeploy"; default false) detach_from_git: Required to update a git-backed stack — Portainer converts it to a plain file-based stack and drops the git link and auto-update. Refused otherwise. endpoint_id: Endpoint ID (derived from the stack itself if omitted)

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
envNo
pruneNo
stack_idYes
env_removeNo
pull_imageNo
endpoint_idNo
compose_contentNo
detach_from_gitNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. Changed5 schema fields changedv0.8.0
    • addedInput schema / properties / detach_from_git
      Added value: +{
      +  "default": false,
      +  "title": "Detach From Git",
      +  "type": "boolean"
      +}
    • addedInput schema / properties / env
      Added value: +{
      +  "anyOf": [
      +    {
      +      "additionalProperties": {
      +        "type": "string"
      +      },
      +      "type": "object"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "title": "Env"
      +}
    • addedInput schema / properties / env_remove
      Added value: +{
      +  "anyOf": [
      +    {
      +      "items": {
      +        "type": "string"
      +      },
      +      "type": "array"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "title": "Env Remove"
      +}
    • addedInput schema / properties / prune
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "boolean"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "title": "Prune"
      +}
    • addedInput schema / properties / pull_image
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "boolean"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "title": "Pull Image"
      +}
  2. First observedv0.3.0

TDQS

A4.8/5.0
Behavior5/5

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

With no annotations, the description carries full responsibility for disclosing behavior. It explains that env variables are preserved and merged, that prune defaults to the current setting, that detach_from_git converts to file-based stacks, and that compose_content must not contain [REDACTED]. These are crucial operational details beyond what the schema provides.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

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

The description is information-dense yet well-structured: the core purpose is stated first, followed by critical behavioral notes, then a bullet-like list of args. Every sentence adds value, and the content is front-loaded with the most important context about env preservation and pull_image.

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 (8 parameters, including env merge logic and git detachment), the description covers all necessary operational details. An output schema exists, so return values need no explanation. Edge cases such as :latest image updates and git-backed stacks are addressed, making the description complete for correct invocation.

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?

Schema description coverage is 0%, so the description must explain every parameter. It does so comprehensively: each argument has a dedicated line with purpose, examples, and conditions (e.g., env example, prune Swarm-only, detach_from_git requirement, endpoint_id auto-derived). This far exceeds minimal parameter documentation.

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 opens with 'Update (redeploy) an existing stack,' which clearly identifies the verb (update/redeploy), the resource (existing stack), and differentiates from sibling tools like portainer_stack_deploy (which creates new stacks). It is specific and unambiguous.

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 usage context, such as when to pass pull_image for :latest images and when detach_from_git is required. It also explains that omitting all optional arguments performs a plain redeploy. However, it does not explicitly contrast with portainer_stack_deploy or other stack operations, so it misses an explicit 'use this instead of X' statement, though the purpose statement implies it.

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

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/ginkida/portainer-mcp'

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