Skip to main content
Glama
Sign In
Official Porkbun MCP Server

Official Porkbun MCP Server

by oborseth
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

List Site Shares

list_site_shares
Read-onlyIdempotent

List site share access records with domain, recipient, and status (PENDING, ACTIVE, CLAIMED, REVOKED, EXPIRED) to track approvals. For ACTIVE shares, retrieve the share URL, QR code, and handoff prompt.

Instructions

List this account's site shares (share_site_access): domain, who it is for, and status: PENDING (waiting for the account holder to approve), ACTIVE (approved, link not used yet), CLAIMED (the other person connected), REVOKED or EXPIRED. For an ACTIVE share it also returns shareUrl, the one thing to send the other person (it opens a page with a prompt for their AI assistant and the share code), plus qrCodeUrl, and shareCode and handoffPrompt in case you send the message yourself. Those are only returned to keys allowed to hand them out (full access or the account permission). Each share has an id for revoke_site_share.

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_site_shares"
  }
}

Input Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.62.0

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered; the description adds a genuinely non-obvious behavioral rule: `shareCode` and `handoffPrompt` are only returned to keys with full access or the `account` permission. That permission-dependent payload truncation is exactly the kind of thing structured fields cannot express. It omits what an empty list or partial-result condition looks like, keeping it from a 5.

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 verb+resource lead is front-loaded and every clause carries information (status meanings, return fields, permission gate, follow-up tool). It is a single dense run-on sentence rather than clearly separated statements, which slightly hurts scannability but wastes no words.

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 carries the full burden of describing return values and does so thoroughly: `domain`, recipient, `status` with all five values explained, `shareUrl` with what it does when opened, `qrCodeUrl`, `shareCode`, `handoffPrompt`, and `id`. An agent can both interpret every field and complete the handoff workflow from this text alone.

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 takes zero parameters, which is the baseline-4 case; there are no inputs to disambiguate. The description instead spends its budget on output semantics, which is the right allocation here.

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?

Opens with a specific verb and resource ("List this account's site shares") and immediately ties itself to the sibling `share_site_access`, which is the tool that creates them. It also names `revoke_site_share` as the consumer of the returned `id`, so an agent can place this tool in the share lifecycle without guessing.

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?

Italicized status semantics (PENDING/ACTIVE/CLAIMED/REVOKED/EXPIRED) tell the agent how to interpret results and what state the workflow is in, and the mention of `revoke_site_share` implies this is the discovery step before revoking. There is no explicit "use this when..." sentence or statement of when another tool would be better, so it stops just short of full routing guidance.

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