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`
Activate (`PENDING_APPROVAL` → `ACTIVE`) / Resume (`BLOCKED` → `ACTIVE`)	Admin	`POST /servers/{id}/activate`
Pause (`ACTIVE` → `BLOCKED`)	Admin	`POST /servers/{id}/pause`
Reject (`PENDING_APPROVAL` → removed)	Admin	`POST /servers/{id}/reject`

Every transition is recorded in the immutable 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

Seeds a starting verdict per tool from that risk level (LOW → ALLOW, MEDIUM → LOG_ONLY, HIGH/CRITICAL → REQUIRE_APPROVAL; no DENY is auto-seeded). Auto-seeded policies are marked is_auto_generated: true; any policy you set yourself takes precedence. The scan does not activate the server.

If the target is unreachable, the scan returns an honest 200 { "scanned": false, "reason": … } (not a 502); a forbidden (private/internal) URL is rejected with 400.

Drift vs. legacy poisoning

For tools that were part of an Admin approval, the reference is the approved fingerprint (name + description + input schema): a later change is reported as drift ("differs from the approved state") and blocks the call until re-approval. Tools that were never approved fall back to the legacy per-scan description hash (is_poisoning_suspect).

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 emergency-stopped — all tool calls rejected (shown as "Paused" in the UI)
`ERROR`	The last scan could not reach the server or failed

Any status other than ACTIVE is refused at the proxy.

Monitoring

The Command Center displays MCP KPIs in near real time — tool calls and block rate, active vs. total servers, and pending approvals. MCP tool calls appear in the Live Activity Feed as the MCP_TOOL_CALL trace type.

On this page