MCP servers

Admin → MCP servers is the escape hatch for data that is not a relational database. If something speaks the Model Context Protocol, you can attach it.

Confluence

Notion

GitHub

Slack

Jira

Google Drive

Linear

Salesforce

Two ways to register

As a data source — the server holds data, and the connector’s tools get introspected so the tables and operations become Registry entities and metrics. This is how you bring in a service that models its data as tools rather than as SQL.

As a server — the server is registered as a capability that custom agents can use in open mode.

Both paths end at the same configuration: a transport, a URL, and credentials.

Transports

Transport	Typical URL	Use when
HTTP / SSE	`https://service.example.com/mcp`	The common case — a hosted MCP server
Local process	a command to run	The server runs alongside SEMANTIX

A local process is executed in the backend container, so the command and anything it needs must exist there.

Credentials

None — an open server.
API key — sent as a header.
Bearer token — sent as an Authorization header.
Basic auth — username and password.

Credentials are stored encrypted and only ever displayed masked. Same treatment as provider keys.

Visibility

all exposes the server to analysts; admins keeps it and its tools to admins. Worth setting for a server with broad access — remember that whatever permission its credentials carry is the permission the agent has.

When to reach for this

The templates in Connectors are the better path for anything with a SQL interface: they are read-only by construction, which an arbitrary MCP server is not. Use MCP for what genuinely is not a database.

After registering

Tools are discovered at connect time. If a server’s tools change, re-register or re-sync it so the tool list reflects the current server, and re-check which of its tools should be visible to analysts.