MCP Servers
Plug in a Model Context Protocol server and the gateway exposes its tools and skills to every chat completion against a model you've attached it to.
What an MCP server gives you
A Model Context Protocol (MCP) server is a small service your team runs that publishes reusable capabilities — callable tools, prepared reference material, named actions — over a standard protocol. Many modern LLM hosts know how to consume one natively, and so does the gateway.
Connect one to your organisation and every chat completion against a model you've attached the server to picks up its capabilities automatically. Your callers don't change anything on their side — the gateway handles the protocol, runs the tool calls, and weaves the results back into the conversation.
Tools vs. skills
An MCP server can publish two kinds of capability. The right shape depends on whether the model should decide when to use it, or whether it should always be available as background context.
Functions the model can invoke on its own when the conversation calls for them — "look this up", "calculate that", "send the report". The gateway routes the call to the server, waits for the result, and feeds it back into the same response.
Curated reference material — a glossary, house style, framing principles — that the gateway loads into the conversation up front, so the model knows it without having to fetch it.
Enabling a server
MCP servers are curated by Servada and made available to your organisation when they're ready. From the MCP Servers page inside your organisation:
- Click Enable on the server you want to attach.
- Supply credentials if the server requires them — Servada will tell you which mode applies (none, bearer token, OAuth). Your credentials are encrypted at rest and only used from inside the gateway.
- Hit Test connection to confirm the gateway can reach the server and see its capabilities.
To have a model actually use the server, open the model's settings under Modelsand add it to the model's MCP server list. From that point, every chat completion against that model has access.
Auth modes
A few servers are public; most expect a credential. The mode is fixed by whoever publishes the server — you supply the value:
Public server. Nothing to configure.
Paste a long-lived token. The gateway sends it on every request to the server. Rotate by entering a new value on the server's detail page; the previous one is overwritten.
Click Connecton the server's detail page. The gateway runs the standard authorization flow with the upstream, stores the refresh token encrypted, and keeps the connection live as it rotates access tokens behind the scenes. Re-authorise from the same page any time.
Attaching to specific models
Enabling a server makes it availableto your organisation — it doesn't automatically light up on every chat completion. Attach it per-model under Models, the same way you attach catalogue tools. That lets you keep one model lean (a cheap routing model, say) while another picks up the full server.
Safety + limits
- All outbound calls to MCP servers route through the gateway's SSRF guard. Private, loopback, and cloud-metadata addresses are refused.
- Credentials are encrypted at rest and never returned in API responses. Rotate them by entering a new value; the previous one is overwritten.
- Tool-call chains follow the same per-model step cap as catalogue tools — a misbehaving server can't spin the model in an infinite loop.
- Skills are size-capped per request so a chatty server can't push enormous context into your prompts unexpectedly.
- If the server is unreachable or returns an error, the gateway drops its capabilities for that request and the completion still runs — your callers don't see a failure because one server is having a bad day.