Runtime Protocols And MCP Support

Purpose

This functional area defines how AI clients communicate with the Runtime.

Main Capabilities

• REST-based tool listing
• REST-based direct invocation
• MCP JSON-RPC 2.0 support
• MCP resource exposure for effective system prompts
• MCP-compliant JSON Schema generation for tool input parameters, including scalar-items array types
• OAuth browser authorization routed through the Portal login experience for runtime clients that use Authorization Code + PKCE

Supported MCP Methods

• initialize
• tools/list
• tools/call
• resources/list
• resources/read

MCP System Prompt Resources

The Runtime exposes toolset system prompts through MCP resources.

The resource payload is not just the raw toolset prompt anymore. It is the effective prompt computed for the requesting tenant and client application.

The effective prompt is composed from:

• the toolset default system prompt
• the client application's system prompt when the toolset assignment enables it
• an optional assignment-specific custom system prompt

Assignment custom prompts support two modes:

• Append — append the custom prompt after the default chain
• Override — replace the full default chain with the custom prompt

This means the same toolset can expose different prompt resources to different client applications within the same tenant.

MCP Schema Generation

The Runtime produces JSON Schema for each tool's input parameters, derived from the mapping's field rules.

The emitted MCP contract is based on ExposedFieldName, not on the raw downstream SourceFieldName. Structural markers from the source path, such as nested objects and [*] array positions, are preserved so the client sees the mapped business vocabulary without losing payload shape fidelity.

This schema generation is protocol-aware. Tools sourced from SOAP/WSDL contracts still expose standard MCP JSON Schema, while the Runtime keeps SOAP-specific invocation metadata behind the tool definition.

Array fields are handled as follows:

• Fields whose type is array include an items node that describes the element type (e.g. "integer", "string").
• Array leaf fields (e.g. a field path ending in [*]) carry the items type from the ArrayItemType property on the field rule. When no item type is specified, the schema defaults to "string".
• Object-typed fields with additionalProperties pass that schema through unchanged.

The Runtime now supports three MCP schema discovery modes:

• Full — the emitted schema includes descriptions and format hints for the exposed field contract
• DataStructureOnly — the emitted schema keeps only structural information needed by MCP binders: exposed field names, object nesting, array items, additionalProperties, and required flags
• Lazy — the emitted schema exposes only the _schema_discovery placeholder field and requires discovery before invocation

DataStructureOnly is implemented by stripping human-readable metadata from the generated schema tree while preserving the JSON Schema structure used by client-side parameter binders.

discover_tool_schema Meta-tool

When any visible tool uses Lazy or DataStructureOnly, the Runtime injects the discover_tool_schema MCP meta-tool into tools/list.

Functionally, this meta-tool:

• accepts a tool_id
• returns the authoritative full inputSchema
• returns the full outputSchema when present
• returns a schema version and schema hash so a caller can reason about schema freshness

Schema discovery activity is also represented in governance call monitoring as a distinct call type, separate from normal tool execution and resource reads.

MCP Invocation Semantics For Discovery

Tools whose inputSchema includes _schema_discovery are expected to be hydrated before first use unless the caller already retrieved and retained the full schema definition in the current conversation.

At invocation time the Runtime applies two important rules:

• if _schema_discovery is the only argument, the Runtime rejects the call and instructs the caller to use discover_tool_schema first
• if _schema_discovery appears alongside real arguments, the Runtime removes it before forwarding the request to downstream execution

For real invocations, the Runtime also translates the request payload from ExposedFieldName to SourceFieldName before building the downstream HTTP request, and translates the downstream response back from SourceFieldName to ExposedFieldName before returning the MCP result.

tools/list Response Logging

When request/response logging is enabled for at least one tool in the catalog, the tools/list response payload is captured as an audit dimension alongside the discovery call. This makes the exact tool contract visible to platform operators for audit and debugging.

Functional Value

This area makes the platform usable by both direct HTTP clients and MCP-capable AI systems.

For browser-capable clients, that usability now extends to a first-class Portal-hosted authorization journey that supports external identity providers, MFA, and an explicit operator confirmation step before runtime access is granted.