Docs

MCP Fusion/Protocol and runtime/Introspection

Introspection

Ask AI about Vinkius

Make a connector describe itself: the server card at the well-known path, the RBAC-filtered mcpfusion manifest, per-action metadata and the contracts behind the lockfile.

A connector that can describe itself is easier to run, audit and integrate. MCP Fusion exposes three introspection surfaces: a static server card, a live dynamic manifest and an in-process metadata API.

The server card

Served at /.well-known/mcp/server-card.json on http and stateless, compiled once at startup:

json
{
  "$schema": "https://modelcontextprotocol.io/schemas/server-card/v1",
  "version": "1.0",
  "protocolVersion": "2026-07-28",
  "serverInfo": { "name": "billing", "version": "1.4.0", "title": "Billing connector" },
  "transport": { "type": "streamable-http", "endpoint": "/mcp" },
  "capabilities": { "tools": {}, "prompts": {}, "resources": {} },
  "tools": [{ "name": "billing", "description": "...", "tags": ["finance"] }]
}

Capabilities are populated from what the server actually registered, so the card cannot advertise a surface that does not exist. It is served read-only, with no session and a public five-minute cache header. Discovery clients and monitoring systems read it without ever opening an MCP connection.

The dynamic manifest

Enable it and the connector publishes a resource describing itself:

typescript
attachToServer(server, {
  introspection: {
    enabled: true,
    uri: 'mcpfusion://manifest.json',
    filter: (manifest, ctx) => stripInternal(manifest, ctx.userRole),
  },
});

The manifest carries the server identity, the MVA architecture marker, and per tool: actions, destructive and read-only flags, required fields, and per Presenter the schema keys, supported UI block types and whether rules are contextual. Unlike the static card, the manifest is read through the MCP connection, which means it is filtered per session: the filter receives the manifest and the request context and returns what that session may see. Role-based discovery is therefore a function, not a separate endpoint.

Use the manifest when agents should self-orient: an agent can read mcpfusion://manifest.json first and plan against the exact surface it is entitled to.

Metadata in process

The registry answers questions about its own surface without a wire round trip:

typescript
for (const builder of registry.getBuilders()) {
  console.log(builder.getName(), builder.getActionNames());
  for (const action of builder.getActionMetadata()) {
    console.log(action.actionName, action.destructive, action.requiredFields);
    console.log(action.hasMiddleware, action.presenterName);
    console.log(action.presenterSchemaKeys, action.presenterUiBlockTypes);
  }
}

This is the same material the contract compiler consumes, which is why the CLI can print your surface, the lockfile can hash it and an admin dashboard can render it: one source, three consumers.

Contracts and digests

Each tool materializes into a ToolContract with surface, behavior, token economics and entitlements sections, each hashed. computeServerDigest() composes them into a server digest; compareServerDigests() tells you whether two deployments are behaviorally identical. The lockfile writes exactly this material to disk. See Contracts for the schema and the CI gate.

Why it matters operationally

  • Onboarding: a new client reads the card and knows the transport and endpoint before connecting
  • Least privilege: the manifest filter makes capability visibility a runtime decision per role
  • Auditing: the contract digest is the artifact a reviewer signs, not a screenshot of a dashboard
  • Regression detection: comparing digests across releases answers "did behavior change" without reading a diff of your whole repository

Next steps