MCP: The Universal Plug That's Making AI Agents Actually Useful

Ever wondered how AI agents actually connect to your tools and data? MCP is the missing piece that's finally making it simple. Here's what you need to know.

Bhawesh Kumar

Senior Principal Architect

Published Aug 29, 2025

Last modified Aug 29, 2025

The 30-Second Pitch

You know how frustrating it is when you have to build custom integrations for every single tool your AI agent needs to use? MCP (Model Context Protocol) just solved that problem.

Think of it as the USB standard, but for AI tools. Instead of building N×M connections (every agent to every tool), you build N+M (agents speak MCP, tools speak MCP, boom—everything works together).

It's not replacing your agent frameworks like LangChain or CrewAI—it's making them way more powerful by giving them a universal way to connect to... well, everything.

The Problem Every Dev Has Hit

Picture this: You've built an awesome AI agent, but it's basically living in a bubble. It can't read your files, check your GitHub repos, query your database, or post to Slack. Every single integration becomes a custom nightmare of API wrappers and one-off code.

I've been there. You end up with this spaghetti mess, where each agent needs its own connector for each service. Want to switch from OpenAI to Claude? Rewrite all your integrations. Want to add a new tool? Start from scratch.

MCP flips this on its head. One protocol, universal connections. It's like finally having a standard plug that works with every device.

How It Actually Works

Here's the cast of characters in this story:

Host = Your AI app (Claude Desktop, your custom agent, whatever). This is where the magic happens.

Client = A specialized translator inside your host. Each client connects to exactly one server (1:1 relationship). If your host needs multiple tools, it runs multiple clients.

Server = The bridge to your actual tools. Think of it as a specialized translator that makes GitHub, your database, or your file system speak MCP.

Tools = The actual actions you can take ("run this SQL query," "create this file," "post to Slack").

Resources = The stuff you can read or browse (files, documents, API responses).

Prompts = Parameterized templates exposed by servers to help you kick off tasks consistently (e.g., "draft_release_notes", "triage_issues"). Hosts can list prompts and fill parameters at runtime.

It's basically a well-organized conversation between your AI and all your tools, data, and reusable prompts—with everyone speaking the same language. The key insight: each client-server pair is dedicated, so if ChatGPT needs GitHub, Slack, and Files, it runs three separate MCP clients internally.

MCP architecture (big picture)

Key points:

1:1 client-server: each MCP client connects to exactly one server.
Multiple clients per host: hosts run one client per configured server (no global client).
Per-host configuration: each host decides which servers to load; discovery spans configured servers, execution is on-demand via the dedicated client.

Before we dive into a single call flow: at session start, a host spins up one MCP client for each configured server (e.g., ChatGPT might start a GitHub client and a Slack client; your IDE might start Files, GitHub, and Postgres clients). Each client discovers the tools its server offers. The model/host can then call any discovered tool, with each call routed through the appropriate client.

Unified flow: tools, resources, prompts

Where does MCP fit in an agentic stack?

Orchestration: Decide when/why to act (LangGraph, CrewAI, custom planners). MCP does not replace this.
Context: RAG, memories, profiles. MCP can fetch context (e.g., query a vector DB) via a server, but it’s not a retriever itself.
Action: MCP standardizes the “do stuff” layer: discover tools, call them, get structured results, iterate.
Content surfaces: MCP also standardizes access to resources (files/data) and prompts (parameterized templates) so hosts don’t have to reinvent these APIs per integration.

Why is MCP taking off now?

Ecosystem momentum: Prebuilt servers exist for Google Drive, Slack, Git/GitHub, Postgres, browsers/automation (Puppeteer), etc.
De facto standard vibes: Open, model-agnostic, runtime discoverable. Multiple hosts (Claude Desktop and several IDEs/editors) are adding or experimenting with support.
Practical value: Cuts glue work; portable across models/vendors; simplifies moving pilots to production.

Comparisons you’ll get asked about

Plugins (OpenAI-era): Similar intent (let LLMs call APIs) but platform-specific and often one-way/stateless. MCP is open and supports richer, two-way, sessionful exchanges.
LangChain Tools: Great dev-facing abstraction. MCP complements it with a model-facing runtime standard. Many frameworks now adapt MCP servers as tools.
RAG: Injects text context; MCP performs actions and can retrieve live, structured data. They’re complementary.

