Meta Muse Builds Its Own Tools: Here It Does Not Have To
Muse writes a connector for anything with an API. One spec of 38 paths and 42 operations means it writes one connector instead of two thousand.
Copy this line into Muse to give it a tool catalog.
read https://monid.ai/openapi.json and use POST /v1/run with my Monid key from secrets
Meta's page for Muse makes a promise most agents cannot: if a task needs a tool that does not exist, it will build the tool. That is genuinely impressive the first time and it does not scale, because building a connector per service means building a connector per service. On 2026-09-24 we checked what Muse would have to read to reach a whole catalog instead: one spec, 310,140 bytes, 38 paths, 42 operations, one bearer key. Muse writes one connector and gets the shelf. This guide runs through Monid, the OpenRouter for agent tools.
What does Muse mean by building its own tools?
Exactly what it says, and the mechanism matters more than the claim.
Meta's own words
Their feature copy reads: "Works with your apps and builds its own tools. Connect your email, calendar, Instagram and more apps you use daily. If a task needs a tool that doesn't exist, Muse builds it for you." That is quoted from their page as read on 2026-09-24, and everything in this section is their description rather than our measurement.
Why it can do that
Muse runs on what Meta calls a Secure VM: a persistent isolated Linux box with a full browser. An agent with a real machine and a real network stack does not need anybody to ship it an integration. It can read a specification, write the client, and make the call.
That is also why there is nothing for a provider to build. We did not write a Muse connector, and there is no Muse plugin to install. The agent does the work on its side.
The part that does not scale
A connector per service is a fixed cost per service. Two thousand services is two thousand costs, paid in agent time, in errors, and in the user waiting. The interesting question is not whether Muse can write a connector. It is how many it has to write.
Which is the whole point of this page
One. The next section is the arithmetic.
Why does one spec beat two thousand connectors?
Because the catalog sits behind one interface, so the connector count stops depending on the tool count.
What we verified
https://monid.ai/openapi.json, fetched 2026-09-24:
http 200 310,140 bytes (303 KiB)
openapi 3.1.0
info.title Monid API info.version 0.1.0
paths 38 operations 42
servers api.monid.ai (Production)
monid.ai (Public registry alias, public/v1 only)
securitySchemes Bearer -> http / bearer
"Monid API key (Authorization: Bearer mk_...) or Clerk-issued JWT."
Three things an agent needs in order to write a client once: a public REST surface it can reach from a browser box, a machine-readable spec it can generate code from, and an auth scheme that is a single header rather than an OAuth dance.
Why 3.1.0 matters
It is the version with full JSON Schema alignment, which is what a code-writing agent actually consumes. A spec an agent can read without special-casing is the difference between "it built a connector" and "it built a connector that works on the second endpoint too".
Why you point at the URL rather than paste it
303 kibibytes is a lot of context to spend on a schema. Handing Muse the URL lets it fetch and read the parts it needs, which is what a machine with a browser is for. Pasting a spec into a chat window spends the budget you wanted for the task.
The honest limit of the claim
We are not claiming Muse is missing anything. It builds connectors, and it built this one. What changes is the exponent: one connector for a catalog against one connector per service. That is the same argument as one MCP server for every tool, made to an agent that does not use MCP at all.
How do you point Muse at Monid?
Three steps, and the second one is the one people get wrong.
Step 1. Get a key
Grab one at app.monid.ai. It looks like mk_... and it goes in a header.
Step 2. Put the key in the Secrets tab, never in the chat
Muse has a place for credentials. Use it. A key pasted into a conversation is a key in a transcript, and Meta's own store hands the agent a stand-in token rather than the literal value when you do it properly. Grant the standing site permission once and the agent has what it needs for every later task.
This is the step to be strict about. Everything else here is convenience; this one is the difference between a credential in a vault and a credential in a chat log.
Step 3. Give it the spec and the verb
read https://monid.ai/openapi.json
then use POST /v1/run with my Monid key from secrets
From there Muse can discover what exists, inspect one endpoint's schema, and run it. Those are the three verbs and they are covered in the next section.
What it looks like when it works
We tested this ourselves on 2026-09-24 and Muse drove the API without help. That is our own test rather than a vendor claim, and it is the premise of this page rather than a benchmark.
Give this to your agent
Set up https://monid.ai/SKILL.md, and then use Monid to read https://monid.ai/openapi.json, then discover which endpoints can look up a company from its domain, inspect the most promising one, and run it for these five domains using my Monid key from secrets.📖 See also Give Your Agent Live Web Context
Which four paths actually matter?
Four of the thirty-eight, and the other thirty-four are plumbing.
The working set
/v1/discover find endpoints by what you need, not by vendor name
/v1/inspect read one endpoint's schema, pricing and health
/v1/run execute it
/v1/runs poll a long one, or read a receipt afterwards
That is the whole loop: ask what exists, ask how to call it, call it, collect the result. An agent that learns those four has the catalog.
What the rest are for
/v1/auth/whoami and /v1/auth/workspaces tell the agent which identity and workspace it is operating as, which matters when a key belongs to a team. /v1/discover/endpoints, /v1/discover/categories and /v1/discover/providers are narrower views of the same registry for when the agent wants to browse rather than search. /v1/endpoints is the full listing. The remainder are housekeeping.
Why discover comes first and why it is free
Because the alternative is the agent guessing a vendor name. Discovery and inspection cost nothing, and only running costs money, which is the property that makes an exploratory agent affordable. An agent that inspects before it runs does not pay for a call with the wrong parameter names, and getting parameter names wrong is the single most common thing we measure going wrong.
The two servers, and which one to use
The spec lists api.monid.ai as production and monid.ai as a public registry alias limited to the public read paths. Point the agent at the production host for anything that runs, and treat the alias as the place a spec and a registry live.
Which endpoint should I use for which job?
| Path | What it does | Input | Output | Best for | Billing |
|---|---|---|---|---|---|
POST /v1/discover | Find endpoints by capability | A description of the need | Matching endpoints with prices and health | The agent's first move | Free |
POST /v1/inspect | One endpoint's contract | Provider and endpoint | Schema, pricing shape, health | Before every first call | Free |
POST /v1/run | Execute an endpoint | Provider, endpoint, input | Result, or a run id | The only paid step | Per the endpoint |
GET /v1/runs/{id} | Poll or audit | Run id | Status, result, receipt | Long jobs and after the fact | Free |
GET /v1/auth/whoami | Identity check | None | Caller and workspace | Confirming which key is loaded | Free |
Verified against monid.ai/openapi.json on 2026-09-24. Pricing per endpoint lives on monid.ai/tools, because the run price depends entirely on which tool you ran.
Four of those five are free. The one that charges is the one that does the work.
When should Muse build its own connector instead?
Four cases, and they are real.
The service is one you use constantly. If your whole job is one CRM, a dedicated connector to that CRM will always be better than a generic route to it. Depth beats breadth when the breadth is one.
There is no public spec. The reason this works is a readable OpenAPI document. Against a service with no spec, Muse is reverse-engineering, and that is where connector-building gets fragile regardless of who does it.
Auth is not a header. An OAuth flow with a redirect is not something an agent completes on its own. Services in that shape need a real integration, built by somebody, once.
The task is genuinely local. Reading your calendar, moving a file, filling a form in the browser. Muse has a machine and a browser for exactly this, and routing it through an API would be worse.
And the disclosure: this is Monid's blog. The honest version of our pitch to a Muse user is arithmetic rather than capability, because Muse can already do the thing. One connector against one per service is the whole claim, and if you only ever need one tool then you do not need us.
Conclusion
Muse promising to build its own tools is a real capability and it has a scaling problem hiding inside it, which is that a connector per service costs per service. On 2026-09-24 the alternative measured out as one document: 310,140 bytes of OpenAPI 3.1.0, 38 paths, 42 operations, one bearer header, two named servers, and four paths that do the entire job of finding a tool, reading its contract, running it and collecting the receipt.
What matters more than the spec is where the key goes. Put it in the Secrets tab and grant the site permission once; a key pasted into a chat is a key in a transcript, and that is the only step here with a cost if you get it wrong. After that, hand the agent the URL rather than the file, because three hundred kibibytes of schema is context you would rather spend on the task.
Free next step: give Muse the spec URL and ask it to run POST /v1/discover for a capability you need. Discovery and inspection cost nothing, so the whole exploration is free and only the tool you choose to run is billed. Start at monid.ai.
FAQ
Is this an official Muse integration?
No, and there is nothing to make official. Muse reads a public OpenAPI document and writes its own client on its own machine, so there is no plugin to install, no listing to appear in and no work on our side. That is a consequence of how Muse is built rather than a gap: an agent with a browser and a network stack does not need providers to ship it integrations. What we did is verify that the three prerequisites are in place, a reachable REST surface, a 3.1.0 spec, and bearer auth, and then confirm by hand that it drives the API.
Where exactly does the API key go?
In Muse's Secrets tab, and nowhere else. Meta's store hands the agent a stand-in token rather than the literal string when the credential lives there, and you grant the standing site permission once instead of per task. A key typed into the chat is a key in the conversation history, which is a different security posture entirely. This is the one instruction on this page we would not treat as optional, and it is the same rule as any other agent surface: credentials belong in the credential store, not in the prompt.
What does the Secure VM actually change?
It is why no integration work exists. A persistent isolated Linux box with a full browser means the agent can fetch a spec, generate a client, install what it needs and make an authenticated HTTPS call, all on its side of the boundary. Agents without that have to be handed tools through a protocol, which is what MCP exists for and what the one-server-per-tool question is about. Muse skips that layer, which makes the connector count the only thing worth optimising.
Does the same approach work from other agents?
Yes, for any agent that can read a URL and set a header, which is most of them now. The spec is public, the auth is a single bearer token, and the four-path loop of discover, inspect, run and poll does not assume anything about the client. Agents that prefer a protocol to a spec can use the MCP route instead, and the tradeoff between one server per tool and one server for all of them is measured separately. The only real requirement is that the agent can make an outbound HTTPS request with a header it was given.
Last updated September 2026.
