Public vs Private Servers

The two modes side by side

Aspect	Public	Private
Authentication	None — any caller can hit the endpoint.	Per-server endpoint token, sent as Authorization: Bearer <token>.
Discoverability	Endpoint URL is shareable; anyone with the URL can connect. There is no central public listing today.	Endpoint URL alone is not enough — only token holders can reach it.
Plan restrictions	Subject to your plan's overall server count.	Tighter cap on cheap plans (typically one private server).
Per-request identity	Same request log as private — organisation, server, version, tool, IP, response status, duration — but with no token identity attached.	Same fields as public, plus the token match outcome captured in the request log.
Rate limits	Plan-based monthly quota.	Same quota model — see Rate Limits.

Public servers in detail

A public server accepts unauthenticated traffic. It is appropriate for reference documentation, marketing content, and anything you would otherwise put on a public website. The endpoint URL is the only thing a client needs to know — there is no token, no header, no setup beyond the URL.

Even though there is no auth, public traffic is still rate-limited per server and tracked for metrics. Anonymous callers are identified by IP address in request logs.

Private servers in detail

A private server requires an endpoint token on every request. When you create a private server, Vectoralix generates a 64-character random token and stores it on the server record. You copy that token from the Details tab and configure your MCP client to send it as an Authorization: Bearer <token> header.

The middleware compares the supplied token against the stored token in constant time, so timing attacks cannot leak the value byte-by-byte. The token field is hidden from API responses to keep it out of accidental log capture.

On a private server, "wrong token", "missing token", and "server does not exist" all return the same 401 — Vectoralix deliberately does not distinguish them, to avoid leaking which UIDs exist via a 404-vs-401 oracle.

Plan restrictions

Subscription tier governs both how many public and how many private servers your organisation may run. Cheap plans typically cap private servers at one — see the Pricing page for the per-plan numbers, since plan caps are part of the billing surface and live there rather than here.

Switching visibility on an existing server

Visibility is a save away — open Details, flip the toggle, save. The change takes effect on the next request, with two consequences worth thinking through before you click:

• Public to private — every existing client without the endpoint token starts getting 401s the instant you save. Distribute the token before flipping, not after.
• Private to public — clients that were sending Authorization headers can keep doing so harmlessly. The header is just ignored on a public server.

When to choose which

• Public — reference documentation, marketing content, open product handbooks, anything you would otherwise put on a public website.
• Private — internal knowledge bases, customer-specific material, anything covered by an NDA, anything you would not want surfacing in an unauthenticated request log.

Revocation

There are two ways to invalidate access to a private server:

• Rotate the endpoint token — replace the stored token. Every existing client breaks until reconfigured with the new value.
• Flip the server back to private from public, or take it down entirely — for a clean break with no token migration.

A private call

POST https://vectoralix.com/mcp/<serverUid>
Authorization: Bearer <endpoint-token>
Content-Type: application/json

{ "jsonrpc": "2.0", "id": 1, "method": "tools/list" }