Runtime Configuration Snapshots

Purpose

This functional area composes live runtime behavior from administrative configuration.

It is responsible for loading, caching, and invalidating the full execution configuration needed for each tenant and client application, so the Runtime can behave as a stable and pre-composed execution layer.

Main Capabilities

• build tenant and client-specific snapshots
• combine mappings, toolsets, policies, and downstream settings
• cache snapshots to keep tool invocation fast
• invalidate snapshots automatically when configuration changes
• deduplicate concurrent snapshot builds for the same key

Snapshot Content

Runtime snapshots combine:

• published mappings
• MCP toolsets
• client application assignments
• client application prompt metadata
• target systems
• authentication profiles
• credential workflow definitions
• tool access policies

Snapshot Scope

Snapshots are scoped per tenant and per client application.

This means:

• different client applications within the same tenant can see different toolset visibility
• different client applications within the same tenant can resolve different effective MCP system prompts
• toolsets are filtered to those assigned to the requesting client application
• each combination has its own cache entry and invalidation lifecycle

Snapshot Caching

The Runtime keeps an in-memory snapshot of each tenant and client application's execution configuration so that tool discovery and invocation do not need to recompute it, or query the database, on every request.

Characteristics:

• fast local access for every request served by a Runtime instance
• entries persist until they are invalidated, rather than expiring on a fixed schedule
• snapshot builds for the same tenant/client key are deduplicated, so concurrent requests never trigger duplicate rebuild work

Snapshots are also mirrored in the platform's distributed cache, so a snapshot survives an individual Runtime instance restarting and can be reused across instances in a multi-instance deployment rather than every instance rebuilding it independently from the database.

Cache behavior is configurable per deployment, including whether snapshot caching is enabled at all, how long a cached snapshot is kept before it unconditionally expires (24 hours by default), and how long a resolved set of credentials is kept cached separately from the rest of the snapshot (5 minutes by default, reflecting that credentials should refresh more often than the broader configuration they are used with).

Cache Invalidation

When administrative configuration changes in the Portal — a mapping is published, a toolset is updated, a policy changes, and similar — the Runtime is notified and rebuilds only the affected tenant and client application snapshots. This keeps published changes visible quickly without requiring every snapshot to be rebuilt.

Client application changes are snapshot-affecting events. This includes changes to client metadata that influence effective MCP prompt composition, such as the client application's optional system prompt.

The same configuration-changed event that triggers a tenant-scoped snapshot invalidation also pushes a notifications/tools/list_changed MCP notification (via McpToolsListChangedNotifier.NotifyAsync, invoked from RuntimeConfigurationChangedConsumer) to any of that tenant's MCP sessions with an open SSE stream, so already-connected clients learn their tool catalog changed without waiting to re-poll tools/list.

The Runtime also supports an alternative invalidation strategy for deployments that prefer to detect configuration changes by checking for updates directly, rather than relying on change notifications, so a consistent snapshot view is maintained either way.

Functional Value

This area gives the Runtime a predictable execution model and keeps configuration-driven behavior consistent across requests, tenants, and deployment scenarios.