Skip to lesson

MicrosoftMicrosoft Certified: Multi-Agent AI Solutions Expert2026-102.2 Design and implement agent memory, context management, and knowledge integration

Connect Search, Foundry IQ, and MCP knowledge

Completed by the knowledge check

Learning objective

Integrate knowledge through Azure AI Search, Foundry IQ knowledge bases, semantic search, and MCP-exposed sources.

Core idea

For an architect integrating agent knowledge, distinguish the content engine, the retrieval workflow, and the tool interface. Azure AI Search indexes and retrieves content. A Foundry IQ knowledge base provides a reusable knowledge layer backed by Azure AI Search agentic retrieval. Semantic ranker improves candidate ordering. Model Context Protocol (MCP) exposes retrieval operations through a tool contract.

These choices can be composed. Connecting a knowledge base through MCP does not replace Search, and choosing semantic ranking does not create a knowledge base. Decide which layer owns ingestion, query planning, credentials, evidence formatting, and response synthesis before selecting the integration.

The stable Search API supports minimal extractive agentic retrieval. The documented Foundry IQ agent connection and several advanced retrieval capabilities use preview APIs; status belongs to the specific integration, not the whole knowledge layer.

How it works

Connect an agent to a Search index

The Foundry AzureAISearchTool connects an agent to an existing Azure AI Search index. Its required parameters are project_connection_id and index_name. The index needs retrievable source text and a retrievable source URL for useful citations; vectors alone cannot provide readable evidence to the model.

query_type selects simple, vector, semantic, vector_simple_hybrid, or vector_semantic_hybrid. The documented default is vector_semantic_hybrid. top_k defaults to 5, and filter applies to every query the agent makes to that index. These tool parameters are distinct from direct Search REST parameters such as queryType, vectorQueries.k, and top.

The tool targets one index. Choose it when a specialist needs a bounded, known corpus and the agent can use the retrieved passages to generate an answer. It does not itself establish a cross-source knowledge-base plan. See 2.2.11 for assigning retrieval responsibilities across sources.

A project connection controls authentication to Search. For the documented private-network path, use Microsoft Entra project managed identity; the tool page says key-based authentication is not supported with private virtual networking. Choose authentication from the supported path rather than assuming every connection option works in every network configuration.

Add semantic ranking at the retrieval layer

The objective’s semantic-search clause corresponds to Azure AI Search’s semantic ranker: secondary ranking of text candidates after BM25 or RRF. For a direct Search query, queryType="semantic" and semanticConfiguration select the configured ranking path. For the agent tool, a semantic-containing query_type selects the corresponding search mode.

Semantic ranker does not generate a conversational answer. Its captions and optional answers are verbatim extracts from indexed content. An agent or a knowledge base’s answer-synthesis capability performs a separate generation step. Keep this distinction visible when deciding which component owns the final response.

See 2.2.10 for ranking inputs, scores, and candidate limits. Here, the integration decision is whether the retrieval layer returns selected passages or also synthesizes a response, and whether the agent’s instructions preserve their citations.

Use a knowledge base for reusable multi-source retrieval

Foundry IQ is the managed knowledge layer powered by Azure AI Search agentic retrieval. Its knowledge bases reference knowledge sources, which can wrap an existing search index or define another supported content integration. Indexed sources ingest content before querying; remote sources retrieve it at query time without copying it into a Search index.

A search-index knowledge source wraps an existing index. Azure blob and OneLake knowledge sources can generate indexing pipelines. Source-specific status matters: the knowledge-source overview marks remote SharePoint and MCP server knowledge sources preview. The existence of a generally available knowledge-base API does not make every connector generally available.

The stable 2026-04-01 retrieve API uses intents and supports minimal, extractive retrieval. The 2026-08-01-preview API supports capabilities including multi-turn messages, LLM query planning, configurable retrieval reasoning effort, and answer synthesis. The overview also states that the Azure and Foundry portals expose agentic retrieval through preview experiences. Do not assume that an object configured in a portal has the stable API schema.

Minimal retrieval skips LLM query planning. Preview low and medium effort can plan subqueries from the question and conversation context. Measure planning latency and model use, especially when the calling agent already decomposes the question.

Expose the knowledge base through MCP

The documented Foundry IQ connection creates a preview RemoteTool project connection using ProjectManagedIdentity. The knowledge-base MCP URL has the shape /knowledgebases/KNOWLEDGE_BASE_NAME/mcp?api-version=2026-08-01-preview on the Search endpoint. KNOWLEDGE_BASE_NAME is the configured knowledge base’s name.

