Chapter 4: Agent Knowledge & Protocols: MCP & Foundry IQ

In Chapter 3, you registered tools by writing JSON tool definitions and implementing handler functions in your application code. That approach works when you control both the agent and the tools. But in the insurance company scenario from Section 4.1, the tools belong to other teams. Each team exposes its capabilities through different mechanisms: the CRM team offers a REST API with OAuth 2.0 authentication, the ticketing system uses GraphQL with API key authentication, and the billing platform provides a proprietary SDK with certificate-based authentication.

Without a standard protocol, you face tool fragmentation — every new tool integration requires custom code for discovery (what tools are available?), authentication (how do I prove I am allowed to call this?), invocation (how do I format the request?), and response handling (how do I parse the result?). If your organization has twenty services and five agent teams, you end up with a hundred bespoke integrations, each a maintenance liability.

The Model Context Protocol (MCP) solves this by defining a single, open standard for how agents discover and interact with external tools. Instead of writing custom integration code for each service, you connect your agent to an MCP server, and the server tells the agent what tools are available, what parameters they accept, and how to call them — using a uniform protocol that works the same way regardless of the underlying service.

The MCP architecture follows a client-server model. Your agent acts as an MCP client. Each external service that wants to expose tools to agents runs an MCP server. The MCP server wraps the service’s native API behind a standardized interface, translating between the MCP protocol and whatever the underlying service actually speaks.

In the insurance company scenario, the architecture would look like this. The CRM team deploys an MCP server that wraps their REST API. This server exposes tools like lookup_policyholder, get_policy_details, and update_contact_info. The IT operations team deploys an MCP server that wraps their ticketing system, exposing tools like create_claim_ticket, get_claim_status, and assign_adjuster. The finance team deploys an MCP server that wraps their billing platform, exposing tools like get_premium_balance and record_payment.

Your claims processing agent connects to all three MCP servers. From the agent’s perspective, these tools look identical — same protocol, same message format, same invocation pattern. The agent does not know or care that one tool talks to a REST API and another talks to a GraphQL endpoint behind the scenes.

An MCP connection follows a structured lifecycle with three phases: initialization, discovery, and operation.

Phase 1: Initialization. The MCP client (your agent) establishes a connection to an MCP server. The client sends an initialize request that includes the client’s protocol version and capabilities. The server responds with its own protocol version and capabilities. This handshake ensures both sides agree on what protocol features they support — capability negotiation happens here, during the initialize exchange, not as a separate later step.

Phase 2: Discovery. After the initialize handshake completes, the client queries the server’s available tools. The most common query is tools/list, which returns a list of all tools the server exposes, including their names, descriptions, and parameter schemas. The client can also query for resources (data the server can provide) and prompts (templates the server offers). This phase is where dynamic tool discovery happens — the agent learns what tools are available at runtime rather than having them hardcoded at development time.

Phase 3: Operation. With the tool catalog in hand, the agent can invoke tools using tools/call requests. Each request specifies the tool name and arguments, and the server returns the result. The agent can make as many tool calls as needed during a session.

Dynamic tool discovery is one of MCP’s most powerful features. In the Chapter 3 approach, your agent’s tool list was fixed at development time — you wrote the tool definitions in your code and deployed them. If a new tool became available, you had to update your code and redeploy.

With MCP, the agent discovers available tools at connection time by calling tools/list. This means that when the CRM team adds a new get_claims_history tool to their MCP server, your agent automatically discovers it the next time it connects. You do not need to change your agent code. The server’s tool list is the source of truth, and it is always current.

Dynamic discovery also enables the agent to adapt to different environments. A development MCP server might expose a limited set of tools with mock data, while a production MCP server exposes the full set with real data. The same agent code works in both environments because it discovers what is available rather than assuming a fixed tool set.

MCP uses JSON-RPC 2.0 as its message format. Every message — whether a request, response, or notification — follows the JSON-RPC specification with a method name, parameters, and an ID for correlating requests with responses.

Here is what a tools/list request and response look like:

And here is a tools/call request and response:

