Named services can now leave KDCube through a delegated MCP connector

Your Claude. Your KDCube memories. Now they can meet — safely.

A KDCube app realm like memory has always been reachable inside the platform: ReAct, widgets, scene, canvas, and pinboard all read it through one generic named-service interface (search, get, about, schema). The new thing is that the same interface now has an external door: a user's own MCP client — their Claude — can reach a KDCube named-service realm from outside, over an authenticated MCP connector, using a delegated credential.

The realm becomes agent-portable. Nothing about it was rebuilt for the outside world; a new consumer was added to the same provider.

This is the literal payoff of the three memory realms close: portable memory. The durable memory realm is the first realm to walk out through this door.

The whole idea in one line

Everything under that sentence is machinery the rest of the Connection Hub series already covered, and this Short just points at it:

• the door is authenticated MCP — discovery → consent → delegated credential → tools/call (see Authenticated MCP: Delegated Credentials, Not Shared Secrets);
• the guard checks every call — resource, tool, grants, consent, before product code (see Protecting KDCube Surfaces With Managed Credentials);
• the bearer is a delegated credential, not a shared secret — scoped, recorded, per-user, revocable (same);
• the external agent stays its own actor, reaching the grantor's data through an explicit edge (see Connected Identities Are Not One User Id).

The named-service realm doesn't need to know any of that. It exposes about, schema, search, get the same way it always has; the connector and the guard sit in front.

What ships today, and what is the pattern

Be precise about the state, because "reachable in principle" and "wired today" are different things.

The shipped external connector today is the memory realm: the user-memories@2026-06-26 bundle exposes an MCP surface with memory_search and memory_get, each declaring the grant it needs (memories:read) and reading only the approving user's memories — widened to the user's linked identities when Connection Hub identity-family reads are available.

task and cnv are the same pattern: any named-service namespace can be placed behind the generic bridge and given per-operation grants. The generic named_services MCP surface exists in the kdcube-services@1-0 example and is namespace-agnostic by design — it serves whatever namespaces the delegated-credential resource catalog configures. What it does not do yet in the shipped example config is wire a live mem/task/cnv namespace catalog for external consent. So: memory is the first realm out the door; the others are next of the same kind.

Two boundaries, not one

A generic connector is broad by shape — one URL, generic tools like named_services_search. So the boundary has to become specific twice: at the connector, and again at the namespace.

named_services_search(namespace="mem")
        |
        v
outer door:      is named_services_search consented?  named_services:use present?
        |
        v
namespace door:  is mem configured?  is object.search allowed?  memories:read present?
        |
        v
dispatch to the memory provider

The inner grant is what keeps a broad connector honest: reaching mem needs memories:read; writing needs memories:write; a different realm needs its own grant. If the credential lacks the namespace grant, the bridge returns a structured delegated_consent_required result naming the missing grant rather than failing silently.

Why it matters

A named-service realm was built once, by its owner, with its own schema and search. Adding an external agent as a consumer did not fork it, re-expose it, or teach the outside agent its private API. The realm stayed the owner of meaning; the platform added a guarded door in front.

That is the shape of agent-portable realms: build the realm once, and let both the resident agent and the user's own agent reach it — each through the boundary that fits, neither learning the other's secrets. Memory walked out first. The door is the same for whatever realm goes next.

Related publications

Documentation on GitHub

The live docs and code behind this entry:

• Recipe — protect a bundle MCP with managed credentials
• OAuth delegated-credential protocol adapter
• Named services — overview