​

Connect an agent

WhooshBang serves one agent surface: a hosted MCP endpoint at https://api.whooshbang.com/mcp, secured by OAuth. Point an MCP client at it, and the client registers itself, sends you to WhooshBang to sign in, and shows you what it is asking for. Approve it and your agent can use WhooshBang the way you can.

No credential is created, copied, or pasted anywhere in that flow. You are not handing the agent an API key — you are approving a connection you can see and end.

​

Connect a client and make a first call

Point the client at the endpoint. Most MCP clients take a URL and nothing else, because everything else is discovered:

{
  "mcpServers": {
    "whooshbang": {
      "url": "https://api.whooshbang.com/mcp"
    }
  }
}

For clients configured from a terminal, Claude Code takes the same thing as one command:

claude mcp add --transport http whooshbang https://api.whooshbang.com/mcp

The first call the client makes is unauthenticated and is refused with 401. That refusal carries the address of everything else — the client reads it, registers itself, and opens your browser:

www-authenticate: Bearer realm="OAuth",
  resource_metadata="https://api.whooshbang.com/.well-known/oauth-protected-resource/mcp"

Sign in, read what the client is asking for, and approve it. Nothing is pasted and no key is issued.

​

Ask it to set you up

Once connected, the agent can go from nothing to an invitation in one tool call:

whooshbang_create_project
  name: "Agent Alerts"
  slug: "agent-alerts"
  confirmation: "create-project"
  invite_subscriber_id: "me"

That creates the project and both environments, connects and routes the shared WhooshBang Telegram channel in test, and returns an authorization_url for you to open on a handset. Pressing Start there is the consent.

confirmation is deliberate. Creating a project is a durable, named thing your whole team sees, so the tool refuses to act unless the exact literal is supplied — which the agent must not do without asking you first.

​

Then send something

whooshbang_send_test_message
  project_id: "<the project it just made>"
  subscriber_id: "me"
  text: "Hello from an agent."

Read the result with whooshbang_get_message_status, and if anything is refused, whooshbang_explain_diagnostic turns the code into an explanation rather than leaving the agent to guess.

​

If it goes wrong

whooshbang_list_context is the orienting call: it says which organization the connection names, which projects it can see, and which permissions were approved. An agent that thinks it cannot see a project usually has a connection approved for a different organization.

​

What you are approving

The approval screen lists exactly the permissions the client asked for, in the same words the dashboard uses for an API credential’s scopes. Two levels exist:

• Organization permissions — reading the projects in your organization, and creating one. No API credential can hold these, which is why an agent that sets up a project needs a connection rather than a key.
• Project permissions — the same operations an API credential can perform: sending, reading messages, and managing subscriptions, connections, endpoints and machine clients.

An access token names your organization and the permissions you approved. It names no project. Every tool takes the project it acts in as an argument, and WhooshBang checks that project against your own membership on every call — so a project outside your organization is refused exactly as one that does not exist.

Your approval is also intersected with what your membership allows, at approval and again every time the client refreshes. Permissions only ever shrink.

​

The connection lasts until you end it

A connection you approve does not expire. The Authorized clients section of the dashboard says so — Lasts until you disconnect it — and means it: nothing times it out, and no period of disuse ends it.

Two things end a connection, and only two:

• You disconnect it. Open the dashboard, find the client under Authorized clients, and choose Disconnect. The agent stops immediately; its tokens stop working at the next call.
• You approve the same client again. Re-approving replaces the connection that client already had for your organization, and the previous one is ended in the same moment the new one is issued. That is deliberate: approving again is what most people reach for when something looks wrong, and it would be a poor answer if the suspect connection survived it.

Re-approving affects only your own connection to that client in that organization. If the same client is connected under another organization, or approved by a colleague, those are separate connections and are untouched.

​

What disconnecting does not stop

If you granted permission to manage machine clients, and the agent used it, the machine clients it created keep working after you disconnect. They are separate identities with their own credentials, bound to their own destinations, and they were always meant to outlive the session that provisioned them.

Ending one is a separate action, taken in the project environment that holds it. The dashboard warns about this where you grant the permission and again where you revoke it; it is repeated here because it is the one part of disconnecting that is not obvious.

​

Test and live

An agent cannot message a real person by accident.

• The test tools resolve the named project’s test environment and take no environment argument at all, so no input can point them at a real subscriber.
• Two tools reach the live environment: a message to one person, and a broadcast to everybody in a group. Each requires an explicit confirmation argument, and live sends through this endpoint are additionally switched off in every environment by default. Turning that on does not bypass the invited-alpha gate, which still decides per organization.

​

Sending to a group

An agent can build an audience and send to it: create a subscriber, create a static group, put people in it or take them out, and broadcast to everybody currently in it. A broadcast is one call that becomes ordinary messages, so every one of them can be read back with the same status tool as any other send.

The same care applies as to a single message, and more of it. The test broadcast tool cannot reach the live environment at all. The live one asks for a confirmation you should not give without knowing how many people are in the group — read that first; a group holds up to fifty thousand, and once a provider has accepted a message nobody can recall it.

Renaming and archiving a group are deliberately not agent tools. Those are decisions about how your own product is organised, and they belong in the dashboard, where the archive confirmation says what it costs.

​

No tool hands out a secret

Nothing an agent can call returns a credential, so nothing it can call can leak one. That is also why an agent cannot create or rotate a customer endpoint: the signing secret is shown exactly once, and the only place that can safely show it is your own browser. Create the endpoint in the dashboard, then let the agent verify and diagnose it.

​

During the invited alpha

The screen an agent sends you to is a sign-in screen. It offers no way to create an account, and it says so — public sign-up is closed and no invitation is automatic. Follow your invitation email first; that link is what creates your account. Afterwards, sign in with the same account whenever a client sends you here.