Installation¶
Every supported host connects to the same remote MCP server. This section is the connection reference: one page per host, each recording what was observed on that host and the date of the pass.
Endpoint¶
Canonical endpoint: https://mcp.bloomy.earth/mcp — no trailing slash.
OAuth discovery, client registration and sign-in all happen from that one URL. The authorization server is discovered through the server's own OAuth metadata, so there is no second URL to configure by hand.
Bring your own account¶
Sign-in asks for your own Bloomy Earth Dashboard → Integration API credentials: a username and an application password. There are no operator-held Bloomy API secrets — the server verifies your credentials live against the Bloomy API before it issues a token for you. Credentials belong only in the OAuth browser flow: never in a host configuration file, never in a chat message.
Consent asks for one permission¶
The consent page renders one permission row per request:
- Requesting write means reading the account and taking climate actions are granted together, or not at all. There is no independent read-only grant to combine with write, and no way to select write without read.
- A client that requests only read is shown only the read row.
offline_accessis never a checkbox. It is a refresh-token capability the client either asked for or did not: when it did, the page shows one informational line —Stay connected across conversations— and the grant carries a refresh token; when it did not, the grant carries none and you re-authenticate when the access token expires.
The granted set is derived from what the client requested, never from form values, and a request carrying no account permission is rejected rather than minting a dead token.
Hosts¶
| Host | Scope set requested | Status |
|---|---|---|
| ChatGPT — custom connector | mcp:read mcp:write (builder-configured at add time, no offline_access) |
validated 2026-11-04 |
| ChatGPT — agent plugin | not recorded separately — sign-in and confirmation behave as on the custom connector | validated 2026-11-04 |
| Claude app (claude.ai web) | mcp:read mcp:write offline_access |
validated 2026-11-04 |
| Claude Code (terminal CLI) | mcp:read mcp:write offline_access |
validated 2026-11-04 |
| opencode | mcp:read mcp:write offline_access |
validated 2026-11-04 |
| Kimi Code CLI | mcp:read mcp:write offline_access |
validated 2026-11-04 |
| Codex CLI | not applicable — no connection was exercised | docs-verified, not exercised |
Each host page states the client version it was validated against and the date of that pass. A host marked docs-verified was checked against its official documentation only: nothing was installed or connected, and no behaviour is claimed for it.
What every host gets¶
Once connected, a host sees the same seven tools, the same single consent permission and the same server-enforced confirmation floor for write actions. What differs between hosts is where the human confirmation step appears — a native dialog on some, ordinary assistant text on others — never whether it happens. A host's own approval setting sits on top of that floor and cannot replace it.