Meta's Muse is the assistant you already talk to. 1Claw is where your AI agents keep their credentials and wallets, and where a person has to say yes before an agent does something that matters. The 1Claw connector for Muse joins the two: ask Muse "is anything waiting on me?", hear what your agents are asking for, and approve or reject it without opening a dashboard. Here is how it works, what it can and cannot do, and how to set it up in about two minutes.
What the connector is
Muse builds Custom Connectors by reading a service's API description and keeping the user's credential for that service in its own secure credential store. The 1Claw connector is a small REST service at muse.1claw.co that publishes exactly that: an OpenAPI description (/openapi.json), plain-language instructions for the assistant (/llms.txt), and six routes. Behind it sits the 1Claw Platform API, the same surface every third-party assistant uses to act on a 1Claw account with the user's explicit grants.
Muse ──(mcn_ connector token)──▶ muse.1claw.co ──(plt_ key + connection id)──▶ api.1claw.co
the connector 1Claw vaultThe token Muse holds (mcn_…) is not a 1Claw account credential. It is an HMAC-signed handle that names one platform connection — your account, linked to the 1Claw-owned "Muse" app, with the agents you chose to expose. The 1Claw platform key never leaves the connector. The prefix is deliberately different from every vault credential (ocv_, 1ck_, plt_), so the vault will never accept it and a leaked one is recognisable on sight.
What you can ask Muse
| You say | Muse calls | What comes back |
|---|---|---|
| "Is anything waiting on me in 1Claw?" | GET /v1/approvals | Pending approvals from both queues — agent action approvals and multi-party consensus — each with a one-line summary |
| "Approve the Base payment to the supplier" | POST /v1/approvals/{id}/decide | Muse reads the item back, gets your yes or no, records the decision in 1Claw. The only write route. |
| "How much is in my agents' wallets?" | GET /v1/portfolio, /v1/balances | Balances for wallets on the agents you granted |
| "What did my agents do today?" | GET /v1/activity | The delegation log for the connection |
| "What jobs do they run?" | GET /v1/automations | Scheduled and event-driven workflows, read only |
| "Which account is this?" | GET /v1/me | The connection and what it has been granted |
What it cannot do, by construction rather than by policy: read a secret, move funds, sign a transaction, or create, change or delete an agent, policy, vault or automation. There is one write route and it takes a yes or a no. Everything else stays in the 1Claw dashboard, behind your passkey.
Setting it up
- Signed in to 1Claw, go to Settings → Connected Apps → Connect Muse (or open 1claw.co/connect/muse directly). The page asks the connector to create (or find) your connection on the Muse app. If you already had a 1Claw account you go through the standard "Sign in with 1Claw" consent once.
- Choose which agents Muse may see: Settings → Connected Apps → expand Muse → Grant agents & vaults. This is the same grant flow every platform app uses; a connection with no grants sees nothing at all. (The Management Access switch on that card is a different control — what an app may do on your behalf — and is not needed for Muse.) You can widen or narrow it later.
- Copy the connector token (
mcn_…). It is shown once. When Muse asks for the service's credentials, paste it, with base URLhttps://muse.1claw.co. - Ask Muse something. "Anything waiting on me in 1Claw?" is a good first question.
To revoke: Settings → Connected apps → Muse → Disconnect. Every request the connector makes re-checks the connection, so a revoked token stops working immediately; there is no cache to wait out. Tokens also expire after a year on their own. The connector rate-limits each token and each caller address, and its responses are marked no-store so nothing about your approvals is cached along the way.
Why approvals are the right first surface
The whole point of running an agent with real credentials is that it can act. The whole point of 1Claw is that a person decides which actions need a human first — a payment over a threshold, a policy change, a message going out under your name — and that the agent waits. Waiting only works if the person finds out. Email is slow; a dashboard is something you have to remember to open. An assistant you already talk to during the day is where a two-word decision belongs.
Two details make this safe enough to put in a chat. First, the assistant is told (in /llms.txt) to read each pending item back in full and get an explicit yes or no per item before deciding — no "approve everything". Second, a consensus vote must echo the approval's payload_hash, and the connector reads that hash fresh from 1Claw and ignores anything the request body supplies. A decision binds to the thing that was shown, not to whatever the model thinks it saw. On the vault side, transaction recipients are screened against the OFAC list before any approval can execute, and every decision lands in your audit log with you as the actor and "Muse" as the app.
A worked example
Say you run a purchasing agent with a USDC wallet on Base and an action_approval_policy that requires a human above $500. Overnight it finds an invoice for $1,200 and creates an approval instead of paying. In the morning:
You: Anything waiting on me in 1Claw?
Muse: One item. "purchasing-agent" wants to pay 1,200 USDC on Base to
0x8f3a…c21e for invoice INV-2291 (Northwind Supply). Created 03:14.
Approve or reject?
You: Approve it.
Muse: Confirming: approve the 1,200 USDC payment to 0x8f3a…c21e for
INV-2291. Yes?
You: Yes.
Muse: Approved. 1Claw recorded your decision; the agent will send it.Under the hood that was GET /v1/approvals, one POST /v1/approvals/{id}/decide with {"decision": "approve"}, and the agent picking up the approved request on its next check (an automation parked on that approval resumes on its own). The agent never learned anything new; the credential never moved; you never opened a browser.
For developers
The connector is open source (Apache-2.0) at github.com/1clawAI/muse-connector: a stateless Hono service on top of @1claw/sdk, with the platform connection itself as the only state. It is also a worked example of how to put any assistant in front of a 1Claw account — the Platform API's grant model does the scoping, so a connector never has to. If you are building for a different assistant, the same shape applies: mint a connection, let the user grant agents, hand the assistant a token that names the connection and nothing more.
Docs: Platform API · Action approvals · Connect Muse.