Skip to content
FR

Design AI Solution Extensibility

Step 11 of 22

Microsoft Foundry Models, MCP, and Copilot Extensibility

Microsoft Foundry model deployment and MCP integration let an AB-100 architect extend Copilot with specialized intelligence, live data, and business actions. This lesson covers Design AI-powered business solutions (25–30% in the course outline before the announced November 16, 2026 update). You will compare deployment types, distinguish indexed knowledge from live connectors, and design controlled actions in supported Microsoft 365 experiences.

Learning objectives

After this lesson you can:

  • Choose between Microsoft 365 Copilot extensibility, Copilot Studio and Microsoft Foundry for a given scenario.
  • Select a Foundry model deployment option (serverless, provisioned, managed compute) based on cost, latency, data residency and customization needs.
  • Explain what MCP is and how agents, Copilot plugins and Foundry tools use it.
  • Pick the right Microsoft 365 Copilot extension point: declarative agent, API plugin, MCP-based action, synced or federated Copilot connector.
  • Describe how agent behavior is shaped (instructions, knowledge, tools, confirmations) and how Teams and SharePoint act as knowledge and delivery surfaces.
  • Recognize when Computer Use is the right integration, and when it is not.

1. Where to build: three extensibility families

Family Typical builder Strength Choose it when
Microsoft 365 Copilot extensibility (declarative agents, plugins, Copilot connectors) Makers and developers Runs inside Copilot, Teams, Outlook, Word; inherits Microsoft 365 security and compliance The users already work in Microsoft 365 and Copilot's own orchestrator is enough
Copilot Studio Makers (low-code) Topics, tools, knowledge, autonomous triggers, many connectors Business teams must own the agent and ship quickly
Microsoft Foundry Solution teams using the portal or SDKs Model choice, custom orchestration, hosted agents, evaluation, fine-tuning where supported You need specific models, full control of the logic, or non-Microsoft-365 channels

These are not exclusive. A common architecture exposes a Foundry-hosted capability through MCP or an API, and consumes it from a Copilot Studio or declarative agent.

2. Microsoft Foundry models

Microsoft Foundry offers a catalog of thousands of models: models sold directly by Azure (for example OpenAI models), and models from partners and the community. As an architect you choose a model and a deployment type.

Deployment options

Option Billing and capacity Fits
Serverless, standard Pay per token, shared capacity Variable or low volume, experiments, most business agents
Serverless, provisioned throughput Reserved provisioned throughput units (PTUs), lower latency variance under a suitable load Steady, high-volume, latency-sensitive production workloads
Serverless, batch Discounted, asynchronous Large offline jobs (classification of archives, bulk summarization)
Managed compute You pay for the virtual machines Open-source or custom models you host

For Serverless API deployments, the exact SKU combines a processing scope with a capacity model: for example, Global Standard or Data Zone Provisioned. Global inference can run across Azure regions; Data Zone constrains it to a specified zone such as the EU; Standard and Regional Provisioned constrain it to the selected Azure geography, which may include more than one region. Resource location and data stored at rest do not, by themselves, establish where inference runs. Check the model, SKU, and data-handling terms against the requirement. Managed compute has its own hosting configuration rather than these serverless SKU categories.

Not every model supports every SKU or location. Provisioned capacity does not guarantee every application response time: token counts, tool calls, network latency, and load still matter. Benchmark the complete agent and compare costs using ROI, TCO, and model routing.

Selection criteria

  • Task fit: reasoning-heavy planning versus simple extraction; multimodal needs; context window.
  • Cost and latency: use smaller, cheaper models for simple steps and larger models only where needed. A model router deployment picks a suitable underlying model per request to balance quality and cost (see the cost chapter).
  • Customization: try prompting and grounding, including retrieval, first, and use fine-tuning only when behavior or style cannot be reached otherwise and enough quality data exists. Not every model supports fine-tuning.
  • Governance: content filters, region availability, model lifecycle (models are retired on a published schedule, so plan upgrades).

Exam tip: if a requirement says "predictable latency under sustained high load", think provisioned throughput; "occasional use, pay for what is used", think standard.

3. Model Context Protocol (MCP)

