Skip to main content

Agentic MCP System Design: Interview Questions and Answer Prompts

Use these questions to practice defending the design rather than merely presenting components.

1. Requirements and Scope​

Why begin with read-only Q&A?​

A strong answer:

  • It provides immediate value while limiting blast radius.
  • It allows the team to validate retrieval, authorization, citations, and tool quality.
  • Write workflows add idempotency, approvals, rollback, reconciliation, and higher compliance requirements.
  • The run model should still support write steps later so v1 is not a dead end.

What would you explicitly exclude from v1?​

  • Autonomous production changes.
  • Arbitrary shell execution.
  • Untrusted MCP server installation.
  • Unlimited multi-agent loops.
  • Broad access through one privileged service account.
  • Answers without citations for factual internal claims.

How would you define success?​

Product:

  • Task completion.
  • Time saved.
  • Answer acceptance.
  • Repeat usage.
  • Low escalation rate.

Quality:

  • Citation correctness.
  • Groundedness.
  • Tool-selection and argument accuracy.
  • Workflow completion.

Operational:

  • Latency.
  • availability.
  • cost per successful task.
  • error and fallback rates.

2. MCP Boundaries​

Why MCP instead of direct function calling?​

MCP standardizes capability discovery and invocation across many model hosts and domain integrations. It reduces custom N-by-M integration work and creates a common governance boundary.

It does not replace:

  • Internal APIs.
  • Business logic.
  • orchestration.
  • authorization.
  • audit.
  • approval.
  • evaluation.

Should every internal API become an MCP tool?​

No. Expose stable, task-oriented capabilities that are useful to an agent. Mirroring hundreds of low-level routes creates tool-selection ambiguity, larger prompts, security risk, and brittle workflows.

Where should business logic live?​

In the existing domain service. The MCP adapter should be thin:

MCP schema and validation
→ identity and policy context
→ domain API
→ normalized result

Avoid moving core business invariants into model prompts or adapter code.

Why introduce an MCP gateway?​

  • Registry and allowlisting.
  • Version compatibility.
  • auth delegation.
  • schema cache.
  • rate limits.
  • circuit breakers.
  • result size controls.
  • central telemetry.
  • kill switches.

The downside is another critical service and network hop. Mitigate with stateless scaling, server-level bulkheads, regional deployment, and a narrow responsibility set.

How do you version tools?​

Prefer additive evolution:

  • Add optional fields.
  • Keep stable semantics.
  • Publish new tool names or versions for breaking changes.
  • Run contract tests against clients.
  • Track tool usage before deprecation.
  • Support a migration window.
  • Pin high-risk workflows to known versions.

3. Agent Orchestration​

How does the agent decide which tools to use?​

Use a layered approach:

  1. Deterministic permission and domain filtering.
  2. Intent classification.
  3. Candidate-tool retrieval/ranking.
  4. Model selection among a small candidate set.
  5. Schema validation.
  6. Policy check at execution time.

Do not pass all enterprise tools to the model.

How do you prevent infinite loops?​

Enforce:

  • Maximum steps.
  • maximum repeated call signature.
  • token budget.
  • tool-cost budget.
  • wall-clock deadline.
  • per-tool deadline.
  • no-progress detection.
  • user cancellation.
  • workflow-specific constraints.

When do you need durable orchestration?​

Use it when workflows:

  • Last minutes or hours.
  • wait for approval.
  • perform side effects.
  • need retries across process restarts.
  • require compensation or reconciliation.
  • must produce a precise audit history.

Simple read-only Q&A can begin with a lighter database-backed run loop.

Would you use multiple agents?​

Not initially. Start with one orchestrator and dynamically filtered domain tools.

Add specialized agents when:

  • Domains have meaningfully different policies or context.
  • Tool-selection quality degrades.
  • Teams need independent release boundaries.
  • Evaluation demonstrates better outcomes.

Multi-agent systems increase latency, token usage, coordination errors, and debugging difficulty.

How do you handle context-window limits?​

  • Keep recent turns.
  • Maintain a versioned conversation summary.
  • retrieve older relevant turns.
  • store full artifacts externally.
  • deduplicate tool results.
  • preserve decisions and citations.
  • use explicit token budgets.
  • separate user-visible history from model context.

4. Security​

How is user identity propagated to tools?​

Use short-lived delegated credentials or signed identity context. Preserve:

  • tenant,
  • user,
  • roles/scopes,
  • request ID,
  • purpose,
  • expiration.

The MCP server and underlying API must enforce authorization. Avoid a universal service account that turns the agent into a confused deputy.

Can the model decide whether a user has permission?​

No. The model can identify an intended action, but a deterministic policy layer makes the authorization decision.

How do approvals work?​

  1. Model proposes a structured action.
  2. Backend validates and hashes the action.
  3. Policy marks it as requiring approval.
  4. Frontend renders immutable server-provided details.
  5. User approves an opaque approval ID.
  6. Backend rechecks identity, policy, expiry, and resource state.
  7. Tool executes using an idempotency key.

How do you defend against prompt injection?​

  • Treat retrieved text and tool output as untrusted.
  • Label and delimit content.
  • Filter candidate tools before model reasoning.
  • Keep authorization outside the model.
  • Require approval for side effects.
  • restrict data egress.
  • scan server and tool metadata changes.
  • sanitize outputs.
  • test adversarial prompts continuously.

What happens if an MCP server is compromised?​

  • Server allowlist and identity verification.
  • least-privilege credentials.
  • egress controls.
  • output size and schema validation.
  • data classification.
  • per-server circuit breaker.
  • kill switch.
  • anomaly detection.
  • immutable audit.
  • rapid key rotation.
  • server isolation.

