What happened
Agno released version 3.1.9 on October 22. The principal new capability is an MCP Tool Runner on AgentOS: POST /mcp/server/tools/{tool_name}/run. The endpoint runs any tool listed in the AgentOS Server Card and returns that tool's result. Agno describes the purpose narrowly but usefully: a developer can test a tool without an MCP client. Deployments can turn off this endpoint with MCPConfig(tool_run_endpoint=False).
That distinction matters because MCP tools are ordinarily discovered and invoked through an MCP client and its transport. The new route creates a direct HTTP path for a named, published tool. It does not, from the release notes, claim to replace MCP or add a general mechanism for running arbitrary code. Its stated scope is tools listed on the AgentOS Server Card. Builders therefore have a more conventional way to exercise a server's exposed capability surface during development, debugging, or integration work.
The release also changes browser access to the AgentOS MCP server. The /mcp and /mcp/server-card routes now accept browser requests from origins permitted by the AgentOS CORS policy. Agno gives one intended result: os.agno.com can reach the MCP server of a local AgentOS instance. Separately, /info now reports the configured MCP path rather than always reporting /mcp.
Most remaining changes are fixes. Function workflows can use a function as their steps in more cases: the release says a function is run once when its body raises a TypeError, and synchronous functions and generators work with arun(). AgenticChunking no longer hangs on a zero or negative model breakpoint and requires max_chunk_size greater than zero. The release also fixes readable Chinese text in BaiduSearchTools output, handling of union-typed human-input tool parameters, Mistral client parameters, and a Postgres metrics refresh that had loaded a legacy column into memory.
For teams using AgentOS as an MCP server, the operational change is not merely a convenience URL. They now need to decide whether an HTTP route that executes published tools belongs in each environment, and ensure that their Server Card, CORS policy, and deployment boundary express the intended exposure.
What the archive adds
This is a new fact on a known Agno story. Now in Agno: stateless MCP serving. covered an earlier AgentOS configuration in which default tools could be served without transport sessions. Version 3.1.9 adds a separate direct HTTP execution path for tools advertised by that server, alongside browser-origin support.
Trend signal
The release supports Agent-ready software exposes capabilities. AgentOS is making its tool boundary more observable: a Server Card identifies the published tools, while a specific HTTP route can execute one by name. The accompanying opt-out and CORS behavior also show that an exposed capability requires explicit deployment controls, not just a discoverable description.
Why it matters
An MCP server is often easy to demonstrate through a compatible client but harder to inspect from ordinary engineering tooling. A direct HTTP runner can simplify smoke tests, diagnostic scripts, and integrations that need to verify a published tool's behavior without first assembling an MCP client flow. The Server Card constraint is important: teams can treat the advertised set as the intended callable surface rather than assuming every internal function should be reachable.
The same feature can widen the practical attack and governance surface if it is enabled without care. A route that executes tools over HTTP needs the same attention given to credentials, authorization, network reachability, input validation, and auditability as any other execution endpoint. CORS approval solves which browser origins may make requests; it does not by itself establish a complete authorization model. Local web access is valuable for iteration, but it should not blur the line between a developer workstation and a shared service.
Limits and uncertainty
The release notes establish that the endpoint runs tools listed in the AgentOS Server Card, can be disabled, and returns results. They do not describe its authentication behavior, authorization model, rate limits, request schema, logging, or whether production deployments should expose it beyond a development network. They also do not provide performance measurements or evidence that browser-origin access works across particular browser, proxy, or deployment configurations. The notes say CORS-allowed origins are admitted, but do not specify a recommended CORS policy. Teams should verify those properties in their own AgentOS configuration before treating the route as a production integration surface.
Skill to build now
Create a minimal AgentOS server with one non-destructive published tool and test the new runner from an HTTP client. Confirm that the tool appears in the Server Card, invoke POST /mcp/server/tools/{tool_name}/run, then disable the route with MCPConfig(tool_run_endpoint=False) and verify it is no longer reachable. Separately, test one allowed and one disallowed browser origin. Record the expected result as a deployment check, not only as a local demo.
Reader takeaway
Agno 3.1.9 makes an AgentOS-published MCP tool callable and testable through a named HTTP endpoint, while allowing approved browser origins to reach the MCP server. That can reduce integration friction, but it turns the published-tool list and the surrounding access controls into a more consequential product boundary.
Open question
What authentication, authorization, and audit controls does the HTTP Tool Runner apply in common AgentOS deployments, and how should they differ between local development and shared production environments?