Everywhere people work, InOrbit in every assistant, registry and IDE

Problem

InOrbit's MCP server (RFC 0050) works from any assistant that speaks MCP and signs in with OAuth, and the plugins of RFC 0040.14 wrap it for each assistant. Today a person still has to find the server's address in our docs and type it into their tool. The places people look for tools are elsewhere: the plugin and connector directories of the assistants, the MCP registry the editors read, and each editor's own list. InOrbit is in none of them.

Each of those places has its own format, its own review and its own terms. Some require a public repository, some a test account, some a privacy policy, and each vendor's terms decide what we may say about it and what we accept by listing. Done one by one, the work repeats and the terms go unread.

Proposal

One address, one public repository

Every channel points at the same public address, signed in with the person's own InOrbit account. Nothing in any channel holds logic of its own: every channel is a manifest that names the server, or a listing that points at it.

The public repository of RFC 0040.14 holds one manifest per channel format:

The repository has a licence, a security policy, a README that lists every tool with its scopes and whether it writes, what reaches InOrbit, and the trademark lines each vendor asks for. It contains no secret and no internal tooling.

A diagram is drawn here in the RFCs product; this page does not show diagrams yet.

The registry entry, under our own name

The server is published once to the official MCP registry as hr.inorbit/inorbit, with the namespace proved by a DNS record on our own domain. The domain then ties the name to the server visibly, which a GitHub namespace would not. The private key that signs the publication lives only in a secret store, and publishing runs from CI with a short-lived identity, as every release does.

The directories that review

Editors without a directory (Windsurf, Zed, JetBrains AI Assistant and Junie, Visual Studio, Neovim) get install links where they exist and a short snippet each on our developer docs. Two editors on the first list are left out: Roo Code and Continue are no longer maintained.

Claude Desktop needs no package of its own: a remote server reaches it through the connector listing.

Sign-in from every client, tested before it is listed

Each client signs in its own way, and a listing that cannot sign in is worse than none. Before a channel is submitted, its client completes a real sign-in and a tool call against the live server. The checks that block several channels are known now:

• the token's audience must name the server when the client asks for it by resource;
• the authorization response must carry the issuer, which some clients require;
• each client's redirect address must be accepted: loopback addresses on any port, and the vendors' own callback pages;
• unauthenticated calls answer 401 with the metadata's address, never 403.

A check that fails becomes a change to the sign-in, under the access-control rules of RFC 0050, never a weaker rule for one vendor.

What the tools may not do in a listed server

Every directory forbids some kinds of tool, and the strictest rule wins:

• no tool that moves money or other financial assets;
• no tool that generates images, video or audio;
• no tool that asks for a credential;
• no plan, upgrade or checkout link in a tool's answer;
• no tool description that steers the assistant toward other tools or promotes anything.

The listed server keeps to all of them.

What reaches us, and what we promise

An assistant sends us what a tool call carries: the tool, its arguments and the person's token. A tool's answer goes back into the assistant's own model, the vendor's processing under the person's own agreement with that vendor. InOrbit logs each call as who, which tool and the outcome, never the arguments or the answer, and sends nothing to a third-party model of its own. Every listing says so in the same words, uses "aligned" rather than "compliant", and tells people the tools are used through an AI assistant.

A directory that would proxy our traffic through its own servers is not used, because it would make that directory a processor of customer data.

Who does what

Engineering:

1. Prepare each manifest.
2. Pass each vendor's validator.
3. Test sign-in from each client.
4. Write the listing texts.
5. Record each channel in the compliance programme's vendor register.

The owner:

1. Read each vendor's terms.
2. Make the repository public.
3. Create the accounts and verify the company.
4. Approve the test account.
5. Submit each listing.
6. Write to vendors whose trademark rules need permission for our wording.

No listing goes out until the owner has read that vendor's terms.

Open questions

• Anthropic's terms. Anthropic's directory terms ask us to indemnify Anthropic for claims arising from our server, and allow removal at any time. The owner decides whether that is acceptable.
• OpenAI's terms. OpenAI's rules forbid selling subscriptions or showing upgrade links inside its assistants. Our tools must stay free of plans and checkout links there.
• The registry's terms. The MCP registry dedicates published metadata to the public domain for good. The entry must therefore hold no personal data.
• Wording. The wording "for" an assistant in our descriptions needs each vendor's permission where its trademark rules ask for it; until then descriptions say "works with".

Alternatives considered

• A separate extension for every editor. It would be more code to maintain, only to write the same address into a settings file. The registry entry and install links reach the same people.
• A third-party gateway that hosts the server for us. It would be faster to list, but it would put a company between our customers and us and see their traffic. Rejected.
• The GitHub namespace in the registry. It needs an organisation owner for every publication and says nothing about the domain the server runs on.

Decision

Open. Proposed by the owner on 2026-10-06: the plugin and the server in every assistant, registry and editor, the owner taking every outward step.

Status log

• 2026-10-06: opened, with each channel's requirements read from its primary sources the same day. The Claude Code plugin is built and private (RFC 0040.14); the other manifests, the sign-in tests and the listing texts are next.
• 2026-10-07: Checked: the docs' Claude page (#481) is live in docs-ui at 3a40912a; the plugin is private (RFC 0040.14). Open.