Campus account MCP

Campus MCP is the generic discovery, admission, and routing surface for capabilities published by installed apps. Publishing a first-party app by default does not make its tools CampusOS tools.

Responsibility model

Every invocation has four independent attributes:

Attribute	Meaning
Contract owner	The app manifest that owns the qualified name, schemas, version, and semantics
Caller authority	The exact installation grant and exposure/audience rule that admit this caller
Executor	The owning workload, or an owner-local browser origin for an explicitly browser-backed tool
Transport	CampusOS/Gateway routing used to reach that executor

CampusOS owns catalog assembly, qualified-name validation, JSON Schema bounds, installation identity, permission checks, generic audience admission, routing, timeouts, and metadata-only audit. It does not own an app tool because it carries the invocation.

Invariants

1. Product tools are declared by the product package and use that package's qualified namespace.
2. Application MCP transports are workload or browser. Catalog validation rejects transport: service.
3. CampusOS has no in-process product executor, reviewed product handler, or app fallback.
4. Executor selection never retries an effect through a different implementation.
5. If the owning workload or browser executor is unavailable, the tool is unavailable.
6. Tool input and output are bounded by the package schemas before and after routing.
7. Exposure changes who may call a tool; it never changes who owns or executes it.
8. Public, selected-account, app-owned-audience, owner-local, and scheduled calls all invoke the same app-owned contract under different generic admission rules.
9. Principal-held signing secrets remain with the principal that owns them. MCP routing cannot acquire or emulate that authority.
10. Discovery metadata may outlive a stopped workload, but successful execution may not.

CampusOS MCP tools

CampusOS publishes only generic platform operations:

• campus.open-app, campus.app-status, campus.list-apps, and campus.launch-app;
• campus.create-app, campus.search-apps, campus.install-app, and campus.uninstall-app;
• campus.call-app-agent for a target app's declared Agent entry point;
• campus.schedule-notification for generic scheduled notification delivery.

Calls, Calendar, Contacts, Drop, Mail, Messages, Wallet, and other products publish their own tools. Examples include campus-contacts.resolve, campus-calendar.availability, campus-drop.status, campus-matrix.send-direct, and campus-wallet.balance. Their names remain app-owned even when a Campus-authored client calls them.

Workload invocation

1. The caller searches the account or public catalog.
2. CampusOS filters results by installation state, declared call/serve permissions, exposure, and generic audience membership.
3. The caller invokes the exact qualified name with bounded arguments.
4. CampusOS repeats admission and schema validation, then routes through the target installation's Gateway to its workload MCP ingress.
5. The workload performs the operation and returns its app-owned result.
6. CampusOS validates the result schema and records routing metadata without persisting arguments, results, or product state.

An automatic lifecycle policy may permit CampusOS to start the target workload before routing. That is generic lifecycle behavior, not a second executor. A startup failure, stopped/manual workload, app timeout, or workload error is returned as failure; CampusOS does not perform the app operation.

Browser invocation

Browser tools are owner-local. The trusted shell verifies the same exact grants, mounts the provider origin, and transfers a MessageChannel port between the caller and provider frames. Arguments and results travel between app origins and are not proxied into an OS product handler. Browser tools are not exposed as cross-account or anonymous HTTP MCP endpoints.

App SDK use

Apps invoke published tools through the domain-neutral SDK:

const result = await campus.mcp.call({
  name: 'campus-contacts.resolve',
  arguments: { query: 'Alice' },
})

if (result.resultType !== 'complete') {
  // The app decides how to present its own incomplete or failed workflow.
}

Friendly product wrappers belong in the owning app source, not CampusSDK. See CAMPUS_OS_BOUNDARY.md for the complete OS inclusion test.