run_connection_session opens one MCP session signed in with an MCP OAuth
connection's stored tokens and runs a batch of tool calls in it, so a
sync makes hundreds of calls over one sign-in. The tokens only go to the
server the connection signed in to. A sign-in that expired and cannot be
renewed flags the connection for reconnecting, which pauses its sources;
network trouble and rate limits are reported as worth retrying.
The MCP SDK knows a token's expiry only when it obtained the token in the
same process. A worker or a restarted API loading tokens from the
connection sent an expired one, got a 401 and asked the owner to sign in
again. The expiry is now saved with the tokens and handed back to the SDK,
which then renews the token with its refresh token first; a token saved
before expiries were kept is renewed once. A sign-in that cannot be
renewed raises MCPReauthorizationRequired.
Explains the opt-in switch, the full endpoint it uses, how write actions
default to asking first, the admin's Write access switch, and which
fine-grained token or GitHub App permissions changes need.
The GitHub tools step gets a second switch under Let agents use GitHub:
Also let agents make changes (issues, comments, pull requests), off by
default. A connection's page has the same switch on its GitHub tool, which
re-reads the tool's actions from the other endpoint. Both are hidden when
an admin turns changes off in the new Write access section of
Admin > Connectors. The token hint and the GitHub App setup note name the
permissions changes need.
A GitHub connection's MCP tool can now point at GitHub's full endpoint
(/mcp/) instead of the read-only one when its owner opts in, at setup
(allow_writes) or later (PUT /api/connections/<id>/writes), which re-reads
the actions and keeps the choices for those on both endpoints. Actions from
the write endpoint are writes unless GitHub marks them read-only, so they
default to asking first.
Admins can forbid it per connector (allow_writes in Admin > Connectors,
kept in app_metadata). Then the option is refused, a refresh goes back to
read-only, and at run time the tool only ever calls the read-only endpoint
and write calls are denied with a reason.
The approval card and a finished call showed what the model asked for,
even where a fixed value replaced it. Calls now carry sent_arguments for
the chat, leaving headers out since they may hold a fixed secret. The
model's own arguments are kept as they were, because they are what later
turns replay to it and it never sees fixed values.
The connect wizard asks for an optional account name (keys and sign-ins
alike) and sets it once the account exists. In the connector drawer a
named account shows its name with the account under it, and Rename in
the account menu changes or clears the name.
Connections get an account_name (migration 0039) that the owner sets with
PATCH /api/connections/<id>; the account label stays the account's
identity, so signing in again still finds it. When someone has more than
one account of a service, its tools are listed as "Telegram · <account>"
and the model sees each account's actions under the account's name
(telegram_send_message_alerts_bot) with the account in the description,
instead of _1 and _2. Actions shared by different services are named
after the service. Tools a user renamed keep their name.
The connect form shows field hints; Telegram's Default chat ID says what
it does and how to find a chat's id. In the drawer, a chat set on the
account shows as set there instead of as a choice.
A Telegram connection can now hold an optional default chat ID. When it
is set, both Telegram actions send there, the model is no longer asked
for a chat, and a chat it names anyway is ignored. In member mode each
member's own connection supplies their own chat. The same bot with a
different chat is a separate connection.
Under Customize, each action now opens its parameters. Each one is either
left to the AI or set to Always use a value, which is sent on every call
and never shown to the AI. Actions with fixed values carry a small count.
PUT /api/connections/<id>/tools/<tool_id>/parameters takes an action and
a map of parameter to value (always use it) or null (let the model
decide), checked against the action's schema; only the tool's owner can
call it. Connection tools now list each action's parameters and whether
they are fixed.
update_tool_actions now checks the submitted actions against the tool's
stored ones: no new actions or parameters, fixed values must fit their
parameter's type. A team editor can still switch actions on and off but
gets 403 for changing a fixed value.
A parameter hidden from the model with a stored value is now always sent
with that value; a model that names the key anyway (by mistake, or because
a prompt told it to) no longer overrides it. 0 and false are real fixed
values; an empty value still means the parameter is left out.
S3 and GitHub sources synced from a connection kept being retried on
every schedule after their connection needed reconnecting, failing and
notifying the owner each time. They now wait, like Drive and Confluence
sources, and resume when the connection is reconnected.
How members connect with a fine-grained token or Sign in with GitHub, how
an admin registers the GitHub App (callback URL, permissions, requesting
authorization during installation, settings), and that
GITHUB_ACCESS_TOKEN now reads public repositories only.
The connect wizard offers both sign-ins when the GitHub App is set up
(token only otherwise, with a link to create a fine-grained token), and
says when GitHub refuses a token. After sign-in, one step turns on the
read-only GitHub tools and picks a repository to sync. The repository
picker searches what the connection can read; a GitHub App sign-in can
choose more repositories on GitHub and the list reloads.
A token connection is shown by its GitHub login rather than a key hint,
and a connection set up without tools can add them from its page. The
GitHub upload tile keeps reading public repositories by URL, and points
to the GitHub connection for private ones.
GitHub is Ready with tokens alone and marked Tokens only until its GitHub
App settings are set. Its setup guide lists them, the callback URL to
register, and the App permissions and install option to choose.
The admin connectors API lists the settings that add Sign in with GitHub
and whether they are complete, next to the required settings (none for
GitHub, which works with tokens alone).
One GitHub connection feeds both a Knowledge source and an agent tool.
Users connect with a personal access token, checked against GitHub and
named after the account, or, when an admin registers a GitHub App
(GITHUB_CLIENT_ID, GITHUB_CLIENT_SECRET, GITHUB_APP_SLUG), with Sign in
with GitHub. App tokens expire after eight hours and are refreshed before
each sync or tool call; tokens with no expiry are never treated as expired.
The catalog gains an optional second sign-in method (oauth_settings,
exposed as sign_in_methods) without changing any other connector.
Sync lists the repositories the connection can read (the token's own, or
the App installations') and ingests one with the connection's token. The
tool is GitHub's read-only MCP server (api.githubcopilot.com/mcp/readonly):
setup discovers its actions and creates it bound to the connection, and
the executor sends the connection's token only to that server.
GITHUB_ACCESS_TOKEN belongs to the server, but any user could ingest any
repository it can see, private ones included. It is now used only for
public repositories; the loader checks the repository's visibility first
and asks for a GitHub connection otherwise.
The loader also takes a token from the connection a source syncs from.
Merging a connection's keys into a plain repository URL no longer fails
on json.loads, manual Sync now passes the source's connection, and a
token GitHub rejects pauses the connection's sources for reconnect.
The cache key held the first ten characters of a bearer token or API key.
Every fine-grained GitHub token starts with github_pat_, so two users of
the same server shared one cached client, and with it the first user's
token, for up to five minutes.
A connected tool's card has its switch again and names its account, so
two accounts of one service are two tools you can turn on and off. Manage
connection in its menu opens the connection panel on the Tools page
instead of leaving for Connectors.
A custom MCP connection at a preset's address is reported and run as that
preset, but saving it checked the custom MCP switch. Turning custom servers
off now leaves a preset on a key alone, and turning the preset off stops it.
The reset ran in an effect after the new picker had reported its default
account, so remote uploads could send no connection. It now happens with
the type change. A connection tile that is not set up says Not connected.
Linear, Jira & Confluence and Asana move to Projects & issues, Stripe to
Payments & business and Reddit to Search & web. An empty Knowledge page
offers Add knowledge and Connect a service.
What a tool looks up and what it does are each set at once to Allow, Ask
first or Off; long lists fold behind Customize, where each action shows its
name in words and its description. A note says what Ask first means over
an agent's API. The panel follows a refreshed tool's actions.
The chat and agent tool pickers mark a tool whose connection expired and
offer Reconnect, which redoes the sign-in in place (or opens the connector
page for a custom server). The connector page names the account without
claiming it is connected and says what went wrong in plain words, keeping
the provider's message on hover.
A tool from a connection shows the catalog's description and a Manage
connection button instead of its own switch, and its menu no longer opens
the raw MCP server form to reconnect. It says when it is off or needs
signing in again.
Adds the copy the next changes use and finishes the Sources to Knowledge
wording in connector flows: reconnect toasts, the disconnect and remove
confirmations, the wizard's done step and the Knowledge picker. Permission
choices read Allow / Ask first / Off everywhere.
With client_secret_basic the MCP SDK sets the Basic header and still sends
client_id in the body; Linear refuses that as two authentication methods.
Token and refresh requests now drop the body client_id when the Basic
header is set, as RFC 6749 describes.
mcp 2.x reads code, state and the RFC 9207 iss off the callback handler's
result; the handler still returned a (code, state) tuple, so every MCP
sign-in failed after the user approved it. The callback route now keeps the
issuer too, since servers that advertise it (Linear) refuse a sign-in
without it.
A page opened on a plain-HTTP address registered its own origin as the
callback, which servers such as Linear refuse. MCP_OAUTH_REDIRECT_URI now
wins when set; the page's value is the fallback.
The client follows an MCP sign-in by its task's events, but the test route
kept only success, requires_oauth and auth_url, so the wizard and the custom
MCP modal reported a failed sign-in before the popup could load.
Linear and Sentry publish https://host/mcp as their protected resource.
DocsGPTOAuth gave the MCP SDK only the server's origin, so the SDK's
resource check (RFC 8707) failed before sign-in with "Protected resource
https://mcp.linear.app/mcp does not match expected
https://mcp.linear.app". The provider now gets the full MCP URL; servers
that publish their origin still pass, and tokens stay keyed by origin.
- Tools from a connection turn on and off on the connector's page (a
real switch, not a badge), next to their action permissions.
- Knowledge synced from a connection lists its sync state there, with
Sync now (connector sources and S3/Reddit sources each through their
own endpoint).
- On the Tools and Knowledge pages, anything from a connection has
"Manage connection" in its menu, which opens that page; the tool
editor with its second credentials form is no longer offered for them.
- A link to a part (Jira & Confluence) opens its parent's page.
- Sources (the collection) are called Knowledge: the settings page (now
/settings/knowledge; /settings/sources redirects), the composer and
agent pickers, Add knowledge, and "syncs into Knowledge" on connectors.
Citations keep "sources". All seven locales.
- Connector cards describe what they do ("Syncs into Knowledge", "Looks
things up", "Takes actions") and drop publisher labels ("Built in",
"Preset"). Filters read "Files & storage" and "Docs & wikis" so
"knowledge" means one thing.
- Custom tools are tools: "Add custom tool". The agent picker no longer
splits built-in tools into "Built-in" and "Default".
- Confluence is one card: syncing pages into Knowledge and the Jira &
Confluence MCP actions (part_of on the preset) share a page. The part
shows on its own when Confluence sync is not set up.
- The empty chat screen swaps its last demo card for "Connect your
data" while nothing is connected, naming services this install can
connect.
- A warning dot on Settings and on Settings > Connectors marks a
connection that needs signing in again; unlike the toast it stays until
the connection is fixed. Connections load once at start for it.
- Category pills on the Connectors page follow the composer's capability
filter, so none leads to an empty page.
- One control for members' own MCP servers: the custom MCP server row's
switch (it sets both the policy and the instance switch); the separate
top-level switch is gone.
- Connectors that only sync content show "No tools" instead of a
sharing policy, and the policies read "The sharer decides per share",
"Always the sharer's account", "Always each person's own account".
- A connector that needs server settings can't be switched on until they
exist; a tooltip says why.
- On phones the table becomes a list ("On · 2 connections · …") and each
connector's controls open in a sheet.
arc53-machine