Nitty gritty (what matters in real builds)

Tool design and naming

Keep tool names stable and descriptive: list_prs, run_sql, write_file.
Validate inputs rigorously. Return typed, compact results with pagination.
Provide good descriptions and examples—models rely on them for correct usage.

Security and governance

Least privilege: separate servers/keys per domain; scoped OAuth where possible.
Guardrails: allowlists/denylists per tool and per resource path; dry-run modes for destructive ops.
Observability: log tool calls, inputs/outputs metadata, latency, and error codes. Redact secrets.
Policy layer: consider an MCP “gateway”/guardian to enforce org policies, rate limits, and approvals for risky operations.

Reliability and UX

Idempotency for actions; retries with backoff; circuit breakers around flaky services.
Timeouts and partial results—don’t block the whole plan.
Human-in-the-loop: surface diffs/previews for writes, optional confirmations.

Multi-user and remote servers

AuthN/Z: map host users to service identities; avoid shared break-glass tokens.
Remote servers: Service-Sent Events (SSE) and OAuth flows are emerging to support cloud deployments and org-wide servers.
Discovery: .well-known/mcp endpoints and registries ease onboarding while enabling private catalogs in enterprises.

Performance and cost

Cache resource listings and schemas. Stream large results when supported.
Minimize token-heavy tool schemas; keep responses focused and reference larger blobs by handle/URI.

Getting started (practical path)

Start local with a desktop host

Install a host that supports MCP (e.g., Claude Desktop). Enable a couple of prebuilt servers (files, Git, GitHub, Slack).
Verify discovery: tools should appear without code changes.

Prototype tasks end-to-end

“Plan a doc update”: read file → generate draft → write file.
“PR triage”: list PRs → summarize → comment or request reviewers.

Add governance and observability

Introduce a thin proxy/guardian to log and approve risky tools (write/delete, external posts, payments).

Move to remote and multi-user

Spin up remote servers with OAuth per user. Add an internal registry and .well-known discovery for sanctioned servers.

Using community MCP servers in popular hosts (Cursor, VS Code, etc.)

Why this matters

Community servers let you wire up GitHub, Slack, DBs, files, and more without writing adapters.
Each host runs multiple MCP clients internally—one client per server (1:1).

Important caveats

Community-run; availability may vary.
Review code and scopes; use least-privilege tokens per server.
Prefer per-user OAuth where possible; avoid shared “break-glass” tokens.
For remote servers (SSE/OAuth), support is emerging—check your host’s current capabilities.

Common configuration patterns (generic templates)

Local process (stdio) servers

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
{
  "mcpServers": {
    "files-local": {
      "transport": "stdio",
      "command": "/path/to/files-server",
      "args": ["--root", "/Users/you/projects"],
      "env": {
        "LOG_LEVEL": "info"
      }
    },
    "github-local": {
      "transport": "stdio",
      "command": "/path/to/github-server",
      "env": {
        "GITHUB_TOKEN": "{{GITHUB_TOKEN}}"
      }
    }
  }
}

Remote (SSE + OAuth) servers

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
{
  "mcpServers": {
    "github-remote": {
      "transport": "sse",
      "url": "https://mcp.example.com/github",
      "auth": {
        "type": "oauth2",
        "client_id": "{{GITHUB_OAUTH_CLIENT_ID}}",
        "client_secret_env": "GITHUB_OAUTH_CLIENT_SECRET"
      }
    },
    "slack-remote": {
      "transport": "sse",
      "url": "https://mcp.example.com/slack",
      "auth": {
        "type": "oauth2",
        "client_id": "{{SLACK_OAUTH_CLIENT_ID}}",
        "client_secret_env": "SLACK_OAUTH_CLIENT_SECRET"
      }
    }
  }
}

Quick-verify checklist

After saving the config, restart the host (or reload settings).
Confirm discovery: tools, resources, and prompts from each server should appear with names and descriptions.
Call a safe read-only tool first (e.g., list resources).
Check logs for errors, timeouts, or auth failures.

Security tips