Assume MCP server output may be hostile.

5. Reliability​

A write tool times out. Do you retry?​

Not blindly. Query operation status using the idempotency key. Retry only when the underlying API guarantees idempotency or reports that the operation was not accepted.

How do you degrade when one tool is unavailable?​

  • Continue with other sources.
  • Mark missing or stale information.
  • return a partial answer.
  • offer retry.
  • avoid inventing the missing result.
  • trip a server-specific circuit breaker rather than failing the entire platform.

How do you resume a disconnected stream?​

  • Persist run events.
  • assign monotonically increasing sequence IDs.
  • reconnect with the last received event ID.
  • replay missed events.
  • deduplicate in the frontend reducer.
  • reconcile final state through a run snapshot endpoint.

How do you prevent duplicate actions?​

  • Approval bound to exact action hash.
  • one-time approval token.
  • idempotency key.
  • unique database constraint.
  • downstream idempotency where possible.
  • status reconciliation before retry.

6. Frontend​

SSE or WebSocket?​

Use SSE when the main requirement is server-to-client token and progress streaming. It is simpler and works well with HTTP reconnect semantics.

Use WebSocket when frequent bidirectional events, collaborative presence, or very low-latency interactive control is required.

How do you prevent streaming from hurting rendering performance?​

  • Batch deltas.
  • update only the active message.
  • parse completed Markdown blocks incrementally.
  • virtualize long history.
  • avoid auto-scroll when the user scrolls up.
  • discard old transient events after snapshotting.
  • memoize stable rows.

How do you make token streaming accessible?​

Do not announce each token. Batch meaningful phrases into a polite live region, announce status transitions, make stop/retry controls keyboard accessible, and preserve focus during updates.

What state belongs on the client?​

Client:

  • Draft text.
  • viewport/scroll state.
  • pending optimistic message.
  • latest rendered event sequence.
  • temporary UI expansion state.

Server:

  • Authoritative messages.
  • run and step state.
  • approval state.
  • tool arguments/results.
  • audit.
  • terminal outcome.

How would you render MCP-provided interactive UI?​

Treat it as untrusted third-party UI:

  • sandboxed iframe or constrained runtime.
  • strict CSP.
  • explicit capability bridge.
  • no direct credential access.
  • validated messages.
  • origin restrictions.
  • versioned UI contract.
  • accessible fallback representation.

7. Data and Storage​

Why relational storage for runs?​

Runs, steps, approvals, and messages have strong relationships, transaction requirements, and operational queries. A relational database provides constraints and clear state transitions.

Store large tool results in object storage and analytics/audit streams in specialized systems.

How do you handle conversation deletion?​

Separate:

  • User-visible conversation content.
  • legally required audit records.
  • derived embeddings and caches.
  • analytics events.

Use deletion workflows with tombstones, downstream propagation, and retention-policy exceptions.

Can tool responses be cached?​

Yes for read-only tools when:

  • Permission context is part of the key.
  • freshness is explicit.
  • data classification allows it.
  • tool and schema versions are included.
  • invalidation or TTL is appropriate.

Never share a privileged cached result across authorization boundaries.

8. Cost and Performance​

How do you reduce cost?​

  • Small model for classification/ranking.
  • strong model only for complex planning/synthesis.
  • candidate-tool filtering.
  • conversation summarization.
  • prompt and schema compression.
  • retrieval before generation.
  • read-result caching.
  • bounded runs.
  • per-team quotas.
  • batch embeddings.
  • cost attribution by use case.

Optimize cost per successful task, not cost per token alone.

What is your latency budget?​

Example:

Gateway/auth                 100 ms
Context load                 150 ms
Tool candidate selection     200 ms
First model decision       500–900 ms
First progress event       <1.5 sec
Tool call                 0.5–4 sec
Final synthesis              1–3 sec

Parallelize independent reads but respect downstream rate limits.

How do you choose between sequential and parallel tool calls?​

Parallelize independent, read-only calls. Keep dependent calls sequential. Avoid parallel writes unless the workflow defines atomicity or compensation.

9. Evaluation and Rollout​

How do you evaluate an agentic system?​

Evaluate the full trace, not only the final prose:

  • Correct intent.
  • correct tool.
  • correct arguments.
  • authorized access.
  • tool-result interpretation.
  • citation support.
  • final answer.
  • safe action behavior.
  • latency and cost.

How do you release model or prompt changes safely?​

  • Version every prompt/model/tool policy.
  • replay golden traces.
  • shadow production traffic.
  • canary by team.
  • compare task success and safety metrics.
  • automatic rollback.
  • maintain reproducibility for audited runs.

What is the minimum bar before enabling write tools?​

  • Strong identity and authorization.
  • confirmation UX.
  • idempotency.
  • audit trail.
  • timeout reconciliation.
  • rollback or compensation strategy.
  • adversarial tests.
  • domain owner signoff.
  • kill switch.
  • on-call ownership.

Staff-Level Signals Checklist

During the interview, make these points explicit:

  • MCP standardizes integration; it does not replace the control plane.
  • Existing services remain systems of record.
  • Models propose actions; deterministic systems authorize them.
  • Tool discovery is filtered by identity, policy, domain, and quality.
  • Every write uses approval and idempotency.
  • Every run is traceable end to end.
  • Tool and prompt versions are governed like software releases.
  • Domain teams own semantics; the platform team owns shared guardrails.
  • Start read-only, evaluate, then expand risk gradually.
  • Optimize for organizational scalability, not only request throughput.