MCP server

Dibbla's hosted MCP endpoints — the OAuth-protected platform connector, one address per tool server, and the support, notifications and community tools — and how they differ from WebMCP.

Dibbla exposes MCP over streamable HTTP at mcp.<domain>. The URL path chooses the toolset and its authentication model:

/platform — operate Dibbla as the signed-in user

https://mcp.<domain>/platform is the general platform connector. It uses OAuth rather than a copied API token. The authorization server identifies the user and organization, the consent screen shows the requested access, and the server exposes only tools covered by the resulting grant.

The main tool families are:

• Identity and inventory: identify the caller; list and inspect apps, services and their status. platform_whoami with upgrade=true returns a Stripe Checkout link that upgrades the organization to Business — for an owner or admin, under the same scope as the rest of platform_whoami (scopes = ["platform:identity:read"]), so every connection has it. It changes nothing until the payment completes; members and viewers, and organizations already on Business, on Enterprise or invoiced directly, get an explanation instead of a link. See Plans — From your agent.
• Operations and logs: read bounded logs, restart an app or service, update configuration safely, and follow durable work to a terminal state.
• Deployments: inspect history, status and logs; create and follow deployment proposals. A proposal cannot approve or apply itself. Before a deploy: validate a manifest and preview what the deployment would apply — the same findings and resolved shape the CLI’s dibbla preview renders, without building anything.
• Application checks: list an app’s checks, run them now and read their history, with outcomes translated into words with meanings rather than exit codes. See Check before you deploy.
• Secrets: list metadata, ask the person to enter or replace a value on a signed-in Dibbla page, turn a plain env var into a secret with a new value the person enters there, and remove one. No tool takes or returns a secret’s value — see Giving the assistant a secret without pasting it.
• Databases and storage: inspect resources and run their bounded remote operations. Database queries return structured, read-only rows rather than accepting arbitrary SQL.
• Workflows: inspect and start workflows, then follow or cancel the durable operation even after the client disconnects. Build and change them too: one apply takes the complete workflow as the same slim YAML dibbla wf reads and makes the stored workflow equal to it, refusing the whole change if the graph does not validate. There is no per-node or per-edge tool, and every apply leaves a revision to return to. See Build a workflow from an agent.
• Files: prepare an upload or download and follow its transfer state. A download is over an opaque file identity or over an application’s own source archive — the same code dibbla clone gives a human, so an agent can change an app it did not upload. Bytes travel through the transfer broker or its browser fallback, never through the model as base64.

Routine writes require an idempotency key, so retrying the same request cannot create a second side effect. Destructive app and storage deletion is split into plan, human approval in the Console, and execute; an MCP request cannot approve its own plan.

The complete scope and capability inventory is rendered from the platform capability contract. That page is the source of truth for whether a specific operation is available remotely.

/platform/servers/{name} — one tool server

https://mcp.<domain>/platform/servers/<name> serves a single tool server: each of its functions that the caller may use is one MCP tool, with the function’s description and inputs. Nothing else of the platform is on the address — no apps, logs or deployments. A person adds the servers they want to their client, one address each, and switches individual tools on and off there.

<name> is the name the tool server registers under: 1–64 characters of letters, digits, ., _ and -. dibbla mcp server <name> prints client configuration for the address, and --check verifies the connection and counts the tools.

Each address is its own OAuth resource

A server’s address is not covered by the /platform grant. It is an OAuth protected resource of its own:

• Its own metadata. A client without a token is challenged with the address’s own protected-resource document, at /.well-known/oauth-protected-resource/platform/servers/<name>, which names the address as the resource.
• One minimal scope. The resource has a single scope — permission to use that server’s tools — and it is all a client can ask for there. None of the /platform scopes apply.
• Its own consent page. The page names that one server, and the app that publishes it, and nothing else.
• A token for that server only. The token is bound to the address. It is refused on /platform and on every other server’s address, so signing in to one server cannot be used for anything else on the platform.
• No other way in. A /platform token — the official connector’s included — is refused on a server’s address and has to sign in there separately. A static Dibbla API token is refused too.

