Skip to lesson

Google CloudProfessional Agentic Architect2026-093.2 Integrating enterprise domain knowledge

Expose enterprise systems through governed MCP boundaries

Completed by the knowledge check

Learning objective

Expose enterprise systems to agents through governed registries and Model Context Protocol (MCP) integration boundaries. Choose an appropriate boundary without giving the model unrestricted backend access.

Core idea

Treat the registry as the catalog and the MCP server as the capability boundary.

The registry records what approved capabilities exist, where they run, and how consumers discover them. The MCP server translates a model-facing tool call into a constrained backend operation. Neither layer replaces the destination’s authentication, authorization, validation, or business rules.

Keep the control path separate from the invocation path:

  • Discovery: boundary owner -> registry -> agent
  • Invocation: agent -> MCP client -> MCP server -> backend system

The registry is not in the runtime data path. Every runtime boundary still checks the relevant identity and policy.

How it works

Choose the integration boundary

Match the boundary to the system you need to expose:

TargetPreferred boundary
Supported Google or Google Cloud serviceUse its Google-managed remote MCP server.
Database without a suitable managed serverUse MCP Toolbox for Databases or a purpose-built server with narrow queries and commands.
Existing managed APIPublish the API as an MCP server through Apigee when that path fits the API estate.
SaaS or custom remote serviceUse a trusted remote MCP server that maps tools to the service’s API.
API that doesn’t need model-oriented toolsRegister it as an endpoint and use an application-controlled integration.

Google Cloud publishes a changing list of supported remote MCP servers, including database and infrastructure services. Prefer a managed server when its exposed operations and regional behavior fit. This reduces operational work, but it does not remove the need for safe tools and least-privilege access.

For other databases, MCP Toolbox for Databases can provide connection management, authentication integration, and custom tools. Prefer a task-specific tool such as get_order_status over a general execute_sql tool.

Define the exposed capability

An MCP server can expose tools, resources, and prompts. A client discovers schema-defined tools with tools/list and invokes one with tools/call. See the MCP tools specification.

Design each production tool as a small application API:

  • Give it one clear business purpose.
  • Validate identifiers, ranges, tenant context, and allowed state transitions.
  • Return only the fields the agent needs.
  • Separate reads from writes, and require deterministic policy or human approval for destructive actions.
  • Limit retries, timeouts, result size, and fan-out.

MCP standardizes discovery and invocation; it does not make a broad database credential or arbitrary API proxy safe. Tool annotations are descriptive hints. A trusted control can use them as inputs to enforcement.

Register, discover, and invoke

Agent Registry catalogs MCP servers, tools, agents, skills, and endpoints. Supported Google Cloud MCP servers enter it automatically when you enable the corresponding API. Supported Cloud Run and Google Kubernetes Engine deployments can also register automatically. Register external servers manually and supply their tool specifications; registration does not automatically inspect a private server. See Register MCP servers.

Use registry metadata for ownership, lifecycle state, environment, endpoint, and capability discovery. Keep registry write access away from consuming agents. A manipulated entry can redirect traffic or influence tool selection.

At runtime, discovery produces a candidate server. The MCP client connects to it, obtains a credential, lists the permitted tools, and calls one. Google Cloud remote MCP servers require the MCP tool call permission and service-specific resource permissions. They support user, workload, and Agent identities; see Set up authentication for MCP servers.

Key distinctions and trade-offs

Registry discovery versus MCP discovery: Agent Registry searches across approved servers and endpoints. MCP tools/list asks one connected server what tools it exposes to that caller. Neither operation authorizes a later business action.

Managed versus custom server: A managed server reduces hosting, patching, and scaling work. A custom server improves control over domain semantics and compatibility, but your team owns its security and reliability.

Direct API endpoint versus MCP server: Registering an endpoint inventories a URL. An MCP server adds a model-oriented contract for discovering and calling tools. Do not build an MCP wrapper when a deterministic application workflow can safely call the API directly.

Broad versus narrow toolsets: A broad server is reusable, but it consumes more model context and increases the blast radius of incorrect tool selection. Google Cloud MCP toolsets group selected tools behind separate endpoints so you can expose only the relevant group. Narrow tools cost more to design, but they are easier to validate, authorize, test, and audit.

Architecture / decision scenario

A support agent needs to read order data from Cloud SQL, check shipment status in a carrier SaaS system, and issue refunds through an internal payments API.

The architect selects a managed Cloud SQL MCP server for approved read operations. The carrier has no approved MCP server, so the integration team hosts a remote server on Cloud Run that maps get_shipment_status to the carrier API and removes unrelated fields. A custom payments server validates order ownership and requests approval before issue_refund commits.

The platform team registers both custom servers and their tool specifications in Agent Registry. The agent can search the registry, but it cannot edit the records. Its identity receives read-only database permission and permission to call the carrier tool. A delegated user credential and approval path governs refunds. Logs correlate the agent, user, tool, target, and result.

This design uses one discovery model without flattening three different trust domains into one credential or one unrestricted proxy.

Common exam traps

  • Treating registration as deployment, network connectivity, or permission to invoke a tool.
  • Assuming MCP replaces IAM, OAuth scopes, destination authorization, or business validation.
  • Giving an agent arbitrary SQL or a generic HTTP tool when a narrow business operation meets the requirement.
  • Using Agent Registry search and MCP tools/list as though they were the same discovery step.
  • Choosing a custom server without accounting for hosting, patching, observability, schema evolution, and credential handling.
  • Trusting tool descriptions or read-only annotations from an unreviewed remote server as enforcement.

What to remember

  • Use the registry as a governed catalog and the MCP server as the execution boundary.
  • Prefer managed MCP servers when they fit; build narrow custom boundaries for unsupported databases, APIs, SaaS systems, and remote services.
  • Expose business operations, not unrestricted backend interfaces.
  • Separate registry discovery, MCP tool discovery, authentication, and operation authorization.
  • Grant least privilege and require deterministic controls for consequential actions.

Knowledge check

References