Pangolin MCP Connector

Overview Schema Source Related Servers Discussions Admin

pangolin_orgs

DestructiveIdempotent

Create, view, update, or delete Pangolin organizations and manage user access within them. Includes server admin listing plus bandwidth reset, with dry-run previews for writes.

Instructions

pangolin_orgs covers the orgs toolset (10 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: check_org_user: GET /org/{orgId}/user/{userId}/check. Check a user's access in an organization. create_org: PUT /org. Create a new organization delete_admin_org: DELETE /admin/org/{orgId}. Delete any organization in the system (server admin). delete_org: DELETE /org/{orgId}. Delete an organization get_org: GET /org/{orgId}. Get an organization list_admin_orgs: GET /admin/orgs. List all organizations in the system with usage counts (server admin). list_orgs: GET /orgs. List all organizations in the system. reset_org_bandwidth: POST /org/{orgId}/reset-bandwidth. Reset all sites in selected organization bandwidth counters. update_org: POST /org/{orgId}. Update an organization update_org_user: POST /org/{orgId}/user/{userId}. Update a user in an org.

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

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.4/5.0

Behavior5/5

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

Beyond the annotations (readOnlyHint=false, destructiveHint=true), the description discloses the auth scheme, the self-hosted CE deployment constraint, the write-gating mechanism requiring both confirm:true and an environment flag, and the dry-run-by-default behavior. It also marks the two privileged admin actions that bypass normal org scoping, which is exactly the kind of risk context an agent needs before deleting anything.

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?

Critical operational constraints (auth, deployment scope, write gating, dry-run) are front-loaded before the action catalog, and each action line is a compact verb/endpoint/effect triple. There is minor sloppiness — inconsistent trailing periods and an unpunctuated run between 'create_org' and 'delete_admin_org' — but no sentence is wasted.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 10-action dispatcher with a generic `body` schema (additionalProperties: {}), the description never states what fields create_org or update_org expect, so an agent cannot construct a valid write without guessing. Auth, write-gating, and admin scope are well covered, and no output schema exists to demand return-value documentation, but the body-payload gap is material for the mutation actions.

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 coverage is 100%, so the baseline is 3, but the description adds real value by mapping each enum value to its HTTP endpoint and effect, which tells the agent which path parameters (orgId, userId) each action requires. The `confirm` semantics are restated from the schema rather than extended, and the expected contents of `body`/`query` per action are never described.

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 names the resource domain ('orgs toolset') and enumerates all 10 actions with an explicit verb plus resource for each (e.g. 'create_org: PUT /org. Create a new organization', 'reset_org_bandwidth: ... Reset all sites in selected organization bandwidth counters'). The domain framing cleanly separates it from siblings like pangolin_users, pangolin_sites, and pangolin_roles without needing to name them.

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 preconditions: 'Self-hosted Pangolin CE only', 'Writes need confirm:true and PANGOLIN_ALLOW_WRITES=true', and 'Omit confirm for a dry-run preview'. It also flags which actions require server-admin scope ('delete_admin_org', 'list_admin_orgs'). It stops short of stating when to prefer this toolset over a sibling (e.g. org-scoped user ops vs pangolin_users), which keeps it from a 5.

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

Deploy Server