Skip to main content
Glama

plugin_privileges

Read-only

Review which host privileges a Docker plugin requests before you install it, without installing anything.

Instructions

Ask the registry which host privileges a not-yet-installed plugin demands.

The review step before plugin_install, which grants these privileges non-interactively (the daemon never prompts) — so this is the only chance to see what a plugin wants before it has it. Worth checking for anything not already trusted: plugins routinely request host mounts, devices, and elevated capabilities, and a granted privilege is host-level access, not container-scoped. Reads the remote plugin from its registry and installs nothing; for the privileges of a plugin already installed, read Config from plugin_inspect instead. Credentials come from system_login, or from ~/.docker/config.json if the host ran docker login. Raises if the reference cannot be resolved in the registry.

args: remote - Registry plugin reference, author/name:tag; the :latest tag is optional and is the default if omitted returns: list - One dict per requested privilege ({"Name", "Description", "Value"}), e.g. Name "mount" with Value ["/data"], or "capabilities" with Value ["CAP_SYS_ADMIN"]; empty if the plugin requests none

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
remoteYes
Behavior5/5

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

Description adds substantial behavioral context beyond the readOnlyHint/destructiveHint annotations: it reads remote plugin data without installing, may raise on unresolved references, relies on credentials from system_login or ~/.docker/config.json, and explains the security significance of host-level privileges. No contradictions with annotations.

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?

Despite its length, every sentence earns its place. The description is front-loaded with purpose, uses structured 'args' and 'returns' sections, and avoids redundancy. It's detailed but not bloated.

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?

The description is fully complete for a tool with one parameter and no output schema: it covers return format with examples, error behavior, authentication, and use-case context. Nothing essential is missing.

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?

The single parameter 'remote' is fully explained with format ('author/name:tag'), optional ':latest' default, and return structure. Schema coverage is 0%, so the description completely compensates, leaving no ambiguity.

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 purpose: 'Ask the registry which host privileges a not-yet-installed plugin demands.' It distinguishes itself from sibling tools by explicitly specializing in uninstalled plugins and contrasts with plugin_inspect for installed plugins.

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

Usage Guidelines5/5

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

The description gives explicit when-to-use guidance: 'The review step before plugin_install' and warns of non-interactive grants. It also names the alternative for installed plugins: 'read Config from plugin_inspect instead.' This is clear, actionable, and specific.

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/L337-org/docker-mcp'

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