Portal Toolset And Client Application Management

Purpose

This functional area controls how published mappings are packaged and exposed to actual AI consumers.

It connects mapping output to the client applications that are allowed to use it.

Main Capabilities

• create and manage MCP toolsets
• select which endpoints are exposed as tools
• define an optional default system prompt at toolset level
• configure request/response payload logging per toolset and per endpoint
• assign toolsets to client applications
• manage tenant-scoped client applications
• define an optional client-level system prompt
• choose prompt composition per toolset assignment
• manage application API keys

MCP Toolsets

Toolsets are the publication grouping used to expose mappings to AI clients.

Functionally, administrators can use toolsets to:

• bundle selected endpoints into a discoverable set
• apply business-friendly tool naming
• maintain prompt-related metadata and default AI instructions
• decide which published functionality becomes visible at runtime

When a selected endpoint is exposed through a toolset, the Runtime presents the endpoint's mapped ExposedFieldName values to AI clients. The raw SourceFieldName values remain an internal runtime concern used only for downstream request and response translation.

Toolsets can now carry an optional default system prompt. This prompt becomes the base instruction set exposed to MCP-capable AI clients for the toolset.

System Prompt Composition

Prompt behavior is controlled across three layers:

• the toolset default system prompt
• the client application system prompt
• an optional assignment-specific custom system prompt

For each client application assigned to a toolset, administrators can choose whether the client application's own system prompt should participate in the effective prompt for that toolset.

They can also enable a custom prompt on the assignment and decide whether it should:

• append to the default prompt chain
• override the full default prompt chain

Functionally this allows:

• a shared toolset prompt for all consumers
• per-client default instructions when a client needs stable behavior across multiple toolsets
• toolset-specific per-client prompt customization when a single consumer needs special behavior for one toolset only

Endpoint Exposure

Not every endpoint in a mapping needs to become an exposed tool.

This area lets administrators decide:

• which endpoints are included
• how they are presented
• which runtime-visible tool identifiers are produced

This keeps the runtime catalog intentional and curated.

Schema Discovery Configuration

Toolset administrators can control how much schema detail is sent to AI clients during tools/list.

At toolset level, the Portal now supports three schema discovery modes:

• Full — send the complete schema with descriptions and format hints
• Data Structure Only — send the real exposed schema structure but omit descriptions and format hints to reduce token cost
• Lazy — send only a placeholder schema and require discovery before invocation

Each included endpoint can override the toolset default. When no endpoint override is configured, the Runtime uses the toolset default for that endpoint automatically.

The toolset editor makes this explicit by showing the effective mode for each endpoint and by allowing endpoint overrides to be reset back to the toolset default in one action.

Discovery Guidance In Portal UX

The Portal guides administrators about the runtime impact of each discovery mode:

• Full favors immediate clarity at the highest token cost
• Data Structure Only remains compatible with standard MCP client binders because real parameter names and types are still sent
• Lazy is explicitly called out as requiring non-standard clients because standard MCP binders expect a real schema at discovery time

For endpoint-level overrides, the editor shows the effective discovery mode derived from either the override or the toolset default so administrators can review mixed configurations safely.

Request And Response Payload Logging

Toolsets support configurable request/response payload capture for governance purposes.

This configuration controls whether the Runtime captures and stores request and response payload data in audit records when tools from the toolset are invoked.

Configurable options include:

• whether payload logging is enabled for the toolset (disabled by default)
• the maximum payload size to capture per dimension (default 512 KB)
• per-endpoint overrides that enable or disable logging for individual tools independently of the toolset default

When enabled, captured payloads are sanitized before storage to remove sensitive values such as authorization headers, tokens, API keys, secrets, and passwords. Content that exceeds the configured size limit is truncated.

This feature is useful for debugging, compliance requirements, or operational review of AI-driven tool invocations, but should be enabled deliberately given the sensitivity of payload content.

Duplicate Endpoint Exposure Warning

When creating or editing a toolset, the Portal checks whether the current configuration would result in the same endpoint being exposed to the same client application through more than one toolset.

If an overlap is detected, the Portal shows a warning banner in the toolset editor identifying the other toolsets that share both a client application and at least one endpoint. A warning icon also appears in the modal title.

This matters because when two toolsets expose the same endpoint to the same consumer and both governing policies pass at runtime, the AI client sees duplicate entries in tools/list, which can lead to unpredictable tool selection behavior.

The warning is advisory. Administrators can choose to proceed, for example when the governing policies on the shared endpoints are mutually exclusive by design.

Client Applications

Client applications represent consuming systems or AI clients.

Administrators can:

• create client applications
• manage client application metadata
• define an optional client application system prompt
• activate or deactivate client applications
• associate toolsets with the correct consumers

Because client application prompt changes affect runtime prompt composition, saving a client application also updates runtime configuration state and invalidates the related runtime snapshots.

Application API Keys

The Portal also supports lifecycle management for application API keys.

Functionally this includes:

• API key creation
• metadata and expiration management
• API key revocation
• API key deletion
• claim-oriented access shaping through roles, scopes, groups, and custom claims

Operational Importance

This area is the publication control point between internal mapping design and external runtime consumption.

It determines which AI clients can see which tools and under what application identity.