App Server vs MCP, and the Claude-Side Equivalent: Three Boundaries for Driving Agents

Two-question synthesis on agent integration boundaries. (1) App Server and MCP are not competitors — they sit at different planes: MCP is the model↔world tool plane (a connector written once, consumed by every surface, operated and authenticated by the tool provider), App Server is the orchestrator↔runtime session plane (thread lifecycle, turns, structured events, timeouts — nothing MCP covers). The only overlap is dynamic tool calls, and there the decision rule is operational: MCP wins for reusable, cross-surface, third-party capabilities; orchestrator-injected dynamic tools win for session-scoped, credential-sensitive capabilities (the linear_graphql pattern — the token never reaches the subagent container, shrinking the documented MCP attack surface of poisoned metadata and rug-pulls to first-party code, at the cost of experimental stability and zero ecosystem reuse). They compose: 'to the model, it's just tokens.' (2) Claude has no documented public equivalent of the App Server protocol; its offering brackets it from both sides — `claude -p` (drive the product CLI, inheriting the full accumulated harness: permission classifier, skills, context files, MCP wiring, with auto mode aborting rather than hanging unattended) and the Agent SDK (build a different product on the raw runtime — Claude Design's weekend prototype). Decision rule: drive the CLI when the product's harness is the value and orchestration is batch/fan-out shaped; build on the SDK when the agent is a different product needing its own tools, events, and UX; the App Server's middle position — structured session control over the product harness — is exactly the layer Symphony's tmux→protocol evolution shows demand for, and the layer Claude-side orchestrators currently approximate from either side