Decision question and scope

Reference patterns for local, remote, hybrid and domain-oriented MCP landscapes.

The analysis starts with a bounded user task and compares MCP with a direct API or deterministic workflow. A working demonstration is not evidence of production readiness.

Architecture and responsibilities

The assessment identifies the host, one client relationship per server, MCP servers, authorization boundaries and authoritative travel systems. MCP standardizes capability interaction; it does not supply inventory, pricing, order semantics or business authorization.

Assessment dimensions

Each dimension requires an owner, evidence, test date and explicit boundary.

  • Host und Client
  • Domänenserver
  • Gateway und Autorisierung
  • Fachsysteme
  • Observability und Betrieb

Travel case

Ein Travel-Gateway kann Richtlinien und Discovery bündeln, während getrennte Server für Produkt, Order, Profil und Zahlung ihre Fachrechte behalten.

The case is complete only when source provenance, state transitions, permissions, expiry, partial failure and recovery are documented.

Evidence and failure analysis

Required evidence includes versioned contracts, negative authorization and schema tests, authoritative state reconciliation, measurable service objectives and a controlled shutdown path. Registry or publisher metadata alone is not a security or compatibility finding.

Outcome

Diagramme, Einsatzbedingungen, Vorteile, Nachteile und typische Fehlanwendungen werden je Muster gegenübergestellt.

The result must state assumptions, unresolved risks and conditions under which MCP is not the appropriate integration choice.

Primary sources and academic context

This page follows the versioned MCP specification and separates normative requirements from architectural recommendations.