New AI Tools: mu Gives Agents 67 Internet Tools From One Endpoint — No API Keys

If you have spent any time wiring up an agent this year, you know the real work is not the model. It is the plumbing: a search API key here, a weather provider there, an SMTP account, a storage bucket, four sets of rate limits and a billing dashboard for each. On 3 August, an open-source project called mu shipped a blunt answer to that problem — 67 real internet tools behind a single Model Context Protocol endpoint, with no API keys to collect and no per-service signup sprawl.

Among the new AI tools launched this week, mu is the one most likely to change how you scaffold an agent in 2026. Not because it is clever, but because it is boring in the right places: one Go binary, one endpoint, one bill, and the same tool catalog exposed to MCP clients, a CLI, a TypeScript SDK and chat bots at the same time.

What mu Actually Ships

mu comes from Micro, the team behind the Go Micro service framework. It is an MCP server that agents connect to at https://micro.mu/mcp, or that you run yourself from the open-source repository. The single most important design decision is what happens behind that endpoint.

Most agent tooling wraps third-party APIs. mu operates the underlying services itself. Its mail_inbox tool reads from a real SMTP inbox with DKIM signing. Its db_create tool writes to actual storage. Its web_search tool queries a search index mu maintains. That is why there are no keys to gather: there is no vendor chain to authenticate against, only mu.

Micro founder Asim Aslam framed the motivation directly: "We built mu because every agent project we saw spent 80% of its time wiring APIs and 20% on the agent. Mu flips that ratio."

The catalog, by category

• Web: search plus clean page fetching — the two calls almost every agent needs first.
• News: RSS aggregation with full article retrieval, not just headlines.
• Markets: crypto, futures, commodities and currencies.
• Weather: forecasts, current conditions and pollen data.
• Places: search, nearby lookup and travel-time estimates.
• Mail: real SMTP sending and receiving, with per-agent addresses.
• Storage and Files: per-caller key-value records plus upload, download and sharing via signed URLs.
• Calendar and Contacts: event creation, free-busy lookup, and name-to-address resolution.
• Search: a personal index across everything the instance holds for you.
• Images, Writing and Apps: generation and search, blog/social/stream publishing, and a sandbox for building small web tools.
• Money and Agent: wallet balance and USDC top-ups, plus a meta-tool that lets the agent compose multi-step answers.

Per-agent email addresses deserve a highlight. Giving an autonomous process its own real inbox turns a whole class of workflows — confirmations, notifications, human-in-the-loop replies — from a custom integration into one tool call. If you are building in this space, our AI agents and automation hub and our field report on how AI agents are quietly automating real work both cover why that matters more than raw model quality.

The Architecture Choice That Makes It Work

mu is built on a Go Micro service registry. Each capability registers a typed handler with a spec declaring its endpoints, documentation and wallet cost. That single declaration exposes the tool simultaneously to:

1. The MCP endpoint, for Claude Desktop, Cursor and other compatible clients.
2. The built-in agent and custom agents in the tool picker.
3. The mu CLI, where every tool is also a subcommand.
4. The TypeScript SDK via mu.service(name, method, args).

Add a tool to the registry and it appears in all four surfaces automatically. That is the kind of design detail that decides whether a project stays maintainable a year later, and it is a pattern worth stealing whatever tooling you use — see the AI for developers hub for more on agent scaffolding.

Identity is bound server-side

Security-wise, the most interesting line in mu's documentation is that identity is bound server-side from the call context. Callers never specify whose data they want, and no account field exists in requests to forge. That closes off a common and ugly failure mode in multi-tenant agent tooling, where a confused or manipulated model asks for someone else's inbox and the API happily obliges.

Authentication is standard-shaped: the first MCP call returns a 401 pointing at mu's authorization server, and compatible clients complete the OAuth flow automatically. For anything else, a Personal Access Token from /token works as a Bearer token. The web app additionally supports username/password, passkeys via WebAuthn, and Google sign-in.

Cost: Metered Per Call, Not Per Subscription

Because each tool's spec declares a wallet cost, mu meters usage per call rather than per seat or per service subscription. A wallet holds balance and accepts USDC top-ups; the live catalog with per-call costs is published at micro.mu/tools.

Two practical consequences. First, cost attribution becomes trivial — you can see which tool an agent is burning budget on without correlating five vendor invoices. Second, self-hosting changes the equation entirely: run your own instance and you supply your own provider keys through environment variables (YouTube, Brave Search, weather providers, mail/DKIM, OAuth), paying those vendors directly instead of mu. The hosted endpoint buys convenience; the self-hosted binary buys control. Our AI for business hub covers how to model that trade for a team budget.

Self-Hosting in Practice

Deployment is a single Docker Compose file, or go install if you prefer the binary. First-run setup walks through creating an admin account and picking an AI provider — Claude, Atlas Cloud/DeepSeek, or a local Ollama or OpenAI-compatible endpoint. Configuration lives in plain JSON files for feeds, prompts, home-screen cards, video channels and saved locations.

