Pangolin MCP Connector

Overview Schema Source Related Servers Discussions Admin

pangolin_sites

DestructiveIdempotent

Manage Pangolin sites by listing, creating, updating, deleting, approving, rejecting, restarting, and regenerating credentials; write actions require confirmation and support dry-run previews.

Instructions

pangolin_sites covers the sites toolset (11 operations). Auth header Authorization Bearer. Self-hosted Pangolin CE only. Writes need confirm:true and PANGOLIN_ALLOW_WRITES=true. Omit confirm for a dry-run preview. Actions: approve_site: POST /site/{siteId}/approve. Approve a pending site and approve (and enable when needed) its associated resources. create_org_site: PUT /org/{orgId}/site. Create a new site. delete_site: DELETE /site/{siteId}. Delete a site and all its associated data. get_org_pick_site_defaults: GET /org/{orgId}/pick-site-defaults. Return pre-requisite data for creating a site, such as the exit node, subnet, Newt credentials, etc. get_org_site: GET /org/{orgId}/site/{niceId}. Get a site by orgId and niceId. NiceId is a readable ID for the site and unique on a per org basis. get_site: GET /site/{siteId}. Get a site by siteId. list_org_sites: GET /org/{orgId}/sites. List all sites in an organization regenerate_re_key_site_secret: POST /re-key/{siteId}/regenerate-site-secret. Regenerate the credentials for a site. For newt sites a new secret is required; for wireguard sites a new public key is required. reject_site: POST /site/{siteId}/reject. Reject a pending site by deleting it and any associated resources that are still pending. restart_site: POST /site/{siteId}/restart. Restart a site. update_site: POST /site/{siteId}. Update a site.

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": {
      "action": "<action>"
    },
    "name": "pangolin_sites"
  }
}

Input Schema

Name	Required	Description
`body`	No	JSON body for the Pangolin operation. Secrets are redacted in output.
`query`	No	OpenAPI query parameters.
`action`	Yes	Pangolin operation to call.
`params`	No	OpenAPI path parameters, such as orgId or siteId.
`confirm`	No	Set to the boolean true to execute the write. Omit this field for a dry-run preview. false and the string true are rejected.

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Nov 5, 2026

TDQS

A4.5/5.0

Behavior5/5

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

Annotations already flag destructiveHint=true and readOnlyHint=false, but the description adds behavior the annotations cannot convey: the required Authorization Bearer header, the two-part write gate (confirm:true plus the server-side PANGOLIN_ALLOW_WRITES env flag), and the dry-run preview path when confirm is omitted. It also discloses the blast radius per operation — delete_site removes 'a site and all its associated data' and reject_site deletes still-pending associated resources — which is exactly the detail an agent needs before a destructive call.

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?

Front-loads the auth and write-gating rules before the operation list, and each operation is a single dense line pairing the action name with its verb, path, and effect. The repeated HTTP verb+path per action is somewhat redundant with the action names, but for an 11-operation dispatcher the enumeration earns its length.

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 5-parameter, 11-operation dispatcher with no output schema, the description covers the essentials: auth, write gating, dry-run semantics, which identifier each read needs, and the destructive scope of delete/reject. Remaining gaps are response shape and error behavior, which the absence of an output schema leaves partly unaddressed.

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?

Schema description coverage is 100%, so the baseline would be 3, but the description goes further by mapping each action to its path parameters (orgId, siteId, niceId) and explaining that niceId is a human-readable ID unique per org. It still does not describe the shape of the free-form body or query objects beyond the schema's own note about redaction.

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 opens by naming the resource domain ('sites toolset') and then enumerates all 11 operations with a specific verb plus endpoint each (approve_site, create_org_site, delete_site, list_org_sites, etc.). An agent can distinguish site operations from the sibling pangolin_orgs / pangolin_resources / pangolin_users toolsets without opening any schema.

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?

It gives concrete invocation conditions: writes require confirm:true AND PANGOLIN_ALLOW_WRITES=true, and omitting confirm yields a dry-run preview — that is genuine when-to/how-to guidance. It also scopes the tool ('Self-hosted Pangolin CE only') and implicitly differentiates get_site (siteId) from get_org_site (orgId + niceId), but never explicitly names a sibling tool or states when to use one of those instead.

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

Deploy Server