portainer-mcp-server

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.0
Disambiguation4/5
Most tools target distinct resource-action pairs, but list_images and portainer_list_unused_images overlap in purpose, as do delete_image and portainer_cleanup_unused_images. However, the names and descriptions clearly distinguish 'all' vs 'unused' variants, reducing ambiguity.
Naming Consistency3/5
The majority follow a verb_noun pattern (list_, get_, inspect_, start_, stop_, etc.), but the two tools prefixed with portainer_ (portainer_list_unused_images, portainer_cleanup_unused_images) break the pattern. The mix of list/get/inspect verbs is also slightly inconsistent, though still readable.
Tool Count4/5
18 tools is on the heavier side but reasonable for a Docker/Portainer management server covering environments, containers, images, stacks, networks, and volumes. Each tool serves a distinct purpose, with no apparent duplication.
Completeness3/5
The toolset covers container lifecycle (start/stop/restart/recreate), image management (pull/delete/cleanup), and stack inspection, but lacks container removal, stack create/update/delete, and network/volume mutations. These are notable gaps for a comprehensive Portainer manager.
Average 3.3/5 across 18 of 18 tools scored. Lowest: 2.7/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior1/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 only says 'get detailed info', which implies a read operation, but doesn't mention potential errors, permissions, or whether the container must be running. There is no disclosure of any side effects or limitations.
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 a single, concise sentence with no redundant modifiers or filler. It is appropriately short and front-loaded, stating the core purpose without unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there is no output schema and no annotations, the description fails to explain what 'detailed info' includes, how the response is structured, or whether it includes runtime status, configuration, network settings, etc. The tool appears relatively simple with two well-documented parameters, but the lack of context for the output makes it incomplete for an agent deciding whether this tool fits the task.
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?
The input schema already provides descriptions for both parameters (containerId and environmentId) with 100% coverage, so the description adds no extra meaning beyond what is in the schema. The baseline of 3 applies because parameter semantics are fully covered structurally.
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 identifies the action (get) and resource (container), and adds 'detailed info' to hint at the depth of data. It distinguishes somewhat from sibling list_containers and get_container_logs, but doesn't enumerate exactly what information is returned.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like list_containers or inspect_stack. It doesn't state any prerequisites, complementary tools, or scenarios where this is the preferred choice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Restart a container' reveals nothing about side effects (e.g., downtime), required permissions, reversibility, or what the response will contain. This is a mutation tool with zero transparency beyond the action itself.
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 a single short sentence, front-loaded with the verb and resource. It contains no redundant words or filler, achieving maximum conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description is expected to explain more. It fails to mention what happens after restart, whether the operation is synchronous, or any confirmation details. The schema covers parameters but not the broader operational context, leaving the description incomplete for an agent invoking the tool.
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?
The input schema fully describes both parameters (containerId: 'Container ID or name'; environmentId: 'Portainer environment ID') with 100% coverage. The description adds no additional parameter guidance, so the baseline 3 is appropriate per the rubric.
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 'Restart a container' clearly states the specific action (restart) on a specific resource (container). This distinguishes it from sibling tools like start_container, stop_container, and recreate_container. However, it does not explicitly mention the Portainer context or contrast with these alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives, preconditions (e.g., container must exist), or expected effects. The description is a bare action statement without any context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It simply states the action without noting that deletion is permanent, may fail if the image is in use, or that the 'force' parameter affects behavior. This is a significant transparency gap for a mutation tool.
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 a single, concise sentence with no filler words or redundancy. It is efficiently front-loaded and entirely on-topic, earning the maximum score for conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple delete operation, the description is arguably too terse. There is no output schema and no annotations, so the description should at least mention potential outcomes (e.g., success/failure indicators) or consequences (e.g., image removal may be blocked if in use). The provided text leaves the agent without enough behavioral context.
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%, with each parameter (force, imageId, environmentId) having a clear description. The tool description adds no additional parameter semantics, but since the schema already documents them well, a baseline score 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?
The description 'Delete a Docker image' clearly states the verb (delete) and resource (Docker image), which distinguishes it from sibling tools like pull_image and portainer_cleanup_unused_images. However, it lacks any additional scope detail (e.g., 'from a Portainer environment') that would make the purpose fully unambiguous, so it doesn't earn a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. It does not mention prerequisites, exclusions, or situations where a different tool (e.g., cleanup unused images) would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for behavioral disclosure. It does not mention that logs come from stdout/stderr, that only a limited number of lines are returned by default, or that the operation is read-only. The description is too minimal to inform the agent about expected behavior.
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 a single concise sentence with no redundant words. It is perfectly front-loaded and each word is meaningful, even if more detail could be added without sacrificing brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is too sparse for effective tool selection and invocation. It does not mention the default tail limit, the optional timestamps flag, or that logs are returned as text lines. With no annotations and no output schema, the description should include these crucial behavioral details.
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?
The input schema fully describes all four parameters, including tail (with default) and timestamps. The description adds no parameter-specific information, but schema coverage is 100%, so a 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?
The description clearly identifies the action (get) and resource (logs from a container), which distinguishes it from siblings like inspect_container. However, it lacks any scope details or explicit differentiation from other tools, making it clear but not maximally specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no context on when to use this tool instead of alternatives such as inspect_container or list_containers. No exclusions, prerequisites, or alternative tool references are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for disclosing behavioral traits. It only states 'Get details', which implies a read operation but does not mention permissions, error behavior, rate limits, or whether any state is changed. This is a significant gap for a tool that might interact with a remote system.
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 a single concise sentence that states the essential purpose. It is front-loaded and contains no redundant or irrelevant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema, the description should explain what 'details' are returned (e.g., stack status, configuration, services). It does not, leaving the agent without a clear understanding of the return value. The simple parameter reduces complexity, but the lack of output information makes it incomplete for practical use.
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?
The schema fully describes the single parameter stackId with the description 'Stack ID', giving 100% coverage. The tool description adds no extra context about the parameter, so the baseline score 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?
The description clearly states the tool's action ('Get details') and resource ('specific stack'), distinguishing it from sibling tools like list_stacks (which lists stacks) and get_stack_file (which retrieves stack files). However, it does not specify what kind of details are returned, leaving some ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives. It does not mention any prerequisites, exclusions, or explicit context for selecting inspect_stack over list_stacks or get_container_logs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. 'Start a stopped container' does not disclose whether the operation is idempotent, what happens if the container is already running, required permissions, or failure modes. This is a significant gap for a mutation tool.
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 a single, front-loaded sentence with no wasted words. It is concise and easy to parse, though it is terse and lacks additional context that could improve usefulness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutating tool with no annotations and no output schema, the description is minimal. It does not explain when to use the tool, potential side effects, or the expected outcome beyond 'start'. This is inadequate for an agent to fully understand the tool's role.
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?
The input schema provides descriptions for both parameters (containerId and environmentId), giving 100% coverage. The description adds no parameter-specific meaning, so the baseline of 3 applies.
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 uses a specific verb ('start') and resource ('container'), and clearly qualifies the target state ('stopped'), which distinguishes it from siblings like stop, restart, or inspect. This is a precise and unambiguous statement of what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. The text does not mention when to use this tool over alternatives such as restart_container or recreate_container, nor does it state any prerequisites or exclusions. It only restates the action without contextual direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden of behavioral disclosure. It states the core operation ('List') but does not disclose output format, sorting, pagination, required permissions, or any side effects. The minimal phrase 'in an environment' adds limited context.
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 a single, front-loaded sentence that is highly concise and free of any fluff. It conveys the essential purpose in complete clarity without waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (one parameter, no output schema), but the description does not explain what the tool returns (e.g., list of image IDs, tags, sizes). Since there is no output schema and no annotations, the description is incomplete for an agent to fully anticipate the response.
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?
The schema has full description coverage (100%) for the single parameter environmentId, so the baseline is 3. The description's mention of 'an environment' aligns with this parameter but adds no additional semantic detail beyond the schema's own description.
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 verb 'List', the resource 'Docker images', and the scope 'in an environment'. This distinguishes it from sibling tools like list_containers or list_environments by explicitly naming images as the target.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description does not mention any conditions, exclusions, or comparisons with sibling tools such as pull_image or delete_image.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It does indicate a destructive action ('Delete all unused Docker images') and mentions the force flag, but it fails to mention irreversibility, permission requirements, the role of environmentId, or what 'unused' precisely means. This is a significant gap for a potentially destructive operation.
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 a single, front-loaded sentence with no redundant details. Every word contributes meaning, and it includes the key qualifier 'all unused' and the optional force flag.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's destructive nature, lack of annotations, and no output schema, the description is incomplete. It does not explain the scope of the deletion across environments, the meaning of 'unused', or how it differs from related tools, leaving essential context missing for safe and correct use.
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 baseline is 3. The description adds 'optional force flag' which is already documented in the schema, adding no extra meaning beyond what the structured schema provides.
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 uses the specific verb 'Delete' with the resource 'all unused Docker images' and highlights the optional force flag. This clearly distinguishes it from sibling tools like delete_image (which targets a specific image) and portainer_list_unused_images (which only lists).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as delete_image or when not to use it (e.g., if images are in use). It only states what the tool does, leaving the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden. It only states the action without disclosing side effects (e.g., whether it is a graceful stop or force kill), permission requirements, or state changes. This is minimal behavioral disclosure.
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 a single short sentence, front-loaded and free of redundancy. While it is concise, it adds only slightly more than the tool name itself, preventing a perfect score.
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 simple two-parameter stop operation, the description covers the core action. However, with no annotations, no output schema, and no notes on error behavior or idempotency, it is minimally viable but not fully complete.
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%, with both containerId and environmentId described in the schema. The tool description adds no extra parameter context, but the schema already provides adequate meaning, meeting the baseline.
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 'Stop a running container' uses a specific verb 'stop' and resource 'container', clearly distinguishing it from sibling tools like start_container and restart_container. It is concise 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as start_container or restart_container. It does not mention prerequisites like the container needing to be running or how to obtain the environmentId.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description is minimal and goes no further than what the verb 'list' implies. There is no mention of potential pagination, error handling, permission requirements, or whether the environment ID must be valid. With no annotations provided, this lack of behavioral disclosure is a significant gap.
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 a single concise sentence that front-loads the verb and resource with no unnecessary words. It earns its place without any fluff.
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?
Given the tool's simplicity (one well-documented parameter, no output schema), the description conveys the basic purpose. However, it lacks any usage context, return-value details, or behavioral notes, making it only minimally complete for operational use.
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 coverage is 100%—the only parameter, environmentId, is uniquely described as 'Portainer environment ID'. The description adds no additional meaning about this parameter or how it affects the listing, so it provides no extra value beyond the 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 action (List), the resource (Docker networks), and the scope (in an environment). This distinguishes it from sibling tools that operate on different resources like containers, images, or volumes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as list_containers or list_volumes. The description lacks context about prerequisites or exclusions, leaving the agent without clear selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the action without noting that pulling downloads data into the environment, may require registry credentials, can fail if the image does not exist, or may overwrite an existing tag. This is a significant gap for a side-effectful operation.
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 a single concise sentence with no unnecessary words. It is front-loaded with the verb and resource, making it easy to parse quickly. Every word earns its place.
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?
The tool has only 2 parameters and no output schema, and the description does state the core purpose. However, it lacks behavioral context such as side effects and failure conditions, and provides no usage guidance. While the basics are covered, important contextual details are missing, preventing a higher score.
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?
The schema covers 100% of parameters with descriptive comments (image name and environment ID), so the description adds no additional parameter information. The baseline of 3 is appropriate because the schema does the heavy lifting and the tool has only two simple parameters.
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 uses the specific verb 'pull' and the resource 'Docker image', also indicating the source 'from a registry'. This clearly distinguishes it from sibling tools like delete_image and list_images, and it is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It lacks any context about prerequisites (e.g., environment must exist), conditions (e.g., image not already present), or alternatives such as list_images or inspect_image.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of disclosing behavior. It only states the action without any detail on return format, pagination, error handling, or permissions. For a list operation, agents would benefit from knowing the response shape or any failure modes.
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 a single, direct sentence that gets to the point immediately. There is no filler or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there is no output schema, the description should at least hint at the response contents (e.g., a list of volume objects). It also does not connect to the sibling list_environments for obtaining the required ID. Despite the low complexity, the description is under-specified for complete context.
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?
The sole parameter environmentId is fully described in the schema with 'Portainer environment ID' (100% coverage). The description does not add extra semantics beyond that, but none are needed given the schema clarity.
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 action (List), the resource (Docker volumes), and the scope (in an environment). This distinguishes it from sibling tools like list_containers and list_networks by specifying the exact resource type.
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 the tool is used to retrieve volumes for a given environment, but it does not explicitly state when to prefer it over alternatives or mention any prerequisites such as obtaining the environment ID from list_environments. This is a minimal but not misleading level of guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It only states the action without mentioning what the response contains, default behaviors (e.g., that the 'all' parameter defaults to true), or any side effects. The description is essentially a restatement of the tool's purpose and lacks behavioral context beyond the name.
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 a single concise sentence with no redundant words. It is perfectly front-loaded and every word contributes to the meaning.
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 simple list tool, the description is minimally adequate but lacks context about return value shape (no output schema exists) and any guidance on typical usage. The schema provides parameter details, but the description does not compensate for the absence of output schema or make the tool more self-explanatory.
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% with both parameters ('environmentId' and 'all') having meaningful descriptions. The tool description adds no additional parameter semantics or context beyond what the schema already provides, so the baseline of 3 is appropriate.
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 action (list) and resource (containers) with an environment scoping. It distinguishes itself from sibling tools like inspect_container (single container details) and get_container_logs (logs), making its purpose unambiguous.
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 for listing containers within a specific Portainer environment, but it does not explicitly state when to choose this over alternatives (e.g., inspect_container for details, list_environments for environment info). No exclusions or alternative recommendations are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only says 'Get the docker-compose file content,' without elaborating on return format, error behavior, permissions required, or any side effects. For a read operation, this is minimal but lacks useful context beyond the basic action.
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 a single, front-loaded sentence with no filler or redundant information. It conveys the essential purpose efficiently.
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 simplicity (one fully described parameter, no complex logic), the description sufficiently explains what it does and what the agent needs to provide. However, the absence of any output schema or behavioral notes means the agent may not know the exact structure of the returned content, but this is not a major gap for such a straightforward getter.
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?
The schema covers the only parameter (stackId) with a clear description ('Stack ID'). The tool description adds no additional meaning beyond what the schema already provides, so the baseline of 3 applies.
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 uses a specific verb ('Get') and resource ('docker-compose file content of a stack'), clearly distinguishing it from sibling tools like inspect_stack or list_stacks. It unambiguously states what the tool returns.
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 usage is implied: the agent should use this when the docker-compose file content of a stack is needed. However, there is no explicit guidance on when not to use it or mention of alternatives like inspect_stack, which might provide similar stack information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only states 'List all stacks' without disclosing any behavioral traits such as return format, authentication requirements, scoping, or whether it's read-only. While listing is generally safe, the description adds minimal context beyond the name.
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 a single, coherent sentence that immediately states the action and resource. It is front-loaded and contains no verbose or redundant information, making it extremely concise.
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 simplicity of a 0-parameter list tool with no output schema, the description 'List all stacks in Portainer' is contextually complete for the core function. However, it could optionally mention any caveats (e.g., whether stacks from all environments are included), but this is not critical for a basic list operation.
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?
The tool has 0 parameters and schema coverage is 100%, so the description has no parameter semantics to add. Per the rubric, 0 params qualifies for a baseline of 4. The description adequately implies no inputs are needed.
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 'List all stacks in Portainer' uses a specific verb (List) and resource (stacks), clearly stating the action and scope ('all'). It distinguishes from sibling tools by naming the exact resource type, making it unambiguous which tool to select when stacks are needed.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. While siblings include similar list tools for other resources, the description doesn't explicitly state the intended context or contrast with tools like inspect_stack or get_stack_file. The usage is implied by the resource name but not explicitly articulated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses three key behavioral steps: stops old container, pulls new image, starts new container. However, it is vague about whether the old container is removed, whether persistent volumes are preserved, and what happens to container configuration. The term 'recreate' implies a new container but the details of cleanup and data handling are not specified.
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 a single, well-structured sentence that front-loads the action and uses a parenthetical to list the main steps. It is concise with zero filler, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema and no annotations, so the description must fully explain the tool's behavior, side effects, and return value. It omits critical information for a container recreation operation: whether the old container is destroyed, whether configuration and volumes are preserved, what the result contains, and expected downtime. This is inadequate for a potentially destructive tool.
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?
The input schema provides full descriptions for all three parameters (100% coverage), so the schema already handles parameter meaning. The description adds no additional parameter-specific information beyond the purpose, so baseline 3 is appropriate.
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 tool's function: 'Recreate a container with an updated image'. It uses a specific verb and resource, and the parenthetical ('stops old container, pulls new image, starts new container') distinguishes it from sibling tools like start/stop/restart, which do not involve pulling a new image.
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 use case is implied by 'with an updated image', but there is no explicit guidance on when to use this tool versus alternatives like pull_image followed by start_container, nor any 'when not to use' or exclusion information. The description provides some context but no direct alternatives or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It states 'List all Portainer environments/endpoints,' which implicitly indicates a read-only operation, but it does not disclose any other behavioral traits such as authentication requirements, pagination, potential delays, or side effects. This is minimal but adequate for a simple list tool.
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 a single, efficient sentence with no filler or redundant content. It says exactly what the tool does without wasting words.
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 simplicity of the tool, the description is largely complete. It clearly states the action and the target resource. However, since there is no output schema, it might benefit from hinting at what the response contains (e.g., a list of environments with IDs/names), but this is not critical for a list operation.
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?
The tool has zero parameters, and the schema description coverage is 100% (vacuously). Per the rubric, the baseline for 0 parameters is 4. The description adds no parameter-specific information because there are none to document, so this baseline is appropriate.
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 a specific verb ('List') and resource ('Portainer environments/endpoints'), making it obvious what this tool does. It is clearly distinct from sibling tools that list containers, stacks, images, networks, or volumes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. For example, it does not mention when to choose list_environments over list_containers or list_stacks. The description offers only the basic functionality without context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. 'List' clearly signals a read-only operation, and the parenthetical ('dangling images') adds specific filtering behavior beyond the name. It does not explicitly state non-destructive intent or return format, but the verb conveys the key safety trait.
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 a single, well-structured sentence that front-loads the verb and resource. Every word adds value, and the parenthetical clarifies the exact scope without fluff.
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?
For a simple list tool with one documented parameter, the description provides sufficient context about purpose and filtering. It does not describe return fields or pagination, but no output schema is present, and the tool's simplicity makes these omissions acceptable.
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 coverage is 100%, with environmentId fully described as 'Portainer environment ID'. The description adds no extra parameter details, so the baseline of 3 (schema already documents the parameter) is appropriate.
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 uses a specific verb ('List') and a clearly defined resource ('Docker images not used by any container (dangling images)'). This distinguishes it from sibling list_images, which likely lists all images, and directly matches the tool name.
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 a use case (identifying unused/dangling images), but it does not explicitly state when to use this tool versus alternatives like list_images or portainer_cleanup_unused_images. No when/when-not guidance or alternative references are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![portainer-mcp-server MCP server](https://glama.ai/mcp/servers/hlavrencic/portainer-mcp-server/badges/card.svg)](https://glama.ai/mcp/servers/hlavrencic/portainer-mcp-server)

Score Badge

Copy to your README.md:

[![portainer-mcp-server MCP server](https://glama.ai/mcp/servers/hlavrencic/portainer-mcp-server/badges/score.svg)](https://glama.ai/mcp/servers/hlavrencic/portainer-mcp-server)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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

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