MCP supports two transport mechanisms. The first is stdio (standard input/output), where the MCP server runs as a local subprocess and communicates through stdin and stdout pipes. This transport is ideal for development and local tool servers. The second is HTTP with Server-Sent Events (SSE), where the MCP server runs as a remote web service. The client sends requests via HTTP POST, and the server streams responses and notifications back through SSE. This transport is designed for production deployments where MCP servers run on separate infrastructure.

The choice of transport does not affect the message format — the JSON-RPC messages are identical regardless of whether they travel over stdio or HTTP. This separation of concerns means you can develop and test with stdio locally and deploy with HTTP/SSE in production without changing your tool invocation logic.

MCP connections cross trust boundaries, and security must be addressed at multiple layers. Authentication verifies the identity of the client connecting to the MCP server. For HTTP/SSE transport, this typically uses OAuth 2.0 tokens or API keys sent in request headers. For stdio transport, the security boundary is the operating system process model — only processes that can launch the MCP server subprocess can communicate with it.

Authorization controls which tools a given client is allowed to call. An MCP server can restrict tool access based on the client’s identity — for example, allowing the claims agent to call lookup_policyholder but not delete_policy. This is typically implemented in the MCP server’s middleware layer.

Input validation is the server’s responsibility. The MCP server must validate all arguments received from clients before passing them to the underlying service. An agent might send unexpected parameter values — whether through model hallucination or adversarial prompting — and the server must handle these gracefully.

Transport encryption protects data in transit. HTTP/SSE connections should always use TLS. Stdio connections are inherently local and do not traverse the network, so transport encryption is not applicable.

Microsoft Foundry supports MCP as a tool connection method for agents. When you create an agent in Microsoft Foundry, you can register MCP servers alongside locally defined tools. The agent treats both kinds of tools uniformly — it discovers them, sees their schemas, and calls them using the same tool-call lifecycle you learned in Chapter 3.

To connect a Foundry agent to an MCP server, you provide the server’s endpoint URL and authentication details as part of the agent’s tool configuration. The agent then discovers the server’s tools at connection time and can call them as part of its reasoning loop.

Once configured, the agent automatically discovers the tools exposed by the MCP server. When the agent’s reasoning loop determines that it needs to check a claim’s status, it issues a tools/call to the remote tool just as it would call a local function — but the execution happens on the remote MCP server.

MCP tool calls over HTTP/SSE introduce network latency that local tool calls do not have. A local tool executes in milliseconds. A remote MCP tool call involves an HTTP round trip, server-side processing, and a response — typically adding hundreds of milliseconds to seconds per call.

This latency matters for the agent’s reasoning loop. If the agent makes five sequential tool calls, each taking one second, the total wait time is five seconds before the agent can generate a response. Users notice this delay.

Three strategies help manage MCP tool latency. First, batch when possible — if the agent needs data from multiple tools on the same MCP server, some implementations support batch requests that reduce round trips. Second, set explicit timeouts — configure your agent to abandon tool calls that take too long rather than waiting indefinitely. Third, cache tool results where appropriate — if a policyholder’s information does not change during a single claims processing session, cache the first lookup result and reuse it.

MCP tools introduce failure modes that local tools do not have. The MCP server might be unreachable due to a network partition. The server might return an error because the underlying service is down. The connection might time out. The server might return a valid MCP response that contains an error message from the backend system.

Your agent needs to handle all of these gracefully. At the transport level, implement retry logic with exponential backoff for transient network failures. At the protocol level, check the MCP response for error codes and messages. At the application level, instruct your agent through its system prompt on how to behave when tools fail — should it inform the user, try an alternative approach, or proceed with partial information?

Not every tool should be reached through MCP. Use an MCP server when the tool wraps a service maintained by another team, when the tool’s implementation changes independently of your agent, or when the tool accesses data that must stay within a particular security boundary (the data never leaves the MCP server’s environment — only the result comes back to your agent).

Use local tool definitions, like the ones you wrote in Chapter 3, when you control the tool’s implementation, when low latency is critical, or when the tool is simple enough that the overhead of an MCP server is not justified. A tool that formats a date or calculates a percentage does not need its own MCP server.

In practice, most production agents use a mix of both. The claims processing agent might define local tools for text formatting and data validation while connecting to MCP servers for CRM access, ticket management, and billing operations.

