Integration Entry Point Options

The entry points, and why they are an architectural choice

Connecting Claude into an enterprise stack starts with one decision: which entry point the system connects through. The exam expects you to know the main options, direct API calls, an SDK, MCP servers, Claude Code/CLI, and agent-to-agent protocols, and, more importantly, to treat the choice among them as an architectural decision the Architect owns. It is not a detail to leave to whichever engineer starts coding, and it is not settled by whatever a developer is most familiar with. The entry point shapes flexibility, maintenance burden, and compliance posture for the life of the integration, so it belongs at the architecture level.

This is a remember-level foundation, but its weight is the framing: entry point first, and entry point as a real decision with trade-offs, not a default.

The five options at a glance

Each entry point occupies a different point on the flexibility-versus-overhead spectrum. Direct API calls give the most control over request shape, error handling, streaming, and tool orchestration, but every one of those concerns, including retry logic, is code your team writes and maintains. An SDK (available in Python and TypeScript) wraps the HTTP layer in typed, language-native conveniences, trading a little granular control for faster development; be aware that an SDK version upgrade can occasionally change behaviour and warrants a code review before deploying. MCP servers standardise how tools and internal services are exposed, keeping the integration layer separate from your orchestration logic so it can be reused across applications, at the cost of an added protocol layer that makes debugging tool calls less direct than plain function calls. Claude Code/CLI is an agentic entry point built for developer workflows, writing, reviewing, and navigating code, and is deliberately not intended as the backend for a multi-tenant or customer-facing product; those should route through the API, the SDK, or the Agent SDK instead. For multi-turn agentic work inside your own product, the Agent SDK runs a managed loop that handles iteration, tool execution, and termination so your team does not build that infrastructure, whereas a raw API loop remains the right choice when you need custom logic between turns. Agent-to-agent protocols connect two independently operated agent systems so they can exchange tasks or results directly.

Knowing what each is for is the point of this foundation. The later knowledge points, MCP as a protocol and the direct-API-versus-MCP trade-off, dig into specific choices among these; here you just need the menu and what each item trades.

Not interchangeable, and not API-by-default

The two traps both come from underrating the decision. The first is treating all entry points as functionally interchangeable and choosing based on developer familiarity alone. They are not interchangeable: they differ in flexibility, maintenance overhead, and compliance posture, so picking whichever a developer happens to know best can land the integration on an entry point that fits the developer but not the requirements. The second is assuming the API is always the default choice regardless of the integration's compliance and reuse requirements. The direct API is a fine option, but it is not automatically correct; a reuse-heavy integration may be better on MCP, and a compliance-constrained one may not survive on the API at all.

The corrective is to treat the choice as the Architect's, made against the integration's actual requirements. That is why compliance constraints filter the options first: the requirements, not familiarity or habit, decide the entry point.

What the exam trips candidates on

Two traps. The first is treating all entry points as functionally interchangeable and choosing based on developer familiarity alone, ignoring that they differ in flexibility, maintenance, and compliance. The second is assuming the API is always the default choice regardless of the integration's compliance and reuse requirements. The credited answer treats entry point selection as an architectural decision made against the integration's requirements.

Common misreadings to avoid

How this shows up on the exam

Expect an integration where the entry point is chosen by habit or assumed to be the API, against requirements (reuse, compliance) that point elsewhere. The reliable reading is that entry point selection is the Architect's decision, made against the integration's requirements, from five distinct options. This foundational knowledge point unlocks MCP as a standardised protocol and compliance constraints filtering entry points first, and it sets up the direct-API-versus-MCP trade-off.