Open for Agents logoOpen for Agents

Stories

Use Open for Agents with Microsoft Agent Framework

28 July 2026 by Open for Agents

Microsoft Agent Framework runs the agent. Open for Agents lets the website owner govern the site knowledge and capabilities that agent can use.

The two projects therefore have complementary jobs:

  • Microsoft Agent Framework supplies the agent runtime, model integration, orchestration, and tool-calling loop.
  • Open for Agents Core lets a WordPress owner discover, review, publish, and validate the site capabilities exposed through MCP.
  • MCP carries the reviewed tool definitions, typed inputs, annotations, calls, and structured results between them.

This is an interoperability path, not a Microsoft partnership, endorsement, Foundry certification, or claim of universal compatibility.

What we tested

On 28 July 2026, we tested Open for Agents Core 0.3.29 against:

  • Python 3.13.14, agent-framework-core 1.12.1, and mcp 1.28.1.
  • .NET 10.0.10, Microsoft.Agents.AI 1.15.0, and ModelContextProtocol 1.4.1.

The approved release candidate was source commit b42f2d6bce9fa2f0e0be6c9c3e1b2f9afacfdcf4. Its WordPress.org-format ZIP had SHA-256 9cfa83eabff0169bcc0e5c4245a6b44b2401864ab1563304b39eed77a2d5f418. The public WordPress.org ZIP has SHA-256 58110622a561d29132c1fadc6679bd2de3eeed7a930202f84ff1b69881a6fca4; its 342 extracted files are byte-identical to the approved candidate.

Both clients connected over Streamable HTTP to a disposable WordPress and WooCommerce fixture loaded from that exact ZIP. No model or model-provider call was made.

The disposable exact-artifact fixture exposed ten coherent read-only tools. A separate final run of the samples against the live demo returned 22 read-only, closed-world tools in both clients. The live catalog had SHA-256 335a00fbb9d4d69a39e5e875827e298156a4918d54c532925c3a28bf926c33f0.

Python: inspect and call the reviewed tools

Install the exact tested packages:

python -m pip install \
  agent-framework-core==1.12.1 \
  mcp==1.28.1

MCP_ENDPOINT=https://your-site.example/mcp python probe.py

The complete public sample is probe.py, with its pinned requirements.txt. Its core flow is:

async with MCPStreamableHTTPTool(
    name="open-for-agents",
    url=endpoint,
    load_tools=True,
    load_prompts=False,
) as mcp_tool:
    listed = await mcp_tool.session.list_tools()

    for tool in listed.tools:
        assert tool.annotations.readOnlyHint is True
        assert tool.annotations.openWorldHint is False

    site = await mcp_tool.session.call_tool("get_site_info", {})
    posts = await mcp_tool.session.call_tool("list_posts", {"per_page": 3})
    products = await mcp_tool.session.call_tool(
        "woo_search_products",
        {"per_page": 3},
    )

This is deliberately model-free. It proves the transport, discovery metadata, and representative calls before an agent or model is introduced.

.NET: expose the MCP tools as Agent Framework functions

Install the exact tested packages:

<PackageReference Include="Microsoft.Agents.AI" Version="1.15.0" />
<PackageReference Include="ModelContextProtocol" Version="1.4.1" />

Then run the sample with the site endpoint:

MCP_ENDPOINT=https://your-site.example/mcp dotnet run

The complete public sample is Program.cs, with its pinned Probe.csproj. Its core flow is:

await using McpClient client = await McpClient.CreateAsync(transport);
IList<McpClientTool> tools = await client.ListToolsAsync();

foreach (McpClientTool tool in tools)
{
    Tool protocolTool = tool.ProtocolTool;
    if (protocolTool.Annotations?.ReadOnlyHint != true ||
        protocolTool.Annotations?.OpenWorldHint != false ||
        tool is not AIFunction)
    {
        throw new InvalidOperationException($"Unexpected tool: {tool.Name}");
    }
}

CallToolResult site = await client.CallToolAsync("get_site_info");
CallToolResult posts = await client.CallToolAsync(
    "list_posts",
    new Dictionary<string, object?> { ["per_page"] = 3 });

Microsoft documents this same architectural handoff: the official MCP C# SDK retrieves MCP tools, and Agent Framework can use them as AIFunction instances.

Bounded results remain ordinary successful results

Open for Agents bounds published tool output rather than returning an unbounded response to the client. In the exact-artifact test, a product query generated 39,224 characters across 50 original items. Core returned:

  • HTTP 200 and isError: false.
  • A projection capped by max_chars: 1500.
  • One returned item and 49 omitted items.
  • A continuation pointing to page 2.

The live samples request six products from the seven-product demo catalog and fail unless the response remains successful, reports reason: "output_budget", retains the 1,500-character projection contract, and points to the continuation page. This is separate from the 50-item disposable-fixture proof above.

The transport limit is separate. A genuine request body over the 65,536-byte limit returned HTTP 413 with JSON-RPC code -32003. That is a rejected request, not an ordinary tool result.

Errors do not have to poison the session

The exact Python and .NET probes also tested two recoverable client mistakes:

  • An unknown tool returned HTTP 200 with JSON-RPC -32602.
  • Invalid arguments for a known tool returned HTTP 200 with CallToolResult.isError: true.

After each failure, the same client session successfully called get_site_info. Clients should still handle each error explicitly; recovery evidence is not permission to ignore validation failures.

Security and approval boundaries

Tool annotations help a trusted client understand intent, but the MCP specification treats annotations as hints rather than enforcement. They do not replace authentication, authorization, server-side validation, least privilege, logging, or human approval.

This tested MCP surface is read-only. It does not claim write-capable MCP. If a future reviewed operation can change the site, standing approval in an Agent Framework harness must not replace Open for Agents' operation-specific approval and server-side policy.

The Open for Agents Assistant and hosted Gateway are separate products and are not part of this direct Microsoft Agent Framework-to-Core MCP connection.

Agent Skills are a separate path

Microsoft Agent Framework has separate, experimental MCP-based Agent Skills support. This interoperability test did not exercise direct skill:// discovery, MCPSkillsSource, skill archives, or skill execution. Direct Agent Skills support remains outside this article's tested scope.

Primary sources

Install Open for Agents Core 0.3.29 from WordPress.org or read the integration documentation before connecting a client to a site you operate.