Offloading MCP Tool Access to Agent Registry

It’s been a couple of weeks since Google Cloud Next concluded, and I am still playing catching up labbing things out and exploring!

One of the largest changes, of course, has been the rebranding of Vertex AI to Gemini Enterprise Agent Platform. Once you dig into the features that came along for the ride, you begin to see that this wasn’t just an aggressive marketing move to show Google is serious about agents — some genuinely good changes were introduced. I want to talk about some of the changes to the MCP Server Registry through the unveiling of Agent Registry.

What is an MCP Server Registry?

An MCP (model context protocol) server registry is a catalog of MCP servers, providing both an abstraction layer between each MCP endpoint and a usage card indicating the tools available to the agent for each server. This promotes tool / server discoverability analogous to how a conventional API gateway surfaces available endpoints to a developer or client.

From a governance and controls perspective, you could then add egress rules to your agents to prevent MCP tool calls outside of what you’ve specified in the gateway, allowing your AI governance and AppSec teams to vet tools prior to them being made available to development teams.

Didn’t Google Already Have an MCP Server Registry?

Kinda. The previous iteration was somewhat limited in that all MCP services exposed had to be a part of the Cloud API Registry, restricting you to only see 1P services provided by Google or services you’ve developed or exposed through Apigee.

What’s more, your agents still had to negotiate complicated OAuth flows (machine-machine and user delegated permissions) to prove to the tool that the agent or the user has access to the MCP server’s resources. This means that your developers (hopefully) had to set up secure secret management in their agent and then go deal with these auth flows through custom code.

Introducing MCP Servers on Agent Registry

As mentioned earlier in the article, Google launched Agent Registry during Next. Agent Registry allows you to see in a single pane of glass all of the agents that have been deployed to Gemini Enterprise Agent Platform, regardless of where they were deployed or what framework was used to develop it.

A sub-component of Agent Registry is the MCP Server catalog, which can be used now to register any MCP Server containing tools. And the best part: there’s no longer the prerequisite of having to find a way to get the MCP Server declared in Google Cloud API Registry!

Let’s take the following MCP server as an example:

Example MCP server registered in Agent Registry

The MCP server entry provides an ADK code snippet for free to showcase how the MCP server can be accessed using the new AgentRegistry object.

import os
from google.adk.integrations.agent_registry import AgentRegistry
from google.auth import default
from google.adk.agents import Agent
from google.adk.models import Gemini
from google.genai import types

_, project_id = default()
LOCATION = os.environ.setdefault("GOOGLE_CLOUD_LOCATION", "us-central1")
MCP_SERVER_NAME = os.environ.get("MCP_SERVER_NAME", "agentregistry-00000000-0000-0000-fd1e-a93aec9d9168")
os.environ["GOOGLE_GENAI_USE_VERTEXAI"] = "True"
registry = AgentRegistry(project_id=project_id, location=LOCATION)

mcp_toolset = registry.get_mcp_toolset(
    f"projects/eseabrook-agent-identity/locations/us-central1/mcpServers/agentregistry-00000000-0000-0000-fd1e-a93aec9d9168"
)

root_agent = Agent(
        name="sample",
        description=(
            "You are a helpful AI Assistant who can answer questions."
        ),
        model=Gemini(
            model="gemini-flash-latest",
            retry_options=types.HttpRetryOptions(attempts=3),
        ),
        tools=[mcp_toolset],
)

The snippet showcases how the agent doesn’t have to deal with the MCP server endpoint directly — the registry is able to broker that access and abstract away the endpoint.

The Agent Registry entry also provides a list of tools exposed by the MCP Server based on the MCP tool schema provided on registration.

Tool details snapshot

Creating an MCP tool entry must be done through the console, at least until the REST API and / or gcloud alpha agent-registry command group catches up. The tool specification must follow the tool object schema, as defined by the Model Context Protocol.

The MCP server hosted on Cloud Run that my tool references is a “hello world” app on steroids — it takes in an authorization header token and validates it against my auth provider (Auth0). If the request is successful, it provides a static string acting as “the latest secure data”.

import os
import logging
import asyncio
from fastmcp import FastMCP
from fastmcp.server.auth.providers.jwt import JWTVerifier

logging.basicConfig(level=logging.INFO)
logger = logging.getLogger(__name__)

verifier = JWTVerifier(
    jwks_uri=os.environ.get("MCP_SERVER_AUTH0_CONFIG_URL"),
    issuer=os.environ.get("MCP_SERVER_AUTH0_ISSUER"),
    audience=os.environ.get("MCP_SERVER_URL")
)

