Integrate and extend agents in Copilot Studio
Tools, Computer Use, MCP, Connectors, and APIs
CoreExtend agents with governed tools, including computer use, MCP servers, custom connectors, and REST APIs.
Aligned to the AB-620 live Skills measured outline; visible page date April 21, 2026; product behavior verified September 19, 2026.
Why this matters
Tools cross the boundary from generating text to reading or changing systems. Descriptions, schemas, authentication, approvals, and least privilege determine whether orchestration can select and execute them safely.
Must Know
- Configure and monitor computer use for an agent: Use computer use for supported UI automation when an API or connector is unavailable, with isolated credentials, clear instructions, testing, and run monitoring.
- Configure MCP tools: Connect an approved MCP server, review exposed tools and schemas, configure authentication, and give the agent clear selection descriptions.
- Add a tool by using an existing custom connector: Select the custom connector operation, create the required connection, describe the tool, and map its schema for orchestration.
- Add REST APIs to an agent: Import or define the REST API contract, choose operations, configure authentication, and expose bounded tools with usable descriptions.
Compare and Distinguish
- A connector exposes typed operations backed by a connection; an MCP server exposes protocol-described tools; a REST API tool is derived from an API description.
- Computer use operates a user interface when a suitable API or connector is unavailable; API-based automation is usually more stable and observable.
- A tool description helps generative orchestration decide when to call it; the input and output schema governs the actual invocation contract.
Scenario examples
- Scenario: A pilot succeeds but production users have different permissions. Think: trace identity and authorization through every source, tool, and delegated agent.
- Scenario: A component works in development but fails after deployment. Think: inspect solution dependencies, connections, environment configuration, and channel-specific behavior.
- Scenario: A response is fluent but the operational result is uncertain. Think: separate generation from retrieval, tool execution, telemetry, and verification.
Exam traps
- Giving a tool broad write permission when the use case only needs a narrow read operation.
- Relying on UI coordinates for computer use without testing application state and recovery.
- Adding an MCP server or API without validating its published operations, authentication, and data policy classification.
Key takeaways
- Prefer a typed API or connector when available; use computer use for supported UI automation, and govern every tool’s schema, identity, description, and monitoring.
- Make the identity, data, lifecycle, and failure boundaries explicit for add tools to agents.
- Validate the behavior with representative evidence before broad deployment.
How it works
- Copilot Studio uses the configured descriptions, instructions, conversation state, and orchestration mode to select the relevant topic, knowledge, tool, flow, or connected agent.
- Runtime identity and environment configuration determine whether the selected capability can access its dependency and return a governed result.
Objects and administrative surfaces
- Copilot Studio Tools page and tool configuration.
- Computer use configuration and run monitoring.
- Power Platform custom connectors and connection references.
- MCP server or REST API endpoint configuration and authentication.
When to use it
- Use this topic when the requirement maps to add tools to agents.
- Prefer the narrowest supported surface that satisfies the required behavior and governance boundary.
Security and governance implications
- Apply least privilege to maker, runtime, connector, source, and deployment identities.
- Classify data and connectors, preserve audit evidence, and avoid exposing secrets or sensitive payloads in prompts and telemetry.
Troubleshooting signals
- Reproduce with the same version, channel, identity, inputs, and environment before changing configuration.
- Use activity traces, flow runs, tool errors, evaluation results, or telemetry to locate the failing layer.
More detail
- Match the requirement to the narrowest supported surface: a custom connector packages typed operations behind a managed connection, MCP discovers capabilities published by a server, and a REST API tool exposes selected contract operations.
- Tool descriptions guide generative selection, while input and output schemas control the actual call. Both must be clear enough for the agent to choose and invoke the capability correctly.
- Configure authentication and runtime permissions for the specific endpoint or operation; making a tool visible to an agent does not authorize its underlying resource.
- Choose computer use only for supported interaction with a user interface that lacks a suitable programmatic integration. Isolate its credentials, write unambiguous instructions, exercise representative runs, and inspect monitoring evidence.
- Expose only the required operations, then test valid inputs, rejected inputs, downstream errors, and returned results so failures remain bounded and diagnosable.
Ready for the quiz?
- Which requirement determines the correct surface for add tools to agents?
- Which identity performs the operation, and where is authorization enforced?
- What evidence distinguishes a safe successful result from a fluent but incomplete one?
Related objectives
- D2.2.S1 — Configure and monitor computer use for an agent
- D2.2.S2 — Configure MCP tools
- D2.2.S3 — Add a tool by using an existing custom connector
- D2.2.S4 — Add REST APIs to an agent