Microsoft Agent Framework II: Tools, MCP, Memory, and RAG

Sat, 15 Aug 2026 00:00:00 +0000

Introduction

Part I created a single-turn agent that could understand a customer message and return a safe response. Real support work needs more: the agent must read trusted business data, find the right support policy, and remember the conversation without inventing facts.

This article adds those capabilities with Microsoft Agent Framework. We will build a support agent that can look up an order and search a small Qdrant vector database. The sample keeps both tools read-only and uses local Ollama embeddings so it is easy to run and understand.

Real-World Scenario: A Pending Payment

A customer says:

My order ORD-1001 failed twice, but I see a pending charge. Is my order confirmed?

A model alone cannot know the order status or the company’s pending-charge policy. The agent needs two controlled sources:

GetOrderStatus reads the order system.
SearchSupportKnowledge retrieves approved support guidance.

The model decides which tool is useful, but the application owns the tool implementation and its authorization boundary.

flowchart LR C((Customer question)) --> A{{Support agent}} A -->|order status| O[[GetOrderStatus tool]] A -->|support policy| K[[SearchSupportKnowledge tool]] O --> D[(Order data)] K --> KB[(Support knowledge base)] D --> A KB --> A A --> R([Grounded response]) R --> C classDef customer fill:#fef3c7,stroke:#d97706,stroke-width:2px,color:#78350f classDef agent fill:#dbeafe,stroke:#2563eb,stroke-width:2px,color:#1e3a8a classDef tool fill:#cffafe,stroke:#0891b2,stroke-width:2px,color:#164e63 classDef data fill:#dcfce7,stroke:#16a34a,stroke-width:2px,color:#14532d classDef response fill:#fce7f3,stroke:#db2777,stroke-width:2px,color:#831843 class C customer class A agent class O,K tool class D,KB data class R response

1. Function Tools: Let the Agent Read Business Data

What problem do tools solve?

The model understands language, but it does not automatically know the current state of an order, account, or payment. A function tool gives it a controlled way to ask the application for that information.

For the pending-payment case, the agent extracts ORD-1001 and calls get_order_status. The application reads the order system and returns Payment review and Pending charge. The model explains those facts; it does not invent them.

Customer: Is ORD-1001 confirmed?
Agent:    Call get_order_status(orderId = "ORD-1001")
System:   { status: "Payment review", paymentStatus: "Pending charge" }
Agent:    Your order is not confirmed yet. The payment is still pending.

How is a function tool built?

A function tool is a typed application function exposed to the agent. Its name, description, and parameter schema help the model decide when to request it. The function itself remains normal application code:

1
2
3

AIFunction orderTool = AIFunctionFactory.Create(
  (string orderId) => orderStore.GetOrderStatus(orderId),
  "get_order_status");

Use narrow inputs, validate arguments, return predictable data, and start with read-only tools. A create_refund tool would need authorization, idempotency, and human approval because it changes business state. Tool descriptions guide selection, but the host remains responsible for security.

What problem does MCP solve?

Suppose the company already owns a payment-support service used by its web portal, call-center application, and several agents. Copying its tool code into every agent creates duplicated integrations. The Model Context Protocol (MCP) gives that service a standard way to publish tools that different hosts can discover and call.

For the same customer question, the flow can become:

Agent host -> MCP client -> Payment MCP server -> Payment system
                   |
                   +--> get_order_status

The agent still decides that order status is needed. The MCP server owns connection details, authorization, and the actual call to the payment system. MCP changes where the capability lives and how it is discovered; it does not replace the agent, conversation memory, or RAG.

Local function tool versus MCP tool

Boundary	Function tool	MCP tool
Tool owner	Same application process	Separate MCP server
Discovery	Registered in application code	Discovered through MCP
Transport	In-process call	Stdio or HTTP
Reuse	Mainly one host	Many hosts and agents
Security	Host authorization	Server authorization plus host policy

A .NET host can discover MCP tools and pass them to an agent or chat client:

await using var mcpClient = await McpClient.CreateAsync(
  new StdioClientTransport(new()
  {
    Name = "payment-support",
    Command = "dotnet",
    Arguments = ["run", "--project", "PaymentSupport.McpServer"]
  }));

var tools = await mcpClient.ListToolsAsync();

The Part II sample runs both tools in a local SupportMcpServer over stdio. The API discovers them at startup, so you can see the MCP boundary without deploying a remote service. In production, treat every discovered MCP tool as untrusted until the host applies an allow-list and authorization policy.

3. Conversation Memory: Continue the Case

What problem does memory solve?

