Skip to main content
Glama
Sign In
mcp-1panel-plus

mcp-1panel-plus

by EC061
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

List Installed Apps

list_installed_apps
Read-only

Lists installed App Store applications on a selected node, including update flags and ports, while stripping secrets and docker-compose contents.

Instructions

List installed App Store applications on the selected node, including canUpdate flags and ports. Environment secrets and docker-compose contents are strictly stripped.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "list_installed_apps"
  }
}

Input Schema

NameRequiredDescriptionDefault
nameNoOptional installed app name filter.
pageNo1-indexed page number.
nodeIdNoTarget node ID: "local" for the Main Node, or a numeric string ID (e.g. "3") from list_nodes.local
page_sizeNoItems per page (1-500).
sync_statusNoRefresh container runtime status before listing.
only_upgradableNoWhen true, list only apps with available updates.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

A3.6/5.0
Behavior4/5

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

Annotations already declare this a safe read (readOnlyHint true, destructiveHint false), so the description is not obliged to re-establish safety. It instead adds genuinely non-obvious behavior: environment secrets and docker-compose contents are strictly stripped from results, which tells the agent what it will and will not see. It does not discuss pagination limits or the cost of the refresh flag, leaving minor gaps.

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?

Two sentences, front-loaded with the action and scope, with zero redundant restatement of the title or schema. The second sentence carries real information about what is excluded from results rather than padding.

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 read-only paginated list with six fully documented parameters and no output schema, the description covers action, scope, and notable result characteristics (update flags, ports, stripped secrets). Return shape and pagination are not spelled out, but the schema and annotations cover enough that the omission is small.

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 every parameter (name, page, nodeId, page_size, sync_status, only_upgradable) is already fully documented in the schema. The description reinforces node targeting and mentions port data but adds no format, default, or interaction details beyond the schema. Baseline 3 is appropriate when the schema carries the semantics.

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 states a specific verb and resource ("List installed App Store applications") and pins the scope to a single node. It also names the concrete payload fields (canUpdate flags, ports), so an agent knows what it returns. It does not explicitly contrast with get_installed_app, but the singular/plural distinction in the names makes the boundary readable.

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 statement of when to use this tool versus get_installed_app, list_app_versions, or list_containers, and no prerequisites or exclusions. The only routing hint is "on the selected node," which is a scoping remark rather than usage guidance. The agent must infer when this listing is the right call.

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

Deploy Server

Other Tools