Skip to content

Chapter 7 — MCP & RAG

Security & Persistence

Layered access control around MCP capabilities, and how the Registry persists, caches and refreshes server and tool metadata.

Security and authorisation

  • Access to the MCP management interface is restricted to authenticated users — only users logged into the platform can view and manage servers and tools.
  • Communication between the application and the Registry is protected with Bearer token authentication; requests must include the configured API token in the Authorization header.
  • Credentials required by individual MCP servers are managed centrally by the Registry. They are never exposed to the frontend or passed through the Agent; server authentication tokens are stored encrypted and applied by the Registry when it calls the corresponding server.
  • Access is further restricted by configuration: a project can reach only the servers assigned to it, and an Agent receives only the tools configured on its node.
Authenticated user → project MCP servers → Agent tool set → MCP Registry → MCP server

This limits MCP functionality to the relevant users, projects and Agent configurations while keeping server credentials and direct MCP communication centralised.

Availability, persistence and cache

  • Persistence — the Registry stores MCP server and tool metadata in PostgreSQL, providing a stable source of configuration and server information across application restarts.
  • Cache — frequently accessed metadata is cached in Redis, including server lists, project-specific server information, tools and prompts.
  • Invalidation — the cache is refreshed or invalidated automatically when server configuration changes: creation, update, deletion or manual reload.
  • Background checks — the Registry periodically checks registered servers, updating each server's availability status and refreshing its tool and prompt metadata.

Together these keep MCP metadata up to date while reducing repeated discovery requests during normal application usage.