End-to-End Request Flow and Trust Boundaries

Learning objectives

• Trace the exact flow from the user's prompt to the final answer.
• Understand the difference between a model request and actual tool execution.
• Identify validation requirements at every boundary.

sequenceDiagram
  actor User
  participant Host
  participant Model
  participant Client as MCP Client
  participant Server as MCP Server
  participant Service as Order Service
  User->>Host: Where is ORD-101?
  Host->>Model: Prompt + available tool schemas
  Model-->>Host: Request lookup_order
  Host->>Host: Consent and policy check
  Host->>Client: Call tool with arguments
  Client->>Server: tools/call
  Server->>Server: Validate identity and input
  Server->>Service: getOrder(userId, orderId)
  Service-->>Server: Authorized result
  Server-->>Client: Structured tool result
  Client-->>Host: Result
  Host->>Model: Tool result as untrusted context
  Model-->>Host: User-facing explanation
  Host-->>User: Order is shipped

Important boundaries

1. The model suggests a tool call; the host decides whether to execute it.
2. The host handles consent, policy, and connection orchestration.
3. The server validates the schema, identity, authorization, and business rules.
4. Tool output is untrusted data. The host must prevent output text from silently changing policy.

Common mistake

“The model supplied the correct user ID” is not proof of authorization. Identity must come from a trusted session or token, not from a model-generated argument.

Interview answer

“I keep the model outside the trust boundary. The host approves execution, the MCP server validates input and identity, and the domain service enforces record-level authorization.”