Status: stable for the MCP boundary; working draft elsewhere — the MCP relationship is frozen in the 0.8.0 concept model; the other comparisons describe what Xtrape is, without claiming feature parity or superiority over named categories.

Positioning

Xtrape is a governance plane, not another entry in the tool-calling ecosystem. This page states its boundaries with adjacent categories precisely — including where the canonical design deliberately says nothing.

Xtrape and MCP

This boundary is explicit and frozen in the concept model:

• MCP is a protocol projection under Xtrape Exposure — a protocol representation of governed capability material presented to AI clients. It is not the interaction umbrella, not parallel to the operator Panel or chat channels, and not a Device.
• Xtrape is therefore not an MCP alternative. It is the plane whose governed material an MCP endpoint can carry. The Exposure product owns the AI-facing model (Exposure Tasks, tool naming, discovery catalogs); the Platform owns authorization. An MCP adapter holds no canonical state and never pre-authorizes: every call returns to the Platform for a fresh decision.
• The MCP adapter role and protocol contract are frozen as edition-neutral; the concrete adapter component is under active implementation (the exposure spine of the current release train). Do not read this site as claiming a shipping MCP product today.

Xtrape and AI agent frameworks

Xtrape does not define an "Agent" as a platform object at all — that term was deliberately retired from the object model, because it was carrying too many meanings at once. An AI agent is normally an implementation component inside a Widget/Service, or (in a future, still-open participant model) an independently governed caller. What bridges an external runtime into Xtrape is a Connector; what actually executes a Service's work is a Worker. The one place the word survives unchanged is the principal type naming an autonomous AI originator — the party that initiated an invocation, which is a governance question, not a runtime one.

So the relationship is complementary: an agent framework helps you build the thing that does the work; Xtrape governs how that thing is registered, exposed, authorized, and audited once it runs. Xtrape makes no claims about how you should build agents.

Xtrape and workflow engines

Xtrape deliberately avoids a global "Task" or workflow object. The canonical model defines Exposure Tasks (versioned definitions of reusable work presented to AI clients) — not an orchestration engine. Workflow placement is an explicitly open decision in the current concept freeze. If you need a workflow engine, Xtrape is not one; a workflow engine's steps could, however, be governed Services.

Xtrape and API gateways

Xtrape's Community Edition deliberately introduces no gateway concept. Governance is modeled at the invocation level (originator, path, versioned operation, resource) rather than at a network choke point. The adjacent stance worth knowing: outbound third-party calls are governed through proxy, quota, approval, and audit policies by a distinct platform service — outbound-call governance, not inbound API gateway framing. Multi-platform collaboration is modeled as Platform-to-Platform capability exposure, not gateway federation.

What Xtrape is not

• Not a package registry or app store — the Artifact Repository (design-stage) may index and reference external registries; it does not replace them.
• Not a scheduler or cluster manager — deployment topology, scaling, and Worker placement are open decisions. (Replica is simply the technical-domain synonym of Worker; what is open is how many run, where, and under what policy — not the naming.)
• Not a hosted service or commercial SLA — Community Edition is self-hosted, best-effort software. See Governance.