Server Management

Register a Server

Registering a server is an Editor action. There are two ways, both packageless — you always end up with a governed proxy URL.

Navigate to Integrations → MCP (/integration/mcp) and click Add server → From the catalog. Palveron mirrors the official MCP registry, so you can search it and connect a server in one click. Each catalog entry carries trust signals: when the registry record was last updated and published, and a link to the server's source repository. Behind the scenes this reads GET /api/v1/mcp/registry.

Custom address

On the same screen choose Custom and provide:

Name — Human-readable identifier (e.g. "GitHub MCP")
Server URL — The MCP server's Streamable-HTTP endpoint
Connector type — Optional free-form label (defaults to custom); descriptive only, not a fixed list
Description — Optional context for your team

New servers start in the PENDING_APPROVAL state.

Via the API

curl -X POST https://gateway.palveron.com/api/v1/mcp/servers \
  -H "Authorization: Bearer {api_key}" \
  -d '{
    "name": "GitHub MCP Server",
    "server_url": "https://api.githubcopilot.com/mcp/",
    "connector_type": "custom"
  }'

The response contains the server id; the governed endpoint agents connect to is POST /api/v1/mcp/proxy/{id}.

Lifecycle & role split

MCP servers move through an explicit, audited lifecycle with a clear separation of duties:

Transition	Who	Route
Register + scan	Editor	`POST /servers`, `POST /servers/{id}/scan`
Approve (`PENDING_APPROVAL` → `ACTIVE`; needs a successful scan and admits every tool with its rule) / Resume (`BLOCKED` → `ACTIVE`; admits nothing)	Admin	`POST /servers/{id}/activate`
Admit tools on an active server (not admitted or changed)	Admin	`POST /servers/{id}/tools/release`
Pause (`ACTIVE` → `BLOCKED`)	Admin	`POST /servers/{id}/pause`
Reject (`PENDING_APPROVAL` → removed)	Admin	`POST /servers/{id}/reject`

Every transition is recorded in the tamper-evident admin-audit trail. Only an ACTIVE server is proxied (deny-until-active): a call to any other status is refused at the proxy — a PENDING_APPROVAL server returns JSON-RPC -32002.

Tool Discovery Scan

After registration, scan the server to discover its tools:

POST /api/v1/mcp/servers/{id}/scan

The scan connects to the MCP server, calls tools/list, and for each tool:

Registers the tool with name, description, and input schema
Automatically classifies risk based on tool name and description:

Risk Level	Triggers (tool name or description)
CRITICAL	`exec`, `shell`, `command`, `eval`, "execute arbitrary", "run command"
HIGH	`write`, `delete`, `remove`, `drop`, `modify`, `update`, `insert`
LOW	`read`, `get`, `list`, `search`, `query`, "read-only"
MEDIUM	Default for anything unrecognized

Records the current state of each tool. The scan sets no rule and admits nothing: each tool waits for an Admin's decision, starting from a proposed rule (see Tool Policies). The scan never changes the server's status.

If the target is unreachable, the scan returns an honest 200 { "scanned": false, "reason": … } (not a 502) and the server list shows scan_state: failed. A configuration the scan cannot run with (private or internal address, unsupported sign-in method, missing token) is rejected with 400 and recorded as scan_state: not_run with its reason.

Changes vs. legacy poisoning

For admitted tools, the reference is the admitted fingerprint (name + description + input schema): a later change shows as "changed since the admission" and blocks the call until an Admin admits the tool again. Tools that are not admitted are blocked anyway; for them the legacy per-scan description hash (is_poisoning_suspect) is shown as an extra signal.

Server Status

Status	Meaning
`PENDING_APPROVAL`	Newly registered — not yet activated; the proxy refuses calls (`-32002`)
`ACTIVE`	Operational — tool calls are proxied
`BLOCKED`	Paused by an Admin, or blocked by a targeted stop; all tool calls rejected (shown as "Paused" in the UI)

Any status other than ACTIVE is refused at the proxy. Only people set the status. What the last scan saw stands next to it (scan_state: never scanned · failed · could not run · outdated, scan again · succeeded, with scan_reason) and never changes it.

Monitoring

The Command Center displays MCP KPIs in near real time: tool calls and block rate, active vs. total servers, servers whose last scan failed, and pending approval requests. MCP tool calls appear in the Live Activity Feed with the type MCP_TOOL_CALL.

On this page