Scope tokens narrowly; rotate regularly.
Use allowlists/denylists for risky tools.
Log tool calls (metadata only) for auditability; redact secrets.
If offered, put a policy proxy in the middle to gate dangerous actions.

Examples: Cursor and VS Code (generic config)

These examples show how a VS Code–style host (including Cursor) might configure community MCP servers. Exact paths and UI may vary by host/version.

Example 1: GitHub server (local stdio)

1
2
3
4
5
6
7
8
9
10
11
{
  "mcpServers": {
    "github-local": {
      "transport": "stdio",
      "command": "/usr/local/bin/mcp-github", /* replace with your path */
      "env": {
        "GITHUB_TOKEN": "{{GITHUB_TOKEN}}"
      }
    }
  }
}

Reload hint (VS Code/Cursor): Open Command Palette → “Reload Window”. After reload, verify discovery: look for tools like list_prs.

Example 2: Slack server (remote SSE + OAuth)

1
2
3
4
5
6
7
8
9
10
11
12
13
{
  "mcpServers": {
    "slack-remote": {
      "transport": "sse",
      "url": "https://mcp.example.com/slack", /* replace with your server URL */
      "auth": {
        "type": "oauth2",
        "client_id": "{{SLACK_OAUTH_CLIENT_ID}}",
        "client_secret_env": "SLACK_OAUTH_CLIENT_SECRET" /* set in your env */
      }
    }
  }
}

Notes:

One client per server (1:1). Each configured server results in a dedicated client inside the host.
Use environment variables for secrets (never inline tokens). Scope tokens narrowly.
Start with a read-only tool call to validate connectivity before enabling write actions.

Example server design checklist

Tools: clear verbs, narrow scope, JSON schemas, examples.
Errors: typed errors (validation_error, not_found, permission_denied) with actionable messages.
Resources: stable URIs, pagination, ETags/revision IDs.
Security: least-privilege credentials, scoped tokens, audit logs, rate limits.
Ops: health endpoint, metrics, SLOs, backpressure.

Common pitfalls (and how to avoid them)

Overbroad tools like do_everything cause misuse—split into small, composable tools.
Silent failures confuse agents—return structured, typed errors and guidance.
Unbounded responses explode tokens—summarize and link to resources.
Shared credentials break governance—bind actions to users and scopes.

What MCP is not (and that’s okay)

Not an agent brain or planner; it’s the standardized I/O for actions.
Not a knowledge base; it can fetch context, but it doesn’t store it.
Not a magic auto-integrator; you still design tools, schemas, and policies.

Opinionated take: where this heads next

Registries become the “app stores” for agents, but enterprises will need private catalogs and vetting pipelines.
Expect richer streaming, proactive server push (events), and first-class namespaces to reduce collisions.
Security posture will define real adoption: signed servers, policy-as-code, reproducible builds, and per-user OAuth by default.
The winner pattern: an orchestration layer + MCP toolbox + RAG/memory + a governance proxy in the middle.

Roadmap signals from the community

Remote servers over SSE with built-in OAuth 2.0 (emerging/under active development).
Official registries and .well-known/mcp discovery endpoints.
Enterprise-friendly: private registries, better namespacing, streaming, and stateless options.

Wrap-up

MCP isn’t hype—it’s the practical connector that lets your agents actually do useful work with your real tools. Start small (local host + two or three servers), wire up a couple of real workflows, and add governance as you scale.

# mcp # aws-knowledge-mcp # mcp-integration # mcp-server # ai

Any opinions in this article are those of the individual author and may not reflect the opinions of AWS.

Enjoyed reading this content? Let the author know!

Your likes, comments, shares, and saves help creators reach more builders.

Loading recommendations

Loading article

Builder Center

MCP: The Universal Plug That's Making AI Agents Actually Useful

Bhawesh Kumar

The 30-Second Pitch

The Problem Every Dev Has Hit

How It Actually Works

MCP architecture (big picture)

Unified flow: tools, resources, prompts

Where does MCP fit in an agentic stack?

Why is MCP taking off now?

Comparisons you’ll get asked about

Nitty gritty (what matters in real builds)

Getting started (practical path)

Using community MCP servers in popular hosts (Cursor, VS Code, etc.)

Examples: Cursor and VS Code (generic config)

Wrap-up