Implement tool use and environment interaction

An agent reports that it cannot open a pull request. The cause could be a tool the agent was never offered, a tool it can see but may not run, a credential sitting in an environment variable its program never reads, a setup workflow that exists only on a feature branch, or a branch protection doing exactly its job. Each of those causes is settled by a different control, and this domain, which carries 20–25% of the exam, trains you to name that control before changing anything. The controls sort into four decisions that every tool-using agent needs answered. Tool capability decides which tools exist for the agent, which it is offered, which it may run, and which credential each program reads. MCP server setup decides how Model Context Protocol (MCP) servers, the programs that expose tools to an agent through an open protocol, are declared, connected, and allowed. Execution context decides which machine the agent runs on, where its configuration is read from, and which grant each surface issues (a surface is any place a behavior is configured or decided, such as a file, a setting, or how a task starts). Safe operation decides how a failure is classified, retried, rolled back, escalated, and recorded. The classic trap is a correct fix applied to the wrong control: approving a tool the environment does not have, or widening the permissions block of the copilot-setup-steps job (the job that prepares Copilot cloud agent's environment) to change what the agent may push, when that push scope comes from the task's working branch.

Read the four subtopics in order; each builds on the last. Select and configure agent tools (the tools page) covers tool capability: it separates whether a tool exists in the environment, whether the model is offered it (a custom agent's tools list or Copilot CLI's visibility flags), and whether it may run (Copilot CLI's allow and deny rules, or each MCP server's tools field for Copilot cloud agent, a separate property from the custom agent's tools list), and where each program looks for its credential. Configure MCP servers (the MCP page) covers MCP server setup: which configuration surface a given agent reads (repository MCP settings on GitHub, a VS Code mcp.json file, or a custom agent profile), launching a server as a subprocess that talks over its standard input and output (stdio) versus reaching a hosted one over Streamable HTTP, and the registry and allow/deny-list policies that control which servers developers may use. Integrate agents within development environments (the environment page) covers execution context: a local agent, a cloud agent, and a CI (continuous integration) invocation are separate execution contexts, several configuration files are read only from the repository's default branch, and each grant, such as setup-job permissions or the agent's working branch, is scoped to the surface that issued it. Operate agents with safe execution paths and robust error handling (the safe-operation page) covers safe operation: classify a failure before retrying, retry only the smallest unit that failed and only a bounded number of times, inspect what already happened before replaying anything with side effects, roll back where the change actually lives, escalate through a channel that exists where the agent runs, and keep evidence that outlives the run. MCP appears on the other three pages too, so here is the split: the tools page covers choosing and permitting a server's individual tools, the environment page covers which machine a server runs on and how an unattended CLI loads it, the safe-operation page covers telling MCP protocol errors from tool errors, and the MCP page covers declaring, connecting, and governing the server itself.

Across all four decisions the exam rewards the same instinct: choose the smallest grant, prepared before the run starts, that stays safe when no person is present to answer a prompt. That means an explicit tools list in a custom agent profile rather than an omitted one, since omitting that property enables every available tool; specific read-only tools in an MCP server's tools field rather than ["*"], because Copilot cloud agent uses configured MCP tools autonomously and does not ask for approval first; in Copilot CLI, an allow rule naming one tool or a targeted deny rule rather than a blanket allow; dependencies installed in the setup workflow rather than discovered by trial and error; and a bounded retry or an escalation rather than a loop. The same instinct reads blockers correctly: a branch protection, a required check, or a pending workflow approval is a gate for a person to clear, not an error for the agent to retry around.