Connectors

The server from the last piece can talk to an AI, but on its own it does not reach anything useful yet. Connectors are how it reaches the world. A connector is any wiring between the node and something else, and there are two directions: things connecting in, and the node connecting out.

Clients connecting in

These are the AI clients. Claude, ChatGPT, Grok, and command-line tools like Claude Code and Copilot all connect to the same server over a sign-in. The model on the other end does not care what the server is made of; it just sees a set of tools it can call.

The practical part is that one server serves all of them. You connect each client once (the per-client steps are in the docs), and because the chat apps run in a browser, that includes your phone.

The node connecting out

These are the tools, and they are connectors going the other way. The node ships with two real ones:

• an Azure connector, so the AI can look at and manage the node's own resource group,
• a GitHub connector, so it can read code, commit, and trigger its own deploys.

Each outbound connector talks to a real service over its API. The credential it needs lives in the node's vault, never in the code.

Adding your own

A new connector is just a new tool. You wrap a service's API in a small handler, store its key in the vault, and the tool reads that key when it runs. If the key is not set, the tool says so plainly instead of failing in a confusing way. Drop the module in, redeploy, reconnect, and the AI can use it. The full pattern is in the extending guide.

Why this shape

The old way to integrate was a custom adapter per client and per service. Here there is one server in the middle: every client speaks to it the same way, and every service is reached the same way. That is the whole point of the protocol, and it is why the system can keep growing without the wiring turning into a mess.