Pangolin MCP Connector

Overview Schema Source Related Servers Discussions Admin

pangolin_users

DestructiveIdempotent

Manage Pangolin organization users and invitations by creating, listing, retrieving, updating 2FA or server-admin status, and deleting users or open invitations.

Instructions

pangolin_users covers the users toolset (12 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: create_org_user: PUT /org/{orgId}/user. Create an organization user. delete_org_invitations: DELETE /org/{orgId}/invitations/{inviteId}. Remove an open invitation from an organization delete_org_user: DELETE /org/{orgId}/user/{userId}. Remove a user from an organization. get_org_user: GET /org/{orgId}/user/{userId}. Get a user in an organization. get_org_user_by_username: GET /org/{orgId}/user-by-username. Get a user in an organization by username. When idpId is not passed, only internal users are searched (username is globally unique for them). For external (OIDC) users, pass idpId to search by username within that identity provider. get_user: GET /user/{userId}. Get a user by ID. list_org_invitations: GET /org/{orgId}/invitations. List invitations in an organization. list_org_users: GET /org/{orgId}/users. List users in an organization. list_users: GET /users. List non–server-admin users (server admin). update_org_create_invite: POST /org/{orgId}/create-invite. Invite a user to join an organization. update_user_2fa: POST /user/{userId}/2fa. Update a user's 2FA status. update_user_server_admin: POST /user/{userId}/server-admin. Promote or demote a user's server admin status (server admin).

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

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

Behavior4/5

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

Annotations already declare destructive/open-world/non-read-only, and the description adds real context beyond them: the auth header requirement, the CE-edition restriction, the confirm-plus-env-var write gate, and the omit-confirm dry-run mode. That dry-run behavior is exactly the kind of operational trait annotations cannot convey. Remaining gap: it never states the blast radius of delete_org_user/delete_org_invitations (cascading effects, whether the user is detached vs removed), and the global idempotentHint=true sits awkwardly beside create_org_user/update_org_create_invite, though the description itself does not assert idempotency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The front-loading is good: constraints and the write gate come before the action catalogue. But the catalogue is a dense run-on with several missing separators between an action's prose and the next action name ("...open invitation from an organization delete_org_user:"), which forces re-parsing. For a 12-action dispatcher some enumeration is unavoidable, but the formatting defects cost readability.

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?

For a multi-action tool with five generic container parameters and no output schema, the description covers what an agent actually needs: auth, edition limits, the write/confirm protocol, dry-run mode, and a per-action endpoint with meaning. The only omission is return-value shape, which is less critical here since every action maps to a documented REST endpoint.

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 schema already documents action, params, query, body and confirm; the baseline would be 3. The description earns a fourth point by adding semantics the schema cannot: the idpId lookup rule for get_org_user_by_username (internal vs external username scoping) and the pairing of each action with its path parameters. The generic body/query/params containers still get no per-action shape guidance.

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 toolset and enumerates all 12 actions with HTTP verb + path + a one-line human meaning (e.g., "list_org_users: GET /org/{orgId}/users. List users in an organization."). It is unambiguously about user/invitation/2FA administration, which separates it from the org, site, resource, role and target siblings.

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 operating conditions: self-hosted Pangolin CE only, Authorization Bearer header, writes require confirm:true plus PANGOLIN_ALLOW_WRITES=true, and omitting confirm yields a dry-run preview. It also explains when to use idpId (external OIDC users) versus omitting it (internal users only). It stops short of explicitly saying when to prefer this tool over a sibling such as pangolin_orgs, but the action naming makes the boundary inferable.

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

Deploy Server