# Centralis in ChatGPT

Centralis is a plain MCP server over HTTPS with OAuth 2.1 in front of it, so it
is not Claude-specific — ChatGPT can hold the same connector. What differs is
the host, and three of its constraints are worth knowing before you start
rather than after.

## Before you start

- **Your Google address must already be on the team list.** ChatGPT sends you to
  Centralis, Centralis sends you to Google, and then it checks the address that
  comes back against the team registry. Signing in proves who you are; it does
  not by itself let you in. If you get *"not on the team list"*, that is the
  missing step — send an owner the address you tried; they add it with
  `team_manage` and you can retry immediately.
- **Connectors are a workspace setting on Business and Enterprise plans.** If
  the option below is absent, an owner or admin has to enable custom connectors
  for the workspace first. Nothing on the Centralis side can work around that.
- **Use the same Google account in both places.** The identity Centralis records
  against every change is the one you sign into Google with here, not the
  account you are logged into ChatGPT as.

## Add it

Settings → **Connectors** → **Advanced** → turn on **Developer mode**, then
create a connector with:

| field | value |
|---|---|
| URL | `https://mcp.jinemi.com/mcp?toolsets=research,docs,ops,forge` |
| Authentication | **OAuth** |

Press **Connect**. ChatGPT registers itself, sends you to Centralis, Centralis
sends you to Google, and you land back on a consent page that names ChatGPT's
origin as where the tokens will go. Approve it and the tools appear.

There is nothing to paste and no client id to ask for: Centralis supports
dynamic client registration, so ChatGPT provisions its own credentials on first
connect.

## Keep the `?toolsets=` part

This is the one line people delete, and it is the one that matters most here.

The default surface is every native tool plus the mounted Discord server — well
over a hundred definitions. Claude holds that; ChatGPT does much worse with it,
and selection accuracy degrades long before any hard limit does. Naming toolsets
registers only those, and an unregistered tool costs nothing at all — this is a
context saving, not a permission. Your role still decides what you may reach.

`research,docs,ops,forge` is a reasonable default. Swap the list for what you
actually do; `/toolsets.json` lists every name the server accepts. A name it
does not recognise is a `400` with the valid list in the body, not a silent
mis-scope.

**`research` is the one to keep.** It carries `search` and `fetch` — the two
tool names ChatGPT's own research surface calls, without consulting a
description, over Thermograph's written record: architecture decisions,
runbooks, the business layer, and the dated notes and call summaries. They are
opt-in precisely so Claude never sees them, since there they would only compete
with `docs_search`. Without `research` in the URL, ChatGPT can authenticate and
then find nothing to call on its own initiative.

## Check it worked

Ask it: **"search the Thermograph docs for how environments stage"**. You should
get results citing `dev` → `main` → `release`, each linking back to a file on
the forge.

For the non-research tools, ask **"what's running on prod right now?"** — that
should call `fleet_status` and list the Swarm services.

## When it does not

| symptom | cause |
|---|---|
| Connect fails before any Google page | the workspace has custom connectors disabled, or the URL is missing `/mcp` |
| Google signs you in, then *"not on the team list"* | the address is not on the team — an owner adds it with `team_manage`, no restart needed |
| Connected, but every call returns 401 | the connector was added with a URL this deployment does not serve as a resource. Check it is exactly `https://mcp.jinemi.com/mcp`, query string and all — a token's audience is the URL you configured |
| Connected, but ChatGPT never calls anything | `research` is missing from `?toolsets=`, so there is no `search`/`fetch` for it to reach for |
| Fewer tools than expected | working as intended — see `?toolsets=` above, and note your role filters the rest |

## What it cannot do

Everything a role cannot reach is absent from the session rather than refused,
so ChatGPT will not offer it and cannot be talked into it. Beyond that:

- **Writes still go through a pull request** where the estate says they do. That
  is a property of the tools, not of the client — `onedev_write` opens a PR from
  ChatGPT exactly as it does from Claude.
- **Owner-only tools need an owner.** Reading secrets, changing production
  directly, and promoting releases are not member-visible in any client.
- **Audit records the person, not the product.** A change made through ChatGPT
  is filed under your Google identity, and `audit_read` cannot tell which client
  it came from. If that distinction ever matters, use a separate bearer identity
  instead.