3. Context, Data, and Agent Workflows

Goal

Treat context as a designed product surface.

MCP servers should not dump raw systems into a model. They should expose curated tools and resources that are relevant, minimal, permission-aware, and easy for the model to reason over.

Patterns

• Progressive disclosure: search, list, then get detail.
• Server-side filtering and summarization.
• Metadata that communicates freshness and source.
• Explicit boundaries for private or regulated data.

Exercise

Create a context funnel for one source system.

Goal

Wrap an external API as a dependable MCP capability.

Implementation concerns

• Map API endpoints to model-friendly tools.
• Hide vendor-specific complexity behind stable schemas.
• Handle pagination, rate limits, retries, and timeouts.
• Normalize errors into clear recovery guidance.
• Keep credentials out of prompts and logs.

Assignment

Wrap a mock CRM or GitHub-like API with search/list/get operations.

Goal

Expose internal systems safely.

Avoid giving models arbitrary database or admin access. Prefer predefined, audited operations that map to business questions.

Safe patterns

• Read-only roles by default.
• Parameterized queries or service methods.
• Row-level and field-level permission checks.
• Result limits and redaction.
• Approval gates for writes.

Exercise

Convert an unsafe run_sql tool into three safe reporting tools.

Goal

Compose MCP capabilities into multi-step workflows.

Agent workflows often need search, inspection, draft creation, user confirmation, and final action. Your MCP surface should make those steps explicit and recoverable.

Patterns

• Split planning from execution.
• Represent intermediate state clearly.
• Use idempotent draft operations.
• Require confirmation for high-impact writes.
• Return next-step hints in errors.

Assignment

Design a five-step account research workflow.

Goal

Make failures understandable and recoverable.

Error taxonomy

• Validation errors: the model supplied bad or missing input.
• Permission errors: the user or token cannot perform the action.
• External service errors: dependency failure or rate limit.
• Business rule errors: request is valid but not allowed.

Good errors include

A short message, retryability, safe next steps, and no secret leakage.

Exercise

Rewrite five raw API errors into MCP-friendly errors.

Goal

Build an API-backed MCP server for a business system.

Requirements

• Connect to a mock CRM, ticketing, or project system.
• Provide search, list, and get tools.
• Add a safe update flow using draft and confirmation steps.
• Return useful errors and next-step hints.
• Include resource URIs for important records.

Review

Demo a user request that requires at least three MCP interactions.