Skip to lesson

Google CloudProfessional Agentic Architect2026-092.1 Using coding agents effectively

Attach MCP servers with a minimal tool surface

Completed by the knowledge check

Learning objective

Attach a Model Context Protocol (MCP) server to a coding agent and expose only the tools that the agent needs. This lesson focuses on connection and tool selection, not on designing the server, sandboxing generated code, or building a complete identity policy.

Core idea

Treat an MCP connection as a capability budget. Connecting a server can make its live data and actions available to the coding agent. Start with the smallest useful surface:

task -> required operations -> narrow toolset -> visible tools -> permitted calls

Select a task-specific server or toolset, withhold irrelevant tools, and apply invocation permissions as a separate control.

How it works

An MCP host is the coding application. It manages one or more MCP clients, which connect to MCP servers. A local server usually runs as a process and uses standard input and output (stdio). A remote server runs elsewhere and exposes an HTTP endpoint. Google Cloud documents this distinction in its MCP servers overview.

After connection, an MCP client can discover a server’s tools. Each tool has a name, description, and input schema. The MCP specification defines tools/list for discovery and tools/call for invocation. The coding-agent host decides which discovered tools to place within the model’s reach and what approval or permission checks apply to a call.

Use these layers deliberately:

LayerDecisionWhat it does not prove
ConnectionWhich local process or remote endpoint is attachedThat every advertised tool is needed
ExposureWhich discovered tools the model can selectThat a selected call is approved
PermissionWhich calls run, prompt, or are deniedThat the backend authorizes the operation
Backend authorizationWhich resources and actions the identity can accessThat the model chose the right action

Attach the narrowest endpoint

Start with the task, then list the operations it requires. Prefer a server or endpoint that contains only those operations. Some Google Cloud MCP servers offer toolsets: subsets of one server’s tools, each available through its own endpoint. The agent treats a toolset endpoint as a server. Google recommends using these subsets instead of a large general endpoint when they fit the task (Configure MCP in an AI application).

Use workspace or project scope for a server needed only by one repository. Use user or global scope only when the server is appropriate across projects. Review a shared configuration because a local stdio entry can start code on each developer’s machine.

Configuration files are client-specific; MCP does not standardize their shape. For example, Antigravity reads workspace servers from .agents/mcp_config.json, supports local commands and remote serverUrl entries, and provides a disabledTools list (Antigravity MCP configuration).

The following Antigravity configuration attaches the Secure Source Manager code-review toolset and withholds its comment-writing tool:

{
  "mcpServers": {
    "source-review": {
      "serverUrl": "https://securesourcemanager.googleapis.com/mcp/code_review",
      "authProviderType": "google_credentials",
      "disabledTools": ["batch_create_pull_request_comments"]
    }
  }
}

The selected Secure Source Manager toolset contains pull-request reads plus the comment-writing tool. Withholding that tool leaves the agent able to inspect a review without publishing comments. If the task later requires comments, enable that capability only for the workflow that needs it.

Set permission and verify the effective surface

Exposure and approval are different. In Antigravity, unconfigured MCP tools use Ask mode. A policy can match one tool, one server, or all MCP tools. Prefer a specific tool rule over a server-wide or global wildcard (Antigravity MCP permissions).

Verify the result in the client’s MCP manager or tool listing:

  1. Confirm that the intended server connects through the expected transport and endpoint.
  2. Inspect the effective tool list, including tools added by a server update.
  3. Run a representative allowed read and confirm its expected result.
  4. Confirm that an excluded or denied write is unavailable or blocked.
  5. Recheck the list when the task, server version, or server authorization changes.

An exclusion list requires maintenance because a server can add a new tool that is not named in the list. Prefer a server-side toolset or a client allowlist when available, then use exclusions for any remaining tools.

Key distinctions and trade-offs

Tool exposure versus tool search: Tool search can defer loading full tool definitions until they are relevant. It does not remove the capability. A searchable write tool remains available unless another control withholds or denies it. See Claude Code’s tool-search behavior.

Read-only label versus enforcement: A tool name, description, or annotation helps the model select a tool. It is not an authorization boundary. Enforce read-only behavior through the chosen endpoint, client controls, and backend permissions.

Broad reuse versus least capability: A broad server is convenient across many tasks and needs fewer configuration changes. A narrow surface reduces irrelevant choices and unintended actions, but teams must update it when the task changes. Optimize for the active workflow, not for every possible future request.

Architecture / decision scenario

A team uses a coding agent to review pull requests in Secure Source Manager. The agent must read pull-request metadata and file diffs, then write findings to a local report. It must not publish comments, merge changes, or manage repositories.

The architect attaches the /mcp/code_review toolset at project scope rather than the full /mcp endpoint. The client withholds batch_create_pull_request_comments, and permission rules cover only the remaining read tools. Backend credentials also have only the required repository access. The team verifies both a successful diff read and a blocked comment action.

For a later remediation workflow, the team creates a separate configuration and approval path instead of broadening every review session.

Common exam traps

  • Treating a successful server connection as permission to use every tool.
  • Assuming the MCP protocol standardizes each coding agent’s configuration file.
  • Using a full server endpoint when a task-specific toolset exists.
  • Confusing tool search or deferred loading with removal of a capability.
  • Auto-approving server/* or all MCP tools when only one operation is needed.
  • Assuming a tool’s read-only description replaces backend authorization.
  • Filtering today’s tools without checking for newly advertised tools later.

What to remember

  • Derive MCP access from the coding task’s required operations.
  • Prefer a narrow server or toolset, then filter the remaining tools.
  • Keep connection, model exposure, invocation permission, and backend authorization separate.
  • Verify both an allowed operation and an excluded or denied operation.
  • Reassess the effective tool surface when tasks or servers change.

Knowledge check

References