6.3 Add Tools to a Topic

6.3 Add Tools to a Topic

Quick Answer: Register capabilities on the agent Tools page for generative selection, and/or insert Add a tool action nodes inside topics for deterministic calls. Write clear names and descriptions, configure inputs (dynamic AI fill vs custom values), set authentication and completion, then test that the right tool fires for the right intent.

Leaf skill Add tools to a topic sits next to agent-flow wiring and response formatting. AB-620 expects you to explain scope (agent vs topic), selection (planner vs hard-coded node), and metadata (descriptions that make generative orchestration safe and accurate).

What counts as a tool

Microsoft describes tools as building blocks that let the agent interact with external systems. Common tool types include:

You create tools from the agent Tools page (Add a tool → existing or New tool) or call existing tools from topics.

Agent-level tools vs topic-scoped calls

This distinction is an exam favorite.

Agent-level tools (orchestrator inventory)

Tools added to the agent are available for automatic orchestration across conversations when generative orchestration is on and Allow agent to decide dynamically when to use the tool remains selected.

The planner considers:

• Tool name and description
• Conversation context and derived user intent
• Available inputs/outputs and prior tool use in the conversation

Topic-scoped explicit calls

Inside a topic:

1. Topics → open topic → Add node → Add a tool.
2. Pick from tabs such as basic tools, connector, and tool catalogs.
3. An Action node appears; map inputs; continue the topic after outputs return.
4. Save (and republish agent as needed).

Use explicit topic calls when you need:

• Fixed order (authenticate → validate → tool → message)
• Branching that depends on tool outputs before any generative summary
• Classic orchestration, where tools cannot be freely planner-selected and must be called from topics
• Guarantees that a tool never runs without a prior adaptive card or policy check

You can combine both: register the tool on the agent for reuse, and call it from a topic. If dynamic use would be dangerous for a high-risk tool, clear the option that lets the agent decide dynamically so only explicit topic calls run it.

Descriptions that drive generative orchestration

Microsoft’s generative orchestration guidance is blunt: high-quality descriptions are how the agent associates user intent with tools and topics. For tools, the add wizard often prepopulates a description—edit it.

Writing style (exam-ready rules)

• Simple, direct language; active voice; present tense.
• Keywords users actually say (“weather,” “forecast,” “ticket,” “invoice”).
• One or two sentences: what it does and when to use it.
• Unique names: “Weather Forecast,” not ambiguous “Helper.”
• Disambiguate siblings: say what the tool does not do when two tools are similar.

Weak: Name Answer Question / Description This tool can answer questions.
Stronger: Name Create ServiceNow Incident / Description Creates an IT incident in ServiceNow for hardware or software failures. Use when the user needs a tracked ticket. Does not answer HR policy questions.

Poor overlap causes the agent to invoke multiple similar tools; test and revise descriptions.

Inputs, validation, and generative questions

On the tool configuration Inputs table, each parameter has a fill mode:

Customization can include display name, description, identify-as entity mapping, retry logic, and extra validation. Human-friendly input names (“start date,” “email address”) help the model form natural clarifying questions—so you often do not hand-author a Question node for every field when generative orchestration owns collection.

Still author explicit questions or adaptive cards when fields are sensitive, multi-field at once, or must match a corporate form layout.

Authentication, confirmation, and completion

Authentication

Tools run in the user context of the agent runtime and generally require authentication appropriately enabled:

• End user credentials: least privilege; user only sees what they can access (default pattern for many personal data tools).
• Maker-provided credentials: shared connection; good for common reference data, riskier for personal LOB records—govern carefully.

Ask the end user before running

Optional confirmation gate in the chat experience before the tool executes—useful for send-email or delete-record style actions. Default is often No; flip to require consent when business risk is high.

Completion

As in response formatting: don’t respond (fold into orchestrator reply), generative write-up, specific response, or Adaptive Card. Also choose which output variables remain available to the agent and downstream tools.

Classic vs generative recap for tools

Admin note: if an environment admin disables generative orchestration, agents there are classic-only—plan topic-level tool calls as the primary path.

Scenario patterns

Scenario A — Weather lookup (simple tool topic)

Topic Get weather with trigger phrases (“will it rain,” “today’s forecast”). Single Add a tool action for MSN Weather (or equivalent). Map location from variable or AI fill. Message or generative completion returns forecast. Teaches minimal topic + tool.

Scenario B — High-risk refund tool

Agent-level tool Issue Refund with dynamic use disabled. Only the Refund request topic calls it after manager-code validation and adaptive card confirmation. Completion uses Send specific response with amount and reference ID.

Scenario C — MCP specialist tools

MCP connector added at agent level; generative orchestration picks MCP tools by their published names/descriptions. Topic still used for onboarding explanation and responsible-AI disclosure, not for re-implementing each MCP method as a flow.

Scenario D — Classic mode customer

Tenant policy forces classic orchestration. Every connector action the business needs appears inside topics with trigger phrases and Question nodes. Agent-level tool list alone will not “wake up” without topic design.

Testing and activity map

With generative orchestration, use the test panel activity map to verify which tool or topic the planner chose. For topic action nodes, step through variables before and after the Action node. After schema changes, refresh the action node, save, republish, and start a new test conversation so stale context does not mask binding bugs.

Decision cheat sheet for AB-620

1. Need the planner to discover a capability from free text? Agent-level tool + excellent description + dynamic allowed.
2. Need guaranteed step order or classic mode? Topic Add a tool action node.
3. Multi-step systems choreography / HITL? Prefer agent flow tool (still invocable from topics).
4. No API, only UI? Computer use (with monitoring and governance).
5. Structured enterprise API reuse? Custom connector or REST tool with clear inputs/outputs.
6. Overlapping tools mis-fire? Rename, rewrite descriptions, add “does not” clauses, retest.

Closing checklist

• Tool published/available and visible on Tools page or topic picker.
• Description unique and intent-aligned.
• Inputs validated; sensitive fields not left to sloppy AI fill without confirmation.
• Auth mode matches data sensitivity.
• Completion mode matches compliance for user-visible text.
• Dynamic use enabled only when safe.
• Classic vs generative implications documented for the solution.

Adding tools to topics is how Copilot Studio agents leave the chat bubble and act on the enterprise. AB-620 rewards builders who choose the right scope, write metadata the orchestrator can trust, and still fall back to explicit topic actions when determinism wins.