The same binary is both server (mu --serve) and CLI, which keeps the operational surface small. There is also a web app at the same endpoint for human operators, with cards for headlines, prices, weather and unread mail plus an inline agent that can act on what you are looking at, and Discord and Telegram bots exposing /agent, /news, /markets, /weather and /mail.

The licence matters

mu is licensed AGPL-3.0. Running a modified version as a service requires sharing your source. For internal use that is usually irrelevant; if you intend to build a commercial product on top of a forked mu, read the AGPL-3.0 text with your legal team before you start. This is the single most common way teams get surprised by an otherwise excellent open-source dependency.

Where the Sceptic Should Push

A single endpoint that operates its own mail server, search index and storage is a big claim. Four honest reservations:

• First-party services mean first-party quality ceilings. A self-maintained search index will not match a dedicated search vendor on coverage, and mu's own weather or places data has to be evaluated against what you use today — not assumed equivalent because the interface is nicer.
• Concentration risk is real. Consolidating 67 capabilities behind one dependency means one outage, one licence and one project's maintenance velocity now sit on your critical path.
• The prompt-injection surface is wide by design. An agent that can fetch arbitrary pages, read mail, write storage, send email and run sandboxed apps is the textbook dangerous combination. Untrusted content entering a loop with send and write capabilities needs explicit controls; map yours against the OWASP Top 10 for LLM Applications before granting mail or file scopes.
• Deployment carries the compliance obligation. Self-hosting does not remove governance duties — for EU-facing systems, obligations under the EU AI Act follow the deployer. Running the binary yourself moves responsibility toward you.

A One-Afternoon Evaluation Plan

mu is cheap to test, which is most of its appeal. Do it properly anyway.

1. Connect the hosted endpoint to one MCP client. Claude Desktop or Cursor handles OAuth automatically. Fifteen minutes, no keys, no commitment.
2. Replay three real tool calls. Pick calls your current agent already makes — a search, a page fetch, a data lookup — and compare result quality against your incumbent provider side by side. This is the step teams skip and later regret.
3. Test read-only first. Web, news, markets, weather. Grant mail, files and storage scopes only after you have seen how the agent behaves on untrusted input.
4. Then stand up the self-hosted instance. Time the Docker Compose setup, note what needed a provider key anyway, and record maintenance assumptions honestly.
5. Check the per-call costs against your volume. Metered pricing is excellent at pilot scale and needs modelling at production scale. Pull the catalog costs and multiply by your real call counts.
6. Decide on the licence before you fork. If a commercial product is the goal, settle AGPL implications now rather than after three sprints of work.

Who Should Actually Use This — and Who Should Not

Blanket recommendations are how teams end up with dependencies they resent. mu fits some situations very well and others badly.

Strong fit: prototypers and solo builders who need capability today and cannot justify a week of integration work; internal tools where the data is not sensitive and the value is in speed; teaching and demo environments, where "no API keys" removes the single biggest onboarding barrier; and self-hosted setups in organisations that already run their own infrastructure and want agent tooling inside the perimeter.

Poor fit: products whose core differentiator is search or data quality, because you will eventually want a specialist provider and a direct contract; regulated workloads that need per-vendor data processing agreements, since first-party consolidation makes that paperwork harder rather than easier; and commercial forks, where AGPL-3.0 obligations are a genuine constraint rather than a footnote.

The honest middle path most teams land on: prototype against mu, measure which three or four tools your agent actually leans on, then decide whether those specific calls deserve a dedicated vendor. Consolidation is a starting position, not a destination — and it is far cheaper to specialise later than to integrate forty services up front on a guess.

Why This Fits a Wider Pattern

mu is the second significant open-source, self-hostable agent-infrastructure release in as many weeks — the other being the Buzz workspace from Jack Dorsey's Block, where agents hold their own cryptographic identities. The common thread is that the interesting work has moved down the stack, away from models and toward the environment agents operate inside: identity, tool access, audit trails and cost attribution.

That shift also reflects how quickly model economics keep resetting, most recently with the Qwen3.8-Max open-weights release. When the model layer reprices every few weeks, the durable investment is portable infrastructure around it. MCP is becoming that portability layer, and mu is a bet that the tool catalog behind it should be one dependency instead of forty. Follow generative AI news for how that consolidation plays out.

The Bottom Line

mu will not out-search a dedicated search vendor or out-deliver a dedicated mail provider. That is not the pitch. The pitch is that you can hand an agent a genuinely useful slice of the internet in an afternoon, with no key collection, no signup queue and no rate-limit archaeology — then decide later, with evidence, which individual services deserve a specialist.

For anyone prototyping agents right now, that is close to the best available trade. Test it read-only this week, keep write scopes locked until you have watched it handle untrusted input, and read the licence before you fork. If you are still choosing the rest of the stack around it, start from our complete guide to the best AI tools and our honest review of AI coding tools.