MCP Deployment

Server Configuration

Every field on the Details tab, the rules around each, and the downstream consequences of changing it. Read this before you reconfigure a server that already has live traffic.

The Details tab

The Details tab is where the server's identity and runtime configuration live. It is the first tab you land on when you open a server. Its fields (name, description, visibility, tool pivot) take effect live on every request. The four content tabs (Contents, Categories, Groups, Relations) feed into version snapshots; the Versions tab is where you cut and activate those snapshots.

Name and description

The name surfaces in three places: the dashboard listing, the MCP "server name" string sent to AI clients on connection, and — for public servers — the public directory entry. The description is exposed to clients as the server "instructions" string and is what most AI clients show users when picking which server to call.

Slug and endpoint URL

The slug is auto-generated from the name and must be unique within your organisation. It is, however, cosmetic — the public endpoint URL is keyed on an internal immutable identifier (the server UID), not the slug. The endpoint shape is always: 

POST https://vectoralix.com/mcp/<serverUid>

You can rename a server or change its slug at any time without breaking existing clients. The UID never changes.

Visibility

A two-state toggle — public or private. Public servers accept any caller; private servers reject every request that does not present a valid endpoint token in an Authorization header. Switching visibility takes effect on the next request, so be cautious about flipping a public server to private without warning its clients.

See Public vs Private Servers for the full decision matrix and migration story.

Enabled tools

Tools are attached to a server through a many-to-many pivot. You can enable any combination of File Search, Code Execute, and API URL tools your organisation has authored. Each tool can be wired to multiple servers — there is no copy.

Tools are live, not versioned: The server-to-tool pivot is read on every incoming request. Toggling a tool on or off, or changing the tool's configuration, takes effect immediately on every server it is attached to. This is intentional — it means a buggy tool can be disabled without cutting a new version. It also means tool changes are not captured in version history; if you need that audit trail, treat tool edits as deliberate releases on their own.

Saving a draft vs cutting a version

Saving the Details tab does not publish anything to the served endpoint. The endpoint only exposes content and tool configurations from the active version snapshot — see Versioning & Releases for how to cut and activate one. Server-level fields (name, description, visibility, tool pivot) are exceptions: they are read live and take effect on save.

Permissions

  • Viewing a server requires the mcp_servers.can_view entitlement on your organisation role.
  • Editing the Details tab requires mcp_servers.can_edit.
  • Deleting requires mcp_servers.can_delete.

Entitlements are bundled into the named roles your organisation owner assigns to members. The exact mapping is configurable per organisation; see Members & Roles when that group is online.

Deleting a server

Deleting a server is a soft delete. The endpoint URL begins returning 404 immediately. Internal records (versions, content, tools pivot) remain in the database for a recovery window so support can restore on request. Once the soft-delete window passes, recovery is no longer possible.

A minimal example call

Once Details is saved and a version is active, this is the shape of a request a public server will accept: 

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

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

A private server requires the same body plus an Authorization: Bearer <endpoint-token> header. The slug never appears in the URL — only the immutable UID does.