MCP is an open protocol that lets an AI client discover and call tools and read resources exposed by a server in a standard way. A server can be reused by compatible clients, reducing repeated integration work. Authentication, transport, schemas, and supported capabilities still need compatibility checks.

  • MCP server: exposes tools (for example "get open orders", "create ticket"), each with a name, description and input schema.
  • MCP client: the protocol component inside an AI application or runtime that connects to an MCP server. The host and its model decide which tools to request and handle authentication, approvals, and results. Supported MCP features vary between hosts; do not assume every host consumes resources, prompts, and tools in the same way.
  • As with generative orchestration, tool names and descriptions drive selection, so write them precisely.

MCP in the Microsoft stack

  • Foundry Agent Service can connect an agent to remote MCP servers through its MCP tool, and you can limit the allowed tools to a subset so the agent cannot call everything the server exposes. Foundry also supports grouping tools into a reusable toolbox behind one MCP-compatible endpoint.
  • Copilot Studio can add an MCP server as a tool for an agent.
  • Microsoft 365 Copilot: MCP plugins can provide actions inside declarative agents; they are not standalone Copilot experiences. Federated Copilot connectors also use MCP for live external access. Confirm the manifest version and host support for the chosen integration route.

Design guidance

  • Prefer MCP or an API over screen automation when the system offers one.
  • Apply least privilege: authenticate with an identity limited to what the agent needs, restrict the tool list, and require approval for write or destructive tools.
  • Treat tool output as untrusted input: a malicious or compromised MCP server can inject instructions (prompt injection) or return sensitive data. Review servers, tool definitions, connection permissions, and data retention. Use explicit allowed-tool lists and approvals for high-risk calls. MCP does not establish a trust boundary or bypass source authorization. Review agent security and governance when deciding what may cross that boundary.
  • Keep servers focused: a few well-described tools beat dozens of overlapping ones.

4. Extending Microsoft 365 Copilot

Extension point What it does Choose it when
Declarative agent Configures Copilot with instructions, knowledge and actions for one scenario; Copilot's orchestrator and models do the work You want a scenario-specific Copilot without writing orchestration
API plugin / action Lets an agent call a REST API with an OpenAPI description, or an MCP server, to read or change data The agent must act on a business system
Copilot connector (synced) Ingests and indexes external content into Microsoft Graph Content is stable enough to index and you want Graph-based search, security trimming and relevance
Copilot connector (federated) Retrieves external content at query time through MCP without indexing it in Graph; write tools depend on the connector and rollout Data must stay in place, is highly dynamic, or cannot be copied
Custom engine agent Brings your own orchestration and models, delivered in Microsoft 365 channels You need full control of planning and models

Notes:

  • Agent behavior is shaped by clear instructions (role, scope, steps, tone, what to refuse), grounded knowledge, and the actions the agent may call. Microsoft recommends writing instructions as precise, structured guidance and testing them on real prompts.
  • Confirmations: design explicit confirmation for high-impact writes and verify what the host actually enforces. Permission to share information with a plugin is not identical to approval of a specific transaction. Validate arguments and authorization in the target API as well.
  • Teams and SharePoint are delivery and knowledge surfaces, with support depending on the agent type and host. Declarative agents can use supported Microsoft 365 knowledge; Copilot Studio SharePoint grounding requires the appropriate user authentication. Publishing in Teams does not automatically grant access to every chat or meeting. Test authorized and unauthorized users with the actual configuration.
  • Distinguish the technical MCP/API action plugin used by a declarative agent from broader product packages called plugins. Packaging, deployment, and governance requirements differ by route. The Copilot Studio agent design lesson explains how these actions participate in orchestration.

5. Computer Use

Computer Use lets an agent operate a browser or desktop application by seeing the screen and clicking and typing, the way a person would. It exists in Copilot Studio and in Foundry.

  • Use it for legacy or third-party apps without an API or MCP server.
  • UI-driven automation needs evaluation for latency, reliability, and auditability. It can adapt to some interface changes, but changed layouts, authentication prompts, and malicious on-screen instructions can still disrupt a task.
  • Run it in a controlled environment with a dedicated, least-privilege identity, and monitor sessions.

Compare supported structured integrations—connectors, APIs, or MCP tools—before computer use. MCP is not inherently better than a well-supported API; choose by capability, authentication, governance, and maintainability.

