Open for Agents

Stories

Use Open for Agents with Microsoft Agent Framework

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.

Both examples connected over Streamable HTTP to a clean WordPress and WooCommerce test site running the public WordPress.org release. We called the tools directly, without a model, so the result measured the connection and tool contract rather than model behaviour.

The same examples were then checked against the live Open for Agents demo. Python and .NET discovered the same 22 reviewed read-only tools and successfully called representative site, post and product operations.

Python: inspect and call the reviewed tools

Install the 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 example calls the tools directly before adding a model. That makes it easier to confirm that the connection, discovery information and representative calls work as expected.

.NET: expose the MCP tools as Agent Framework functions

Install the 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.

Large results remain usable

Open for Agents limits large tool responses so an agent receives a useful first page rather than an oversized payload. In our product test, a 50-item response returned the first item, explained that more results were available and provided continuation information. The request still succeeded.

The live sample asks for six of the seven demo products and checks that the response stays within the published 1,500-character limit while pointing to the next page.

Requests that exceed the transport limit are rejected before execution. This is different from a successful tool response that has been shortened.

A mistaken call does not end the session

The Python and .NET examples also tested two common client mistakes:

  • Calling an unknown tool produced a clear error.
  • Sending invalid arguments to a known tool produced a clear tool error.

After each mistake, the same client session successfully called get_site_info. Clients should still handle each error explicitly rather than ignoring 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. We did not test that Agent Skills path here.

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.