Without conversation memory, every HTTP request looks like a new conversation. A customer would need to repeat the order number and the entire problem on every message.

Example:

Message 1: My order ORD-1001 failed twice, but I see a pending charge. Agent: ORD-1001 is in payment review and has a pending charge.

Message 2: Should I try payment again? Agent: No. Based on the same case and policy, avoid repeated attempts.

The API sends a sessionId with both requests. The runtime maps that ID to an AgentSession, so the framework preserves previous messages and tool results:

if (!_sessions.TryGetValue(sessionId, out var session))
{
  session = await agent.CreateSessionAsync(cancellationToken);
  _sessions[sessionId] = session;
}

var response = await agent.RunAsync(prompt, session,
  cancellationToken: cancellationToken);

This is conversation memory, not a customer profile database. Long-term memory would store durable facts such as a preferred language or verified account identifier and would require its own identity, consent, retention, and access controls. The sample stores sessions in process for teaching; production APIs need durable, tenant-aware session storage.

4. RAG with Qdrant: Retrieve Approved Policy

What problem does RAG solve?

The order tool tells us what happened to ORD-1001; it does not tell us what company policy says about pending card authorizations. RAG retrieves the relevant policy passage and gives it to the model as evidence.

For this case, the retrieval flow is:

Question: "I see a pending charge. Is my order confirmed?"
  |
  v
Create query embedding -> Search Qdrant -> Select support passage
  |
  v
Model uses passage: "Pending card charges can be temporary authorization holds..."

RAG has two distinct stages:

Indexing: split documents into passages, create embeddings, and store vectors plus source metadata.
Retrieval: embed the user question, search the vector database, apply access filters and a similarity threshold, then provide selected passages to the model.

The sample uses Qdrant for vector storage and search, and Ollama runs the local nomic-embed-text model to create 768-dimensional embeddings. This avoids requiring a second paid API while still using real semantic embeddings. The sample seeds one approved pending-charge passage when the collection is first used.

var results = await qdrant.QueryAsync(
  "support-knowledge",
  query: Embed(query),
  limit: 1,
  cancellationToken: cancellationToken);

return results.Count == 0 || results[0].Score < 0.15
  ? "No matching support guidance was found."
  : results[0].Payload["text"].StringValue;

RAG is not simply “put documents in the prompt.” Retrieved text is evidence, not permission. Filter by tenant and user access, retain source metadata, defend against prompt injection in documents, and do not let retrieved text override application rules.

%%{init: {"flowchart": {"nodeSpacing": 12, "rankSpacing": 22}, "themeVariables": {"fontSize": "12px"}}}%% flowchart LR Q((Question)) --> E[Embed and search] E --> F[Filter approved evidence] F --> M((Model)) M --> R([Grounded answer]) classDef question fill:#fef3c7,stroke:#d97706,stroke-width:2px,color:#78350f classDef search fill:#cffafe,stroke:#0891b2,stroke-width:2px,color:#164e63 classDef model fill:#dbeafe,stroke:#2563eb,stroke-width:2px,color:#1e3a8a classDef answer fill:#dcfce7,stroke:#16a34a,stroke-width:2px,color:#14532d class Q question class E,F search class M model class R answer

Connect the Agent to MCP Tools

The sample discovers both tools from SupportMcpServer and passes them to AsAIAgent:

await using var mcpClient = await McpClient.CreateAsync(
  new StdioClientTransport(new()
  {
    Name = "support-tools",
    Command = "dotnet",
    Arguments = ["run", "--project", "SupportMcpServer/SupportMcpServer.csproj"]
  }));

var tools = await mcpClient.ListToolsAsync();

AIAgent agent = chatClient.AsAIAgent(
    instructions: "You are a support assistant. Use tools for order facts and policy. " +
        "Never invent an order status or claim an action was completed.",
    tools: [.. tools]);

The model may call one or both MCP tools before producing its answer. search_support_knowledge calls Ollama for an embedding and Qdrant for the matching policy passage. Tool execution should be observable and bounded. Validate orderId, limit query length, set timeouts, and return safe errors rather than leaking internal exceptions.

The Sample Application

The sample is an expanded version of Part I:

AgentTools creates the agent and exposes AgentRuntime.
AgentTools.Api hosts the HTTP endpoint.
OrderStore contains deterministic order data for ORD-1001.
QdrantSupportKnowledgeBase stores and retrieves approved pending-charge guidance.
AgentSessionStore keeps the conversation session in memory.

The endpoint accepts a session ID so the customer can ask a follow-up question:

{
  "sessionId": "case-1001",
  "prompt": "My order ORD-1001 failed twice, but I see a pending charge. Is my order confirmed?"
}

