Choose a tool for an enterprise action
Some requests to your help agent need the current state of one record or a change in a system, and your policy content doesn't hold either one. In this unit, you learn how to choose a tool type that fits a lookup or action, and you explore how enhanced orchestration decides when to call that tool.
Separate grounded search from a lookup or action
Start with what the request needs from the agent. Knowledge search fits questions that the content in your sources answers, such as what the equipment policy says about who qualifies for a second monitor. Without tools, an agent can answer questions only from its instructions and knowledge sources.
Tools extend what the agent can do. They let an agent call APIs, run automated flows, interact with external services, and retrieve real-time data. A tool usually delivers one of two outcomes:
- Lookup: The agent retrieves specific, current data from a system, such as the status stored in one record. A lookup reads data and leaves the system unchanged.
- Action: The agent changes something in a system, such as creating a record, sending a notification, or updating data.
The wording of a request often points toward one of these outcomes. A question about one user's own item, or about a value that changes during the day, leans toward a lookup. A request to submit, create, update, or send leans toward an action. A question whose answer is the same for every user and lives in documents leans toward knowledge. Treat these cues as a starting point, because the right retrieval design depends on the source and the task.
An action also carries side effects that a lookup doesn't. When the agent creates an item, that item stays in the list after the conversation ends. Plan who's authorized to trigger the action, and use test data while you build and try out the agent.
In your help agent, a question about the equipment policy goes to knowledge. A question such as "What's the status of my monitor request?" is a lookup against one item in the SharePoint list. A request such as "I need a new laptop dock" is an action that creates a new item.
Match the tool type to the requirement
After you confirm that a request needs a tool, choose the type of tool that carries it out. The following table compares three tool types available to agents powered by the GitHub Copilot harness.
| Tool type | Best for | Signals in the requirement | Example in the help agent |
|---|---|---|---|
| Connector | Well-known services that have prebuilt connectors | A connector for the system already offers the read or write action you need | Look up a request with a read action such as Get items, or submit one with Create item |
| MCP server | Custom or internal services that use the MCP standard | An internal service or database exposes its capabilities through an MCP server | Check an internal asset service that exposes its capabilities through an existing MCP server |
| Workflow | Multi-step, automated, deterministic processes | The same steps must run in a fixed order every time, such as an approval | Run an approval step before the workflow creates the list item |
Power Platform connectors expose actions from hundreds of external services, and connector actions can read from and write to systems such as SharePoint and Outlook. The SharePoint connector shows this range. It includes read actions such as Get item and Get items, and a write action, Create item, so one connector covers both the status lookup and the new request.
A Model Context Protocol (MCP) server provides tools through a standardized protocol. It can expose capabilities from custom services, databases, or internal APIs. MCP servers count against the total number of tools an agent can host, and the number of concurrent MCP instances is capped, so keep the set of servers you attach small.
A workflow is an automated flow that you build in the Copilot Studio flow designer. It runs a multi-step process, such as an approval, a data transformation, or other business logic, and the agent can run it on demand.
Sometimes more than one tool type can reach the same system, so choose the smallest component that meets the requirement. If submitting an equipment request means only creating the list item, a connector action fits. If your organization requires an approval before the item exists, the requirement is a fixed sequence of steps, and a workflow fits.
Learn more in Available tools for agents.
Guide how the orchestrator selects a tool
Adding a tool gives the agent the ability to call it. The decision about when to call it belongs to the orchestrator. Agents powered by the GitHub Copilot harness use enhanced orchestration to determine automatically when to invoke a tool. The orchestrator evaluates each user message and decides whether a tool is needed. When a tool is needed, the orchestrator selects one based on the conversation context and the tool's name and description. For conversational tool use, you don't create explicit triggers or topic flows for each tool call.
Three inputs that you control shape the orchestrator's decision:
- Tool name: A specific name that states the tool's job gives the orchestrator a clear signal about what the tool does.
- Tool description: The description tells the orchestrator what the tool does and when it applies. Well-described tools are invoked more accurately.
- Agent instructions: Instructions are the primary way you control agent behavior. They tell the agent what to do, how to respond, and what to avoid, and they also influence when the agent uses tools.
These inputs guide the orchestrator's choice among tools the agent already has. They don't give the agent access to a system, create a connection, or guarantee that the orchestrator calls a particular tool for a given message. If the SharePoint connector isn't added to your help agent, no instruction or description makes its actions available.
In your help agent, "Where's my dock request?" and "I need a new dock" both mention equipment. The orchestrator uses the conversation context and each tool's name and description to tell a status lookup from a new request. Your instructions can add guidance, such as asking the agent to confirm the request details with the employee before it creates an item.
Learn more in Tools overview for agents.
Reflect: Pick three requests that users make, or are likely to make, of an agent you're planning or building: one that needs a lookup, one that needs an action, and one that knowledge answers. For the lookup and the action, which tool type fits, and which cue in the request points you to it?
Later in this module, you explore the common path for adding an existing connector action, how names and descriptions improve selection, and how to confirm in Preview that the intended tool runs with the right inputs and result.