Tools are where agents stop being chatbots and start being workers — and they are also where governance matters most. Before any agent invokes anything, someone has to decide which tool servers are allowed in the workspace at all. Botmanor makes that an explicit, managed step.
The MCP registry holds your workspace's Model Context Protocol connections. Register a server and Botmanor tracks its connection status, lets you run a connection test, and discovers the tools and resources it exposes. When the server's surface changes, refresh the catalogue to pick up new and removed tools.
That catalogue is the governance artefact. Instead of tool access being a side effect of whatever a developer pasted into a config file, your workspace has a reviewable list: these servers, these tools, this status. Policy definitions can classify tools by risk level — low, medium, high — so the conversation about "should the support bot be able to issue refunds" happens in the open.
To be clear about where the line is today: registered tools are not yet invoked inside the live chat loop — agent-side tool execution lands with the agent runtime upgrade, and Botmanor's reference agent stack (built on Google's Agent Development Kit and Agno) already demonstrates tool-using agents end-to-end. What you build now is the inventory and approval layer that runtime will obey.
Teams that treat the registry this way hit launch with a vetted tool surface instead of a scramble: the connections are tested, the catalogue is current, and the risky tools were flagged months before an agent could touch them.
Do it yourself
Stand up a governed registry of Model Context Protocol servers: register a server, test its connection, discover the tools and resources it exposes, and keep the catalogue current — the approval layer your agent runtime will obey.
From the Botmanor sidebar open MCP Servers to see your workspace’s registered connections.
You should see: The MCP registry loads with a button to register a new server.
Ready to make this your story?
