ScaiLink

ScaiLink is the MCP-side bridge for ScaiGrid agents. It does two related things from the same module: it gives a user's desktop a way to expose local MCP servers (filesystem, shell, git, custom tools) to ScaiGrid over an authenticated WebSocket, and it lets users or tenant admins register hosted MCP servers (Notion, GitHub, an internal SaaS) once and have their tools surface platform-wide.

ScaiGrid's agents see both surfaces as ordinary MCP tools. The desktop bridge enforces explicit user consent on each new invocation; the cloud registry forwards calls under stored credentials and surfaces health, rotation reminders, and a per-tenant cap.

When to use it#

Your agent needs to read or write files on a specific user's machine, with the user explicitly approving each new touchpoint.
You want to register a SaaS MCP server (yours or a third party's) once and have every ScaiGrid app — chat, agent runs, internal tooling — see its tools.
You want a single audit log for both local tool calls and outbound calls to hosted MCP servers.
You need credential rotation reminders, health-check cycling, and namespacing for tools from many different servers.

If you only need a single agent talking to a single tool, you don't need ScaiLink — call MCP directly. ScaiLink earns its place when many users, many tools, and many MCP servers are in play.

What you get#

Desktop bridge:

Authenticated WebSocket at wss://scaigrid.scailabs.ai/v1/scailink/ws. The user's desktop client opens it with their JWT and registers an MCP capability catalog.
Per-tool consent. First-time and out-of-policy invocations prompt the user with the exact arguments before the call runs.
Session resumption. A 120-second grace period bridges short network blips without dropping the catalog.
Audit log. Every invocation is recorded with arguments, result summary, decision, and timestamp.

Cloud MCP registry (v1.1+):

Hosted-server registration by URL + credentials, personal or tenant-shared scope.
Encrypted credentials. AES-256-GCM at rest; write-only via the API.
Automatic discovery. Tools, resources, and prompts surface in the platform /mcp catalog under a namespaced name.
Health-check cron every 15 minutes; three consecutive failures de-list a broken server until it recovers.
Session pool keeps (user, server) MCP sessions warm for five minutes so repeat calls skip the handshake.
Rotation reminders at 90 days on the oldest credential.

Two-minute mental model#

You manage two surfaces in one module:

A session is a connected desktop client — a user, a device, a set of registered local capabilities.
A remote server is a registered cloud MCP endpoint — URL plus credentials, personal or tenant-shared.

Agents invoke either surface as if it were a single MCP catalog. ScaiLink routes the call to the right place — pushing a scailink/tool_invoke frame over the WebSocket for desktop tools, or opening (and reusing) an outbound MCP session for cloud-registered tools.

ScaiLink sits next to a few neighbouring modules. The differences:

ScaiBunker gives an agent a platform-controlled sandbox — files and shell that ScaiGrid hosts. ScaiLink gives an agent scoped access to the user's environment or the user's chosen hosted MCP server. The two are complementary: an agent can use both.
ScaiMCP is the platform-wide MCP aggregation layer. ScaiLink feeds its catalog: desktop sessions contribute device-local tools, cloud registrations contribute hosted tools. From an MCP client's perspective both are just tools in /mcp.
Direct MCP from your agent skips all of this. You lose the audit, the rotation, the namespacing, the consent UI, the health cycling — fine for one tool and one user, painful at any larger scale.

Permissions at a glance#

The desktop bridge uses scailink:view, scailink:invoke, scailink:manage, scailink:audit. The cloud registry adds three tiers: scailink:remote.use to discover and call registered tools, scailink:remote.manage_own to manage personal servers, scailink:remote.manage_tenant for tenant-shared servers. Admin roles get all of these automatically; for tenant_user / tenant_viewer the cloud-registry perms are default-deny and tenant admins enable them per group via custom roles. See Permissions.

Two ways to invoke#

Once tools are in the catalog, an agent can reach them two ways. The desktop bridge exposes a REST surface — POST /v1/modules/scailink/users/{user_id}/tools/{tool_name}/invoke — which pushes the call over the open WebSocket and waits for the response. Anything that already speaks MCP, meanwhile, picks ScaiLink-surfaced tools up automatically through ScaiMCP, with no ScaiLink-specific code on the consumer side. Both paths feed the same audit log.

Audit and observability#

Every tool call, resource read, prompt get, registration, refresh, and credential rotation lands in mod_scailink_audit_log. The audit endpoints expose the events both per-tenant and per-user; the admin UI renders them as a searchable timeline. Desktop sessions carry their own audit_detail_level chosen at handshake (full, metadata, or off), so a privacy-sensitive workflow can opt down to action skeletons while a forensic workflow opts up to full request and response bodies.

Both surfaces feed the same audit pipeline, so a single query gives you "everything ScaiLink did on behalf of this user in the last 24 hours" regardless of which surface served the call.

The admin UI exposes three pages under the ScaiLink nav: a dashboard of connected sessions, a list of cloud MCP servers with rotation chips and health streaks, and the audit timeline.

Where to go next#

Quickstart — register a hosted MCP server and invoke one of its tools in five minutes.
Architecture — how the desktop bridge, cloud registry, and /mcp aggregation fit together.
Cloud MCP registry — scope, naming, credentials, health, session pool.
API reference — every endpoint, request, response.
Register a cloud MCP server — full walkthrough.
Run a desktop session — bridge a local MCP server to ScaiGrid.

ScaiLink's module ID inside ScaiGrid is scailink; its REST API is mounted at /v1/modules/scailink/ and the desktop WebSocket at /v1/scailink/ws.