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/ ``` 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/ 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.