The agent’s MCPTool supplies server_url, server_label, and project_connection_id. knowledge_base_retrieve is the only knowledge-base MCP tool Foundry Agent Service supports; list it in allowed_tools. That tool name is the concrete retrieval interface, while the knowledge base owns source execution behind it. Approval behavior uses require_approval; see 2.3.4 for MCP client approval handling rather than treating approval as source authorization.

Assign Search Index Data Reader on Search to the project’s managed identity for the documented read-only connection. When the knowledge base specifies an LLM, the connection page conditionally requires Cognitive Services User for the search service’s system-assigned managed identity on the Foundry parent resource. These are two different calling identities and two different access directions.

For protected content, carry the end user’s token in x-ms-query-source-authorization as required by the source. The Foundry connection guide shows request-varying MCP headers through structured inputs and a {{search_auth_token}} placeholder. See 2.2.11 for fail-closed application checks and permission-ingestion requirements. The service connection authenticates the tool call; it does not replace the user’s content permissions.

Distinguish an MCP endpoint from an MCP knowledge source

An agent can call an external MCP server directly using the documented mcp tool configuration, including a project connection and allowed_tools. In that design, the agent owns how the tool result becomes evidence. Verify the server’s provenance and authorization before accepting its evidence.

Alternatively, an MCP server knowledge source is a preview remote source inside an Azure AI Search knowledge base. The knowledge base retrieves live tool-backed results and combines them with its other sources. Exposing a knowledge base as an MCP server and consuming an MCP server as a knowledge source are opposite integration directions.

The knowledge-source path adds the knowledge base between the agent and the MCP server.

The knowledge-source path adds the knowledge base between the agent and the MCP serverOn the left, the agent calls an external MCP server directly through the mcp tool and owns how the result becomes evidence. On the right, the agent reaches a knowledge base, which retrieves live tool-backed results from the MCP server knowledge source and combines them with its other sources. The difference is the knowledge base hop.MCP knowledge sourceMCP endpointmcp toolAgentKnowledge baseMCP serverknowledge sourceIts other sourcesAgentExternal MCPserver

Key distinctions and trade-offs

Direct Search tool versus knowledge base: The direct tool targets one index. A knowledge base provides source orchestration and a reusable retrieval contract across configured sources.

Semantic ranking versus answer synthesis: Ranking reorders and extracts existing text. Synthesis generates a response from grounding data and is a separate preview knowledge-base capability.

MCP transport versus knowledge authority: MCP names and invokes tools. The source and application still own permissions, provenance, and the conditions for accepting evidence.

Direct integration offers explicit query control and fewer orchestration layers. A managed knowledge base reduces repeated source-integration work but introduces its own configuration, source constraints, and optional planning. Choose the path whose ownership fits your system.

Architecture / decision scenario

A support platform needs manual search, policy retrieval, and live operational evidence. Its manual specialist uses AzureAISearchTool against one version-filtered index with a semantic-containing query_type. The agent generates the final technical explanation from returned source text and citations.

For questions spanning policy and manuals, the team evaluates a Foundry IQ knowledge base exposed through knowledge_base_retrieve. It explicitly chooses the preview connection path, restricts allowed_tools, and configures service identities and per-user authorization separately. If production requirements permit only stable retrieval, it uses the 2026-04-01 minimal extractive API with supported source types and keeps question decomposition in application code.

Live operational evidence comes from an MCP server. The team chooses whether the responsible specialist calls it directly or whether an approved preview MCP knowledge source brings it into the knowledge base. It does not configure both accidentally. The final evidence contract retains source identity and distinguishes generated explanations from extracted passages, so each integration supplies knowledge without obscuring who retrieved or authorized it.

Common exam traps

  • Treating Search, Foundry IQ, semantic ranker, and MCP as competing substitutes.
  • Assuming the direct Search tool automatically spans multiple indexes.
  • Copying REST query parameter names into agent tool configuration.
  • Calling extractive semantic answers generative answer synthesis.
  • Treating every knowledge source and portal-created object as stable API functionality.
  • Confusing a knowledge-base MCP endpoint with an MCP server knowledge source.
  • Using a service identity as a substitute for user content authorization.

What to remember

Choose the integration layer by who owns retrieval and synthesis. Connect a bounded index directly, use a knowledge base for reusable source orchestration, and treat semantic ranking as a retrieval stage. MCP exposes or supplies knowledge operations; it does not remove source permissions, evidence validation, or feature-specific preview constraints.

Knowledge check

References