The central abstraction in Foundry IQ is the knowledge base. A knowledge base aggregates one or more knowledge sources into a single retrieval target that an agent can query. A knowledge source is a connection to a place where your organization’s information lives. Foundry IQ supports several kinds of knowledge sources, including:

For the insurance claims agent, a single knowledge base might aggregate three sources: a Blob Storage container holding the precedent-ruling archive, a SharePoint site holding current policy language, and a public web source pointing at the state regulator’s published guidelines. The agent does not query three separate systems with three different access patterns. It queries one knowledge base, and Foundry IQ fans the query out across the underlying sources.

A knowledge base is permission-aware. Because the underlying sources — SharePoint, OneLake, and others — carry their own access control, Foundry IQ can honor those permissions at query time, so a user only receives results from documents they are actually allowed to see.

This matters enormously in the insurance scenario. A claims adjuster handling consumer policies should not retrieve precedent rulings sealed for legal review, and a contractor with limited access should not see internal compliance memos. With hand-built RAG, enforcing this is on you: you must propagate identity into every query and filter results yourself, which is error-prone and easy to get subtly wrong. Permission-aware retrieval pushes that enforcement down into the managed layer, so the knowledge base returns grounded answers that respect the requesting user’s access rights.

The feature that most distinguishes Foundry IQ from a classic RAG pipeline is agentic retrieval: Foundry IQ treats retrieval itself as a reasoning task rather than a single similarity lookup.

When the agent sends a question to the knowledge base, Foundry IQ does the following:

The phrase "agentic retrieval" is precise: the retrieval layer is itself doing a small amount of agent-like reasoning — planning, decomposing, searching, and reranking — before it ever hands results back to the calling agent. Your agent asks one question; Foundry IQ may run several searches to answer it well.

It is worth being explicit about how a Foundry IQ knowledge base differs from the RAG pipeline you built in Chapter 2, because they solve the same underlying problem — grounding an answer in your documents — in very different ways.

The trade-off is the familiar one between control and convenience. Hand-built RAG gives you full visibility into and control over every retrieval step — which is why you learned it first in Chapter 2. Foundry IQ gives you a managed, multi-source, reasoning-driven retrieval layer that you attach to an agent rather than maintain yourself. For an enterprise with knowledge scattered across many systems and strict access rules, the managed layer usually wins.

From the agent’s perspective, a Foundry IQ knowledge base is a knowledge tool it can call. You create or reference a knowledge base (configured with its knowledge sources) and attach it to the agent. When the agent’s reasoning determines that it needs grounded information, it queries the knowledge base and incorporates the returned, cited content into its answer.

In Lab 8, you will connect a Microsoft Foundry agent to an MCP server and have it discover and invoke the server’s tools. As you work through the lab, pay attention to the following:

In Lab 9, you will attach a Foundry IQ knowledge base to an agent and observe agentic retrieval in action. Focus on:

Identify which of the agent’s capabilities should be reached through MCP servers rather than local tool definitions. For each, name the owning team and the backend system, and explain why MCP is the right choice — using the criteria from Section 4.3.4 (another team owns it, it changes independently, or it must stay inside a security boundary). Do not route everything through MCP; call out at least one capability that is better as a local tool and say why.

Specify the knowledge base your agent will use and the knowledge sources it aggregates. For each source (Blob Storage, SharePoint, OneLake, or public web), explain what information it provides and why it belongs in the knowledge base. Address permission-aware retrieval explicitly: which users should see which sources, and how does the managed layer enforce that?

Choose one realistic compound question an adjuster might ask, and trace how agentic retrieval would handle it: how it decomposes into subqueries, which sources each subquery hits, how reranking selects the best passages, and what citations come back. Then contrast this with how you would have answered the same question using the Chapter 2 hand-built RAG pipeline. Be specific about what the managed layer does that your hand-built pipeline did not.

Identify what can go wrong across both layers. For MCP: unreachable servers, timeouts, and untrusted tool output crossing a trust boundary. For Foundry IQ: a source that is stale, a permission misconfiguration, or an answer whose citations do not actually support it. For each failure mode, describe a specific mitigation. The assessment rewards thoroughness of thinking, not complexity — a simple, clearly explained mitigation beats a hand-waved complex one.