AINEWS
The open source project runs its own mail server, search index, and storage, so an agent's mail inbox and db create calls hit a real instance rather than a third party API.
Most "agent tools" are thin skin over someone else's API. A self-hosted Go binary called Mu takes a different route: it runs the mail server, the feed aggregator, the search index, and the storage itself, so when an agent calls mail_inbox or db_create, it is hitting a real instance rather than proxying a third-party product.
The project, which surfaced on Hacker News as a Show HN, ships a single Go binary under AGPL-3.0 that exposes 67 tools to any agent that speaks the open Model Context Protocol (MCP) standard. The same binary powers a hosted instance at micro.mu and can be self-hosted on a single machine. The product is the same either way: a small set of internet primitives (mail, news, markets, weather, places, video, calendar, contacts, files, storage) plus a human-facing web app that uses the same underlying state.
The architectural thesis the project owner calls "real tools, not wrappers" is the part worth unpacking. Where most MCP toolkits in the wild re-export calls to a public SaaS (search that hits Bing, email that reads Gmail, storage that writes to S3) Mu runs the equivalent services on the operator's hardware. Outbound mail goes through an SMTP server with DKIM signing. News comes from a feed aggregator the project maintains. Search is a local index. db_create writes to storage the operator controls, not a managed cloud. What changes is not what the agent can ask for; it is where the bytes live when it asks.
That design also makes the project dual-audience in a way most agent toolkits are not. The same Go binary serves the human operator (a web app at the instance URL) and the agent (an MCP endpoint at the same host). A record the agent writes through db_create shows up in the web app; a message the human reads in the inbox is the same message the agent would surface. The shared state is the point: the project is selling one product that is useful to both audiences, not a developer platform with a thin consumer front end.
Authorization follows the MCP spec rather than the API-key convention. The first call to the endpoint returns a 401 that points the client at the instance's authorization server; the client walks the user through sign-in and stores the token. There is no key to paste into a config file. Clients that do not speak the authorization flow (older MCP clients, ad-hoc scripts) can use a Personal Access Token minted at /token. Claude Desktop and Cursor both speak the standard, and the project ships configuration snippets for both.
The credits model maps cleanly to the architecture. Only calls that cost the operator money (paid model calls, paid third-party APIs) draw from a balance the caller has prepaid; everything else is included. Per-tool costs are listed at micro.mu/tools, so a user can price a workflow before running it. For self-hosted deployments, that line is essentially zero, which is part of why the project bothers to ship a single Go binary instead of a managed service.
The Hacker News thread is light on technical pushback and heavy on the open question of who the audience is. Commenters framed MCP releases as "shared essays" rather than finished products: useful as a reference, less convincing as something a real team would deploy. One thread that recurred was whether root agents.md files (the markdown documents that describe how a given agent uses the toolkit) should stay human-authored. The project owner's position, echoed by several commenters, is that they should, because the configuration is the policy and the policy should read like prose.
The test for Mu is the same test that faces every MCP toolset right now: which of the 67 tools are useful in a normal session, and which only exist because the surface area was cheap to grow. The wrapper pattern survives in part because most agents only need a handful of tools in any given run. A self-hosted toolkit has to clear a higher bar (the operator is paying the maintenance, not a third party) and the project's bet is that the dual-audience design, the credits model, and the no-API-key authorization flow are enough to clear it. The next few months of Show HN submissions will tell.