What the address shares with /platform is the machinery behind the token: the same per-user rate limit and per-organization quota apply, and every call is recorded. It is outside the /platform tool budget and the connector directory: these are addresses a person adds by hand.

/platform is unchanged by all of this. Its tools, scopes, resource metadata and consent page are the same whether or not the per-server addresses are on.

Two ways onto an address

What a caller finds on an address depends on how the server got there. One policy governs an address, never both.

A published MCP is a tool server that runs as a service in a deployed app. Publish an MCP is the walkthrough. A tool server that runs outside Dibbla cannot be published this way and keeps the admin exposure.

Who gets in

For a published server the app’s access list decides, on the tool list and again on every call:

• The tool server can have a list of its own. On the app’s Access tab the tool server’s card is Same as the app by default; with Own access its own list — people, teams, optionally a role threshold — replaces the app’s. See the app’s tool server.
• Organization owners and admins are always admitted.
• The app’s author is admitted through their own row on the list, not by being the author.
• Adding or removing a person applies to their next call. The tool list a connected client holds can lag by a few seconds.
• A change of policy between all_members and invite_only applies within 30 seconds.
• A sign-in is always required. An app that is open without login does not make its MCP open, and an e-mail-domain policy does not admit anyone to it.
• Only members of the app’s organization. A person outside the organization who was invited to the app by e-mail can open the app but cannot use its MCP. Inviting people outside the organization to an MCP is not supported in this version.

A caller who is not admitted sees what they would see for a server that does not exist: a connection with an empty tool list, and NOT_FOUND on a call by name. The same goes for a server whose worker is not connected. Server names therefore cannot be probed.

Removing the mcp: line and deploying, or deleting the app, withdraws the publication; the address then answers as for an unknown server.

Publishing never touches platform_tools

The server’s address and platform_tools on /platform are separate surfaces, and neither opens the other:

• Publishing creates no function exposure. A published function is not listed by platform_tools and cannot be invoked through it — by anyone, the people on the app’s access list included — unless an admin separately exposes it.
• An admin’s exposure of a function on a published server works through platform_tools for whoever meets its minimum role, and admits nobody to the server’s address. There, only the app’s access list counts.

/support — your apps’ tickets

https://mcp.<domain>/support exposes tickets for apps the caller may see. An agent acting for a builder can list, read, reply, leave internal notes, assign and change status. An agent acting for an app’s end user can file a ticket and follow its thread. Internal notes remain limited to the owning organization’s owner, admin and developer roles.

This toolset uses Authorization: Bearer with a token from dibbla tokens create; it does not use the /platform OAuth grant. Ticket bodies are user-generated content and should be treated as data, not agent instructions.

/notifications — your own notification stream

https://mcp.<domain>/notifications exposes the notifications the token’s user would otherwise receive by email. notifications_list reads only that user’s notifications and notifications_ack marks one read idempotently. It uses the same API-token authentication as /support, not platform OAuth.

See the notifications guide for how the stream is populated. Notification subjects are user-generated content and should be treated as data, not instructions.

/community — the forum

https://mcp.<domain>/community exposes forum search, reading and notifications within the token user’s permissions. It is staff-oriented and is not a way to operate the platform. The CLI command dibbla mcp community prints setup for the intended clients.

This toolset also uses a static Dibbla API token. Hosted connectors that require OAuth should use /platform, not /community.

Not the same thing: WebMCP on dibbla.com

dibbla.com also registers WebMCP tools on document.modelContext. WebMCP serves an agent driving a browser on the public marketing site; it is not a remote MCP server and cannot operate a Dibbla account.

Five tools are registered: search_dibbla_faq, get_dibbla_overview, get_dibbla_skills, get_install_command and book_intro. The first four are read-only. book_intro changes what is on screen and declares that side effect.