Organization MCP endpoint
Add remote connectors once in the console. The gateway serves them to every managed tool at
https://<gateway>/mcp/org.
Connectors that need no sign-in are shared across the organization. OAuth connectors use the calling developer's personal grant. Desktop built-ins and local commands stay in Claude Desktop.
Set it up
In the console, open Connectors under Settings. Choose Add and search by name. For
anything not listed, paste the server's http or sse address.
The gateway asks the server for its name and tools before saving it. A server that answers openly is ready for everyone. A server that requires sign-in is saved once, then each developer authorizes it with their own account.
URL-only MCP clients sign in through the same WorkOS organization as the console. If the organization has not connected its identity provider, follow Enterprise SSO enrollment. Sign-in opens once Anyray registers this gateway's address. Requiring SSO in the organization policy is recommended hardening on top, not something sign-in waits for.
Connect-managed tools use the developer's existing ark_ key and need no extra sign-in for
the organization endpoint.
This lane needs the organization's WorkOS SSO. Without it the gateway returns 401 naming the
client key and advertises no sign-in, so a URL-only client fails once and says so instead of
looping through a login it cannot finish. Connect-managed tools are unaffected either way.
Developers get the sign-in tool without any setting change. If you need to withdraw it, turn off the Postgres-backed runtime switch:
curl -X PUT https://gateway.example.com/admin/v1/settings \
-H "Authorization: Bearer $ANYRAY_ADMIN_TOKEN" \
-H "Content-Type: application/json" \
-d '{"mcpConnectorSignInTools":false}'
Connectors then stay unreachable until each developer signs in some other way. Set it back to
true to restore the tool once the settings cache refreshes.
The gateway refuses a saved connector it cannot serve, such as one on a private host or sharing a name with another. Ask it how many:
curl -s https://gateway.example.com/admin/v1/policies/claude-desktop/connectors/readiness \
-H "Authorization: Bearer $ANYRAY_ADMIN_TOKEN" | jq '.connectors'
dropped: 0 means every row you saved reaches developers. A non-zero count comes with
dropReasons naming which rows and why.
What developers do
Connect-managed tools need no manual setup. Connect writes the endpoint with the developer's key. An agent the console mints a key for gets it too: the config the Agents card hands out registers the endpoint alongside the retrieval one, for the sandboxed and SDK lanes Connect cannot reach.
In another URL-based MCP client, add the endpoint and no custom header. Copy it from the Connectors page in the console, which shows this deployment's own address:
https://gateway.example.com/mcp/org
Name the server anyray-connectors. If Connect manages that machine later, it takes over the entry
you added instead of leaving a second one behind.
The client discovers AuthKit and asks the developer to sign in
with the organization's SSO. A deployment whose address Anyray has not registered has no sign-in at
all: it returns 401 naming the client key, advertises no authorization server, and answers 404 on
both discovery documents, so a client stops instead of retrying.
When a connector needs a vendor account, tools/list shows a gateway-owned tool named for it, such
as anyray_signin__clickup. Call it with no arguments for a sign-in link, then again with the code
the page shows. It disappears once that developer holds a grant, and the connector's real tools take
its place.
Every waiting connector gets one, so a developer can find a connector by its own name. Each costs
prompt tokens on every request, so an organization with many waiting at once can switch to a single
anyray_connect covering all of them with {"mcpConnectTool":true}. Call that one with no
arguments to list who is waiting, then with a connector to start one sign-in:
{"connector":"Atlassian"}
Open the returned URL and finish vendor consent. The callback shows a short claim code. Give that code back to the assistant with the same connector:
{"connector":"Atlassian","claim":"ABCDEFGHJKLM"}
The claim is single-use and expires after five minutes. Redemption binds the grant to the verified
developer making this call, regardless of who started the browser flow. The tool refuses to start or
redeem while that developer already has a usable grant, so it cannot replace a working connection.
Refresh the client's tool list after redemption. A client that caches tools may need to reconnect
because /mcp/org has no server-push response stream.
The command-line flow remains available:
npx anyray-connect connectors authorize "Atlassian"
The command opens the vendor consent page and reports the account that received the grant. Over
SSH, run it again with --claim <code>. This CLI lane stays unbound until the verified client
redeems the code. The console's Authorize action uses the same claim-code flow.
Until the grant lands, the connector's real tools stay out of tools/list. Calling a remembered
real tool name returns HTTP 200 with an MCP tool result marked isError: true. The result names
the connector and points to anyray_connect while the switch is on. It does not start authorization.