The first request can use tools to answer the question. A second request with the same session ID can ask:

You:

What should I do next, and should I try payment again?

The session preserves the conversation. The order tool and knowledge tool provide facts; the model turns those facts into a customer-facing answer.

Run the Sample

Prerequisites

Install the .NET 10 SDK and Docker Desktop with Docker Compose. You also need a DeepSeek API key. Compose starts Qdrant and Ollama locally and downloads the nomic-embed-text embedding model on first startup, so allow time, network access, and local disk space for the initial download.

From the sample directory:

$env:DS_KEY = "<your-deepseek-api-key>"
docker compose up -d
$env:QDRANT_URL = "http://localhost:6334"
$env:EMBEDDING_URL = "http://localhost:11500"
$env:EMBEDDING_MODEL = "nomic-embed-text"
dotnet run --project AgentTools.Api

Send the real-world request:

1
2
3

curl -X POST http://localhost:5000/api/agent/chat \
  -H "Content-Type: application/json" \
  -d '{"sessionId":"case-1001","prompt":"My order ORD-1001 failed twice, but I see a pending charge. Is my order confirmed?"}'

The response includes the session ID and generated answer. Send another request with case-1001 to continue the conversation.

The order data and seeded Qdrant passage make the sample reproducible at the application boundary. Compose starts Qdrant and Ollama, then pulls nomic-embed-text automatically. The generated wording still varies by model provider. When QDRANT_URL is omitted, the sample uses its in-memory fallback so the API and tests can run without Docker.

Testing Strategy

Unit tests verify deterministic order and retrieval behavior. Integration tests run the real API, MCP server, DeepSeek agent, Ollama embedding service, and Qdrant database. The live scenario sends the pending-payment question, verifies the response contains the known order and pending-payment facts, sends a follow-up with the same session ID, and verifies that the agent uses conversation memory to answer the retry question.

`1`	`dotnet test --solution agent-tools-mcp-rag-sample.slnx --no-restore`

The live-provider fixture loads DS_KEY automatically. It is skipped when the key is unavailable.

Production Considerations

The order store and local embedding setup are educational. Production systems should add:

A managed embedding service or secured local embedding deployment.
A managed or containerized Qdrant deployment with backups and collection-level access control.
Durable, tenant-aware session storage.
Authentication and authorization for every session and tool call.
Tool timeouts, retries, idempotency, and audit logs.
Access-controlled retrieval with source metadata and citations.
Prompt-injection defenses for documents, MCP servers, and tool results.
Token, latency, and cost limits.

Conclusion

Tools give agents controlled access to application behavior. MCP provides a standard boundary for tools owned by another process or service. Memory preserves conversation state, while RAG supplies relevant external knowledge for the current question.

Together, these capabilities turn the Part I chat agent into a useful support assistant without giving the model unrestricted access to business systems. The next article adds Agent Harness, planning, context management, and approval-oriented execution.

Run the Complete Example

The complete runnable sample contains the API, MCP server, Qdrant setup, Ollama embedding service, DeepSeek integration, and tests for the two-turn support scenario:

https://github.com/meysamhadeli/blog-samples/tree/main/src/agent-tools-mcp-rag-sample

Function Tools on dotnetuniversity

Microsoft Agent Framework II: Tools, MCP, Memory, and RAG

Introduction

Real-World Scenario: A Pending Payment

1. Function Tools: Let the Agent Read Business Data

What problem do tools solve?

How is a function tool built?

What problem does MCP solve?

Local function tool versus MCP tool

3. Conversation Memory: Continue the Case

What problem does memory solve?

4. RAG with Qdrant: Retrieve Approved Policy

What problem does RAG solve?

Connect the Agent to MCP Tools

The Sample Application

Run the Sample

Prerequisites

Testing Strategy

Production Considerations

Conclusion

Run the Complete Example

Reference

Function Tools on dotnetuniversity

Microsoft Agent Framework II: Tools, MCP, Memory, and RAG

Introduction

Real-World Scenario: A Pending Payment

1. Function Tools: Let the Agent Read Business Data

What problem do tools solve?

How is a function tool built?

2. MCP: Share Tools Across Applications

What problem does MCP solve?

Local function tool versus MCP tool

3. Conversation Memory: Continue the Case

What problem does memory solve?

4. RAG with Qdrant: Retrieve Approved Policy

What problem does RAG solve?

Connect the Agent to MCP Tools

The Sample Application

Run the Sample

Prerequisites

Testing Strategy

Production Considerations

Conclusion

Run the Complete Example

Reference