# 1. Define the FastMCP Server
mcp = FastMCP("Auth0SecuredServer", auth=verifier)

@mcp.tool()
def get_secure_data(query: str) -> str:
    """A tool that returns highly secure data, protected by Auth0."""
    logger.info(f"Accessing secure data for query: {query}")
    return f"SECURE_DATA: You successfully accessed the secured MCP tool with query '{query}'!"

if __name__ == "__main__":
    logger.info(f"🚀 MCP server started on port {os.getenv('PORT', 8080)}")
    # Could also use 'sse' transport, host="0.0.0.0" required for Cloud Run.
    asyncio.run(
        mcp.run_async(
            transport="streamable-http",
            host="0.0.0.0",
            port=os.getenv("PORT", 8080),
        )
    )

Given the MCP Tool Authenticates an Auth0 Token, the Agent Must Have to Initiate a Client Credential OAuth2.0 Flow, Right?

Nope! As part of the sweeping changes brought in with Gemini Enterprise Agent Platform, some big changes came to agent identity — namely authentication models.

Agent Identity allows for the secure storage of user delegated and client credential OAuth flow credentials via Connectors. By defining and referencing a Connector in your agent, Agent Identity is able to broker the OAuth2.0 flow and transparently attach the bearer token to the header of associated tool call requests.

Below is a step-by-step diagram showing how Agent Identity and Agent Registry work together to surface MCP tools and handle auth to them:

Diagram showcasing how external auth providers are handled via Agent Identity

1. The agent establishes a link to Agent Identity Connector.
2. The Agent Identity Connector negotiates OAuth2.0 flow, automatically fetching (and refreshing) the bearer token as needed.
3. Agent Registry is configured to associate the agent’s toolset with the Connector, signalling that the toolset needs the bearer token included in requests to its tools.
4. The agent’s MCP tools are invoked via registry with bearer token transparently attached.
5. The agent registry forwards traffic to my Cloud Run service.
6. The Cloud Run service validates the token against the auth provider.

Let’s take a look at the agent code:

from google.adk.agents import Agent
from google.adk.auth.credential_manager import CredentialManager
from google.adk.integrations.agent_identity import GcpAuthProvider
from google.adk.integrations.agent_identity import GcpAuthProviderScheme
from google.adk.integrations.agent_registry import AgentRegistry
import os

# The name of the tool as registered in the Vertex AI Agent Registry
mcp_server_name = os.environ.get("TOOL_NAME")
connector_name = os.environ.get("CONNECTOR_NAME")
project_id = os.environ.get("GOOGLE_CLOUD_PROJECT")
location = os.environ.get("GOOGLE_CLOUD_LOCATION")

# This is necessary to access the agent identity data connector
CredentialManager.register_auth_provider(GcpAuthProvider())

auth_scheme = GcpAuthProviderScheme(
    name=f"projects/{project_id}/locations/{location}/connectors/{connector_name}"
)

registry = AgentRegistry(
    project_id=project_id,
    location=location,
)
# 1. Initialize the toolset simply by referencing the registered tool name.
# The Agent Engine dynamically resolves the URL, looks up the Auth Provider, 
# fetches the Auth0 token, and injects the Authorization headers transparently.
mcp_toolset = registry.get_mcp_toolset(mcp_server_name=mcp_server_name, auth_scheme=auth_scheme)

# 2. Initialize the agent with the toolset
root_agent = Agent(
    name="root_agent",
    model="gemini-2.5-pro",
    instruction="""You are a helpful assistant with access to a highly secure MCP tool.
    Whenever a user asks for secure data, use your registered tool to fetch it for them.""",
    tools=[mcp_toolset]
)

By incorporating the Agent Identity auth provider, we bypass all of the finicky boilerplate code that’s usually necessary to fetch a bearer token and shoehorn it into the resource / MCP server request. The benefit from an AppSec perspective is that we are now able to shift authentication and authorization left entirely — brokering tokens with external auth providers is now a platform concern. Access to connectors can be granted explicitly to agent identity principal sets or service accounts, allowing the platform to dictate which agents can utilize the credentials.

You can see exactly how to create a client-credential flow connector via Google’s Agent Identity documentation.

Final Thoughts

Google’s new Agent Registry is a big step in the right direction for the platform. By now, it’s no secret that governance of agentic systems is a big question mark for many enterprise customers. Being able to catalog and restrict external tool access goes a long way to helping enterprise customers feel comfortable with moving agents to production.

I hope this was an interesting read! I know I had fun checking all of this out. For those interested in seeing the full solution, please feel free to check out my repository (much of which was authored using Google’s Antigravity).