Skip to main content
Glama
oborseth

Official Porkbun MCP Server

List WP Credentials

list_wp_credentials
Read-onlyIdempotent

List WordPress application passwords on a Cloud for WordPress domain to audit or revoke them. Metadata only; passwords can't be re-read.

Instructions

CLOUD FOR WORDPRESS ONLY. List the WordPress application passwords on a domain's site (uuid, name, created, last used) so you can audit them or pick one to revoke. Metadata only — the passwords themselves can never be re-read.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
domainYesDomain whose WordPress site to inspect.
wp_userNoWordPress username (defaults to the dedicated `porkbun-agent` user).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.39.4

TDQS

A4.2/5.0
Behavior4/5

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

Annotations already establish read-only, idempotent, non-destructive behavior. The description adds genuinely new context: that the secrets themselves can never be re-read ('Metadata only'), which prevents an agent from expecting retrievable passwords, and it flags the Cloud-for-WordPress platform restriction.

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 tight sentences with zero filler; the platform restriction is front-loaded and the returned-fields list is compact. Every clause earns its place.

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 two-parameter read-only tool with no output schema, the description covers purpose, scope, returned fields, and the metadata-only limitation. Only pagination or empty-state behavior is unaddressed, a minor gap.

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 both 'domain' and 'wp_user' are already documented with their defaults in the schema. The description adds no parameter-level detail beyond what is structured, making the baseline 3 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?

Specific verb (List) plus resource (WordPress application passwords) with an explicit scope qualifier ('CLOUD FOR WORDPRESS ONLY') and an enumeration of returned fields. It is clearly distinguishable from the sibling create_wp_credentials and delete_wp_credentials tools.

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?

States the two motivating use cases ('audit them or pick one to revoke'), which gives an agent a clear reason to select this over the create/delete siblings. It lacks an explicit when-not or prerequisite statement, but the usage context is unambiguous.

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