MCP Deep Dive (v2.0.9)

This page shows the exact MCP execution order using the confirmation-first Loan Application flow.

Exact phase order in the confirmation-first loan flow

1. SchemaExtractionStep completes field extraction.
2. POST_SCHEMA_EXTRACTION rules can move the flow into CONFIRMATION.
3. CorrectionStep can patch edits or set routing_decision=PROCEED_CONFIRMED.
4. PRE_AGENT_MCP rules run inside McpToolStep before planner/tool execution and can move CONFIRMATION -> PROCESS_APPLICATION.
5. POST_AGENT_MCP rules run after MCP work finishes.
6. PRE_RESPONSE_RESOLUTION rules run next.
7. ResponseResolutionStep runs after both rule passes.

So yes, MCP turns can now be shaped by both the new pre-MCP phase and the existing post-MCP / pre-response phases.

Prompt-template interaction semantics

ce_prompt_template now carries two fields that consumers should treat as the canonical turn contract:

• interaction_mode: broad semantics for the turn (COLLECT, CONFIRM, PROCESSING, FINAL, and related modes)
• interaction_contract: extensible JSON for concrete capabilities and expectations

Recommended interaction_mode values:

• NORMAL: generic prompt with no special turn contract
• IDLE: waiting for the user to begin or restate the task
• COLLECT: gather missing required fields
• CONFIRM: allow affirm/edit over already-collected values
• PROCESSING: keep work in progress; retry can be enabled here
• FINAL: terminal response branch
• ERROR: failure branch
• DISAMBIGUATE: ask the user to choose between options
• FOLLOW_UP: follow-up question branch
• PENDING_ACTION: approval/pending-action branch
• REVIEW: evidence review branch

Recommended interaction_contract shape:

{"allows":["affirm","edit","retry","reset"],"expects":["structured_input"]}

Current conventions:

• allows: turn capabilities such as affirm, edit, retry, reset
• expects: input expectations such as structured_input

This is the preferred place to model confirmation and retry semantics. Do not rely on state name substrings such as CONFIRM.

Guardrail blocked path

For MCP_STATUS=GUARDRAIL_BLOCKED_NEXT_TOOL:

1. McpToolStep writes McpConstants.FALLBACK_GUARDRAIL_BLOCKED to context.mcp.finalAnswer.
2. POST_AGENT_MCP rules run.
3. PRE_RESPONSE_RESOLUTION rules run.
4. ce_response + ce_prompt_template still shape final user text.

Example 3: Confirmation-first Loan Application

Chat + Internal Trace

Turn 1 - User

I need a loan for my customer. Customer id 1234, 35000, 24 months.

Info

• Intent resolves to LOAN_APPLICATION.
• State enters ELIGIBILITY_GATE and schema extraction runs.

Turn 1 - Assistant

Please confirm: customerId 1234, requestedAmount 35000, tenureMonths 24. Proceed?

{}

{
  "routing_decision": "CONTINUE_STANDARD_FLOW",
  "state": "CONFIRMATION"
}

Tables

• ce_output_schema (R)
• ce_rule (POST_SCHEMA_EXTRACTION)
• ce_audit (W)

Info

• Schema is complete, so POST_SCHEMA_EXTRACTION moves ELIGIBILITY_GATE -> CONFIRMATION.

Turn 2 - User

Oh wait, change amount to 350000.

Info

• DialogueActStep resolves EDIT.
• CorrectionStep patches only requestedAmount and keeps state in CONFIRMATION.

Turn 2 - Assistant

Updated. Please confirm: customerId 1234, requestedAmount 350000, tenureMonths 24. Proceed?

{}

{
  "routing_decision": "APPLY_CORRECTION",
  "correction_applied": true,
  "correction_target_field": "requestedAmount",
  "state": "CONFIRMATION"
}

Tables

• ce_audit (W)

Info

• No full schema re-extraction is needed for the single-field correction path.

Turn 3 - User

Looks good, go ahead.

Info

• DialogueActStep resolves AFFIRM.
• CorrectionStep sets routing_decision=PROCEED_CONFIRMED.

Turn 3 - Internal MCP Loop

PRE_AGENT_MCP moves state to PROCESS_APPLICATION. Planner executes rating -> fraud -> debt -> submit.

{}

