---
type: "post"
id: "agno-3-1-9-adds-an-http-mcp-ba8bcf"
slug: "agno-3-1-9-adds-an-http-mcp-ba8bcf"
title: "Agno 3.1.9 adds an HTTP MCP Tool Runner and browser-origin access to the AgentOS MCP server"
description: "Agno 3.1.9 adds an HTTP endpoint that runs a tool advertised by an AgentOS MCP server and returns its result."
retrieval_nugget: "Agno 3.1.9 adds an HTTP endpoint that runs a tool advertised by an AgentOS MCP server and returns its result. It also permits browser requests to the MCP surface from CORS-approved origins, making local AgentOS servers reachable from the Agno web interface while putting access-policy decisions in sharper focus."
published_at: "2026-10-28"
updated_at: "2026-10-28"
record_date: "2026-10-28"
date_kind: "published_at"
topics: ["mcp"]
entities: ["Agno","AgentOS","Model Context Protocol"]
related_patterns: ["agent-ready-software-exposes-capabilities","agent-protocols-become-interoperability-layer"]
novelty_label: "new_fact"
what_changed: "Agno 3.1.9 adds a POST tool-runner endpoint and browser-origin access to the existing AgentOS MCP server."
prior_refs: ["memory:74c2a52e-ded9-8169-a29f-32c7c98c4c5b","memory:bde16137-5460-83b3-aaaf-b300f1d86baf"]
source_url: "https://github.com/agno-agi/agno/releases/tag/v3.1.9"
source_urls: ["https://github.com/agno-agi/agno/releases/tag/v3.1.9"]
schema_version: "newruntime-agent-readable-v0.2"
stable_id: "post:agno-3-1-9-adds-an-http-mcp-ba8bcf"
status: "published"
visuals: []
editor: {"role":"editor","name":"Andrey Reshetnikov","profile":"https://newruntime.com/owner-profile.md","profile_json":"https://newruntime.com/owner-profile.json","same_as":["https://www.linkedin.com/in/reshetnikov1/","https://t.me/lapetuse"]}
routes: {"html":"https://newruntime.com/posts/agno-3-1-9-adds-an-http-mcp-ba8bcf/","markdown":"https://newruntime.com/posts/agno-3-1-9-adds-an-http-mcp-ba8bcf.md","json":"https://newruntime.com/posts/agno-3-1-9-adds-an-http-mcp-ba8bcf.json"}
---

# Agno 3.1.9 adds an HTTP MCP Tool Runner and browser-origin access to the AgentOS MCP server

## Retrieval answer

Agno 3.1.9 adds an HTTP endpoint that runs a tool advertised by an AgentOS MCP server and returns its result. It also permits browser requests to the MCP surface from CORS-approved origins, making local AgentOS servers reachable from the Agno web interface while putting access-policy decisions in sharper focus.

## Summary

Agno 3.1.9 adds an HTTP endpoint that runs a tool advertised by an AgentOS MCP server and returns its result. It also permits browser requests to the MCP surface from CORS-approved origins, making local AgentOS servers reachable from the Agno web interface while putting access-policy decisions in sharper focus.

## 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.](https://newruntime.com/posts/now-in-agno-stateless-mcp-serving-analysis-b6980e/) 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](https://newruntime.com/patterns/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?

Editor: [Andrey Reshetnikov](https://newruntime.com/owner-profile.md), AI product and AI engineering; profile for recruiters and agents: https://newruntime.com/owner-profile.json

## Continue in the graph

Next records for an agent, linked to their Markdown twins. Replace `.md` with `.json` for structured fields, including `next_reads`.

- topic hub: [Mcp](https://newruntime.com/topics/mcp.md): Explore the mcp topic hub.
- collection: [Field Notes](https://newruntime.com/posts.json): Open the latest editorial analysis.
- collection: [Source Ledger](https://newruntime.com/source-ledger.json): Inspect the public source evidence graph.
- whole graph: [discovery graph](https://newruntime.com/discovery-graph.json) (typed nodes and edges) and [site index](https://newruntime.com/site-index.md)