6. Worked example

A manufacturer wants a service-technician assistant inside Microsoft Teams.

  • Knowledge: repair manuals in SharePoint → add the SharePoint library as knowledge (permissions apply). Warranty data lives in a partner system that must not be copied → federated Copilot connector over MCP.
  • Action: create a work order in the ERP, which exposes an OpenAPI description → API plugin in a declarative agent, with a confirmation step before creation.
  • Specialist logic: a fault-prediction model trained on sensor data runs on managed compute in Foundry, with an endpoint wrapped as an MCP tool.
  • Legacy step: a supplier portal with no API → Computer Use, only for that step, with a dedicated identity.
  • Governance: restrict the MCP tool list, log calls, review servers before connecting.

Step-by-step architecture decision

  1. Separate knowledge retrieval from writes. A repair-manual search must not create a work order merely because a document suggests doing so.
  2. Use user-authenticated SharePoint grounding and validate access with two technicians whose library permissions differ.
  3. Check that a supported federated connector exists for the partner data. A partner MCP endpoint does not automatically become an approved federated Copilot connector. Otherwise, evaluate a supported custom-agent integration.
  4. Expose a narrowly scoped ERP create-work-order action. Validate the asset ID and technician’s rights in the ERP, show the proposed change, and require confirmation before submission.
  5. Select a supported hosting option for the specialist model. Measure its prediction accuracy separately from conversational answer quality and record dependency ownership and cost.
  6. Test missing warranty data, expired credentials, an unauthorized asset, and instructions embedded in a tool response. A failed lookup must not become a fabricated warranty entitlement.

A synced connector would violate the prohibition on indexing partner data. A larger model would not create ERP permissions. Computer use for every system would add UI dependencies despite existing structured interfaces.

Mini case: resource region versus inference scope

A supported model runs with Global Standard in an EU resource. The team claims that every prompt stays in the EU, as its policy requires. Is the resource location sufficient?

Solution: evaluate an EU Data Zone SKU supporting the required model and workload, review data-handling terms, and check every additional tool’s processing location. If capacity or model support is unavailable, choose a compliant alternative or hold the rollout. Provisioned capacity is a throughput decision, not proof of geographic compliance.

Example: evaluate deployment and integration separately

A service desk receives 600 requests during a normal business day and occasional bursts after a product launch. Its architect should measure input length, response length, concurrency, and tool latency before selecting capacity. The daily request total alone cannot determine the required throughput. For an initial supported model, compare standard serving with a provisioned option under representative traffic and record both cost and answer quality. This is an evaluation procedure, not a claim that one deployment type always wins.

Now consider one request: a technician asks whether an asset is under warranty. The agent might need a manual search, a live warranty lookup, and an ERP asset check. A fast model response does not remove delay from those services. Measure time to a useful answer and the success rate of required tool calls, rather than treating model latency as the entire user experience. Define what to do if the warranty lookup times out: return the confirmed facts, identify the missing evidence, and avoid promising coverage.

Finally, review connection scope. A read-only warranty operation does not need permission to modify contracts. Conversely, a permitted tool name does not prove that every asset identifier supplied to it is authorized. The partner service must check the caller’s rights on the requested record. These checks remain necessary whichever model or deployment SKU hosts the conversational reasoning.

Key terms

  • Deployment SKU: a concrete combination of processing scope and serving characteristics.
  • PTU: a provisioned throughput unit for reserved model-serving capacity.
  • Synced connector: indexes external content with permissions metadata.
  • Federated connector: retrieves from the source at query time.
  • MCP tool allow list: the specific remote tools an agent may use.

Key takeaways

  • Pick the platform by authoring, hosting, and control needs; Foundry offers portal and SDK routes.
  • Distinguish serverless SKUs from managed compute; verify supported models, processing geography, capacity, and workload latency.
  • MCP standardizes how agents discover and call tools; restrict tool lists, use least privilege and treat tool output as untrusted.
  • Declarative agents plus API plugins or MCP actions extend Copilot; synced connectors index data in Graph, federated connectors fetch it live through MCP.
  • Validate knowledge support, authentication, and source permissions for the actual agent type and host.
  • Evaluate Computer Use when no suitable supported structured integration meets the task.

Sources