{
  "mcp": {
    "observations": [
      {
        "toolCode": "loan.credit.rating.check",
        "json": "{\"creditRating\":782}"
      },
      {
        "toolCode": "loan.credit.fraud.check",
        "json": "{\"flagged\":false}"
      },
      {
        "toolCode": "loan.debt.credit.summary",
        "json": "{\"dti\":0.31,\"availableCredit\":220000}"
      },
      {
        "toolCode": "loan.application.submit",
        "json": "{\"applicationId\":\"LA-90311\",\"status\":\"SUBMITTED\"}"
      }
    ],
    "lifecycle": {
      "phase": "POST_AGENT_MCP",
      "status": "TOOL_RESULT",
      "outcome": "IN_PROGRESS",
      "finished": false,
      "toolExecuted": true,
      "lastToolCode": "loan.application.submit"
    }
  }
}

Tables

• ce_rule (PRE_AGENT_MCP)
• ce_mcp_tool (R)
• ce_mcp_planner (R)
• ce_audit (W)

Info

• Tool results append to context.mcp.observations after CONFIRMATION -> PROCESS_APPLICATION.

Turn 3 - Rules + Final

Loan application submitted for customer 1234. Amount 350000, tenure 24 months. Application ID LA-90311.

{}

{
  "mcp": {
    "finalAnswer": "Loan approved and submitted with applicationId LA-90311.",
    "lifecycle": {
      "phase": "POST_AGENT_MCP",
      "status": "ANSWER",
      "outcome": "ANSWERED",
      "finished": true,
      "blocked": false,
      "error": false
    }
  },
  "state": "COMPLETED"
}

Tables

• ce_rule (R)
• ce_response (R)
• ce_prompt_template (R)
• ce_conversation (W)

Info

• POST_AGENT_MCP can move PROCESS_APPLICATION -> COMPLETED using JSON_PATH on context.mcp.finalAnswer.
• PRE_RESPONSE_RESOLUTION runs after that and can still apply final state/context adjustments.

Step Graph

Loan MCP flow

Schema -> CONFIRMATION -> PRE_AGENT_MCP -> planner/tool loop -> POST_AGENT_MCP -> PRE_RESPONSE_RESOLUTION -> response

Execution Steps

Press enter or space to select a node.You can then use the arrow keys to move the node around. Press delete to remove it and escape to cancel.

Press enter or space to select an edge. You can then press delete to remove it or escape to cancel.

Step Detail

CONFIRMATION

CORRECTION

CorrectionStep handles edits in place and routes affirmations forward with routing_decision.

Session Snapshot

• routing_decision
• skip_schema_extraction

Tables Touched

• ce_audit (W)

Turn Table

Table impact by stage

Stage	Reads	Writes	Context impact
Intent/State	ce_intent, ce_intent_classifier, ce_rule	ce_audit	session.intent/session.state
Schema + confirm gate	ce_output_schema, ce_prompt_template, ce_rule	ce_audit	state=CONFIRMATION, routing_decision
PRE_AGENT_MCP	ce_rule	ce_audit	CONFIRMATION -> PROCESS_APPLICATION
MCP planner	ce_mcp_tool, ce_mcp_planner	ce_audit	mcp_action/mcp_tool_code
Tool execution	(tool-specific)	ce_audit	context.mcp.observations[]
Planner ANSWER	ce_mcp_planner	ce_audit	context.mcp.finalAnswer + lifecycle
POST_AGENT_MCP	ce_rule	ce_audit	MCP-driven transition
PRE_RESPONSE_RESOLUTION	ce_rule	ce_audit	Final pre-response transition
Response resolution	ce_response, ce_prompt_template	ce_audit, ce_conversation	assistant payload

Direct Tool Mode

Direct tool request

JSON

{
  "tool_request": {
    "tool_code": "loan.credit.rating.check",
    "tool_group": "HTTP_API",
    "args": {
      "customerId": "CUST-1001"
    }
  }
}

`POST_TOOL_EXECUTION` sequence

Step	What happens
ToolOrchestrationStep	Executes exactly one tool and writes inputParams.tool_result.
Context metadata	Writes context.mcp.toolExecution with status/outcome/meta/result.
Rules	Runs `POST_TOOL_EXECUTION` rules for direct-tool mode.
RulesStep	Runs `PRE_RESPONSE_RESOLUTION` rules before response resolution.
Response	ResponseResolutionStep uses final state/context.

Rule-ready JSON_PATH recipes

$[?(@.context.mcp.lifecycle.finished == true && @.context.mcp.lifecycle.outcome == 'BLOCKED')]
$[?(@.context.mcp.lifecycle.error == true)]
$[?(@.context.mcp.toolExecution.phase == 'POST_TOOL_EXECUTION' && @.context.mcp.toolExecution.status == 'SUCCESS')]
$[?(@.context.mcp.toolExecution.scopeMismatch == true)]

Recommended production pattern

Use ce_rule for deterministic transitions and keep final wording in ce_response/ce_prompt_template. Use context.mcp.* as rule evidence, then let response resolution produce final output.