Connect an MCP server.

Who does what

Which kind of connection?

Both can exist for the same service at the same time. They're independent.

Register an organization MCP server

The wizard has three steps. Nothing is saved until you register, except with Sign in now, which saves the server as soon as sign-in completes so the token has somewhere to live.

Step 1 · Connect

Then pick how Kryex authenticates:

Finally choose a grouping model to suggest tool tiers (from Governance → Model gateway → LLM config), or No model — floor only to let the fixed keyword rule decide alone. Either way, you approve every tool. Click Discover tools →.

Step 2 · Discover tools

Kryex lists the server's tools (name and description). Nothing is saved yet. Click Classify tools →. With Sign in now, the server was saved when sign-in finished, but its tools stay quarantined until you activate them; if you close the wizard before sign-in finishes, the half-made server is removed automatically.

Step 3 · Review & register

• Three columns, READ, WRITE and ADMIN. Each tool card shows the AI's suggestion and reason.
• Drag cards between columns, tick several and use Move to, or use the per-card tier menu. ↺ Re-classify re-runs suggestions with another model and never changes anything you've already approved.
• The AI can't propose a tier below the safety floor (a tool named delete_* is at least ADMIN). You can still choose any tier, and you're accountable for it.
• Finish with Register & activate tools → (normal wizard), Activate tools → (after sign-in), or Save (N changes) when regrouping later. Only the tools you register or activate become usable.

The server's page

• Discovered tools shows a badge counting quarantined tools. Approve them here, or use Review in canvas / Regroup in canvas. Moving an active tool to a higher tier asks for confirmation, and existing grants are re-checked on the agent's next turn.
• Refresh discovery re-reads the server's tools. Any tool whose definition changed is re-quarantined until you re-approve it.
• Reconnect sign-in (OAuth servers) signs in again with the same setup when the shared sign-in expired, was revoked or never finished. A banner appears automatically in those cases.
• Disable / Enable turns the whole server off or on for everyone, immediately. Delete removes the server, its tools and stored credentials, and revokes every grant (revoked grants stay in the audit trail).

Give people access

Developers have nothing to do: granted tools appear to the agent automatically. In Auto mode READ tools run without a prompt, while WRITE and ADMIN tools ask first. Approval-held calls wait for an admin under Governance → Connections.

Set up personal connectors

1 · Register provider apps (built-in providers only)

Pick the provider (e.g. GitHub, Atlassian), paste the client ID and secret from the app you registered at the provider, and optionally scopes (blank uses the provider default). At the provider, the app's callback must be https://auth.kryexlabs.com/connectors/<provider>/callback. Connectors that use Automatic or Custom OAuth don't need this page.

2 · Create and publish a connector

Use Start from: GitHub, Atlassian, Linear, Sentry or Notion to pre-fill.

• Identity. A square logo under 145 KB that fills its tile; a name and a slug (the agent calls the connector @slug; lowercase letters, digits and -); a tagline and description users see in Kryex Code.
• Connection. The full MCP server URL including its path (e.g. https://mcp.atlassian.com/v1/mcp), and how people sign in. Automatic (recommended): click Check sign-in and expect “Self-registration: Supported”. Built-in provider: needs its app on OAuth Apps, plus an app install URL for GitHub Apps. Custom OAuth: authorize and token URLs, client ID and secret, client authentication, scopes, and an optional revocation URL used on disconnect.
• Listing. Category, made by, and documentation, support and privacy policy URLs.
• Help & setup. Text shown when someone's sign-in stalls or fails, and the setup each organization's admin must do at the provider (shown to them as a checklist; wrap values in backticks to make them copyable).
• Save, then Publish. For Automatic, saving registers Kryex with the provider (“Kryex registered with …”), or a red message says why it couldn't. Drafts are invisible to users. If people are already connected and you change how the connector signs in, they're asked to reconnect.
• Tools and health. The tool list fills itself on the first connection (or use Refresh tools); set each tool's tier. Test connection checks reachability, sign-in setup and registration, and the health panel shows the 7-day sign-in funnel and open incidents.

3 · Allow, restrict and set up (org admin)

4 · Connect your account (developer)

• Open the connector under Yours or Discover and click Connect. Your browser opens the provider's page; sign in and approve.
• GitHub only: you'll continue to Install on GitHub. Pick the account and choose all repositories, or the ones you want.
• Kryex Code shows Connected. When the browser asks, allow it to open Kryex Code.
• If something goes wrong, Kryex Code shows why and what to do. After 90 seconds it explains what usually blocks a sign-in.
• Reconnect to switch accounts or renew. Disconnect removes your sign-in and revokes it at the provider where supported.

Provider recipes

GitHub — personal connector, GitHub App

Atlassian — Jira & Confluence, Automatic

Linear, Sentry, Notion — Automatic

Start from the template, run Check sign-in, Save, Publish. There's no app to create.

A self-hosted or in-house service

Register it as an organization MCP server with a Custom OAuth provider, or No sign-in plus an API-key header. On the shared hosted service, private-network addresses are blocked: use a public HTTPS address, or a self-hosted Kryex deployment.

Troubleshooting

Evidence for any of the above is in Governance → Audit log, filtered to MCP servers, Connectors or Tool calls, and by user.

Device licenses (self-hosted)

Pin your own Kryex Server

Kryex Code verifies every license signature on the device and, by default, trusts the Kryex Labs signing keys. A self-hosted deployment pins its own server's key in the machine policy file, which only an administrator can write: %ProgramData%\Kryex\policy.json on Windows, /etc/kryex/policy.json on macOS and Linux.

{
  "license_public_keys": [
    "-----BEGIN PUBLIC KEY-----\n…\n-----END PUBLIC KEY-----"
  ]
}

Get the key from your server's /license/public-key, and list both keys during a key rotation. Once pinned, a license from any other server is refused at sign-in with a message naming this setting.

Tamper alerts

If a license on a device is edited, forged or signed by an untrusted key, Kryex Code stops using it and reports it: an email to every active admin of the organization (at most one per device and kind per day), a high-severity License tampering finding on the Security page, and a license.tamper_detected audit event with the device, key id and app version. If it wasn't expected, revoke the device under Kryex Code → Devices; the person signs in again on a clean device.

Next