Skip to content

MCP Server Registry#

Register upstream MCP servers to extend agent capabilities beyond Lens Agents' native integrations. The registry discovers the server's tools and governs them through the same policy engine.

For what MCP is and how Lens Agents acts as its own MCP server, see Core Concepts → MCP.

When to register an MCP server#

Lens Agents includes native integrations for Kubernetes, AWS, and GitHub. Use the MCP registry for any other system that exposes an MCP-compatible server:

  • A database query server for your data warehouse
  • A deployment server that wraps your CI/CD pipelines
  • A custom internal server in front of your proprietary APIs
  • Third-party MCP servers from the ecosystem (search, documentation, analytics)

Registration#

Administrators register an upstream MCP server by providing its endpoint URL and authentication method. Lens Agents connects to the server, discovers its tools, and makes them available to agents in the team. No agent restart is required — tools appear as soon as registration completes.

Removing a registered server immediately revokes agent access to its tools. In-flight calls complete; no new calls are routed to the server.

Authentication#

The registry supports three methods for authenticating to the upstream server:

Method When to use
Bearer token Static token in the Authorization header — most SaaS MCP servers
API key Key injected as a custom header (e.g., X-API-Key)
No authentication Servers on trusted internal networks

Credentials are stored encrypted on the platform and injected at connection time. Agents never see the upstream server's authentication.

Governance#

Registered MCP tools are governed identically to native tools:

  • Access control — policies determine which teams and agents can use which tools
  • Audit — every call is recorded in the audit trail with tool name, parameters, and result
  • Spending — if a registered tool triggers LLM calls via the platform, those count toward spending limits

There is no governance distinction between a native Kubernetes tool call and a call to a registered MCP server's tool.

Native integrations vs. the registry#

Native integrations MCP registry
What Pre-built, specialized credential handling, optimized tool schemas Any MCP-compatible server
Examples Kubernetes, AWS, GitHub Custom servers, third-party tools, internal APIs
Strength Deeper features (cluster discovery, IAM role assumption, CloudTrail attribution) Breadth — anything that speaks MCP

Use native integrations when you want the deepest support for a major platform. Use the registry for everything else.