fastpanel-mcp

mailbox_password_get

Read-onlyIdempotent

Retrieve a mailbox password from the local macOS Keychain when FastPanel cannot reveal it, only for credentials previously stored by this server.

Instructions

Return the password of a mailbox from the operator's LOCAL password store (macOS Keychain) — not from FastPanel, which never reveals a mailbox password through its API or CLI. Works only when FASTPANEL_PASSWORD_STORE=keychain is set and only for passwords that were set through mailbox_create / mailbox_update while the store was enabled (mailboxes_list shows password_stored per box). If nothing is stored, the only way to get a known password is a reset via mailbox_update generate_password:true — which breaks clients using the old one. SENSITIVE: the result contains a plaintext credential; only call it when the user asks for that mailbox's password. The stored value can be stale if the password was later changed in the panel UI.

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": {
      "address": "<address>"
    },
    "name": "mailbox_password_get"
  }
}

Input Schema

Name	Required	Description	Default
`address`	Yes	Full mailbox address, e.g. support@example.com (the `address` field from mailboxes_list)

Schema Changelog

Changes observed during successful MCP inspections.

Addedv1.3.0Nov 12, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Beyond the read-only/idempotent annotations, the description discloses that the value comes from a local keychain rather than the panel API, depends on an environment flag, may be stale if the password changed in the UI, and returns a plaintext credential. It also warns about the sensitive nature and when it should be called, adding substantial behavioral 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 front-loaded with the core purpose and source, then layers prerequisites, coverage limits, alternatives, and sensitivity warnings. Despite its length, every sentence carries operational value for a sensitive credential-retrieval tool.

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?

With no output schema, the description still makes clear that the result is a plaintext credential and explains the conditions under which retrieval succeeds or fails. It covers prerequisites, staleness, reset alternatives, and sensitivity, which is complete for this one-parameter read 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?

Schema description coverage is 100%, and the single address parameter is already documented as the full mailbox address from mailboxes_list. The description does not add further syntax or meaning beyond that, 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.

Purpose5/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: return the password of a mailbox. It immediately distinguishes the source as the operator's LOCAL password store (macOS Keychain), explicitly not FastPanel, so an agent can tell it apart from mailbox_get and similar siblings.

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?

It gives explicit when-to-use conditions: only when FASTPANEL_PASSWORD_STORE=keychain is set and only for passwords previously set through mailbox_create or mailbox_update while the store was enabled. It also states when not to rely on it (nothing stored), names the reset alternative via mailbox_update generate_password:true, and warns that the reset breaks existing clients.

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