MCP Servers: Giving AI Eyes and Hands

For most of its existence, AI has been blind and paralyzed. It could think, but it couldn’t see your systems or touch your data. You had to copy-paste context in, then copy-paste actions out.

MCP changes that.

What MCP Is

MCP (Model Context Protocol) is a standard for connecting AI models to external tools and data sources. Think of it as USB for AI. Instead of explaining what’s in your database, you give the AI direct access to query it.

The architecture is simple:

  • MCP Server: A small service that exposes tools (functions the AI can call) and resources (data the AI can read)
  • MCP Client: The AI assistant that connects to servers and uses their capabilities
  • Protocol: A standardized way for them to communicate

You can run multiple MCP servers. One for your database. One for your cloud provider. One for your analytics. The AI connects to all of them and orchestrates across services.

Why This Matters

Before MCP, working with AI was conversational. You’d describe what you wanted, the AI would describe what to do, and you’d go do it manually.

With MCP, the AI can act directly. Instead of telling you “run this SQL query”, it runs the query. Instead of suggesting “check your S3 bucket”, it checks the bucket and tells you what it found.

This shifts the relationship from advisor to operator.

A Practical Example

Consider investigating a drop in user signups. The traditional flow:

  1. Ask AI what metrics to check
  2. Go to analytics dashboard, run queries
  3. Copy results back to AI
  4. Ask AI to interpret
  5. Go to database, run more queries
  6. Copy results back
  7. Repeat

With MCP servers connected to my analytics and database:

  1. Ask AI to investigate the signup drop
  2. AI queries analytics directly
  3. AI queries database directly
  4. AI correlates data across sources
  5. AI reports findings with evidence

Same investigation. Half the time. Zero copy-paste.

What You Can Connect

MCP servers exist for most common services:

  • Databases: PostgreSQL, MySQL, MongoDB, DynamoDB
  • Cloud: AWS, GCP, Firebase
  • Analytics: Mixpanel, Amplitude, custom dashboards
  • Communication: Slack, email, notifications
  • Files: S3, local filesystem, Google Drive
  • Code: Git, GitHub, CI/CD pipelines

You can also build custom MCP servers for internal tools. If it has an API, you can wrap it in MCP.

The Security Question

Giving AI direct access to production systems sounds dangerous. It can be.

The mitigation is layered permissions:

  1. Read-only servers for investigation. The AI can query but not modify.
  2. Scoped write access for specific operations. The AI can create a ticket but not delete users.
  3. Confirmation gates for destructive actions. The AI proposes, you approve.
  4. Audit logs for everything. You can see exactly what the AI accessed and when.

Start with read-only access to non-sensitive systems. Expand gradually as you build confidence.

Building Your First MCP Server

An MCP server is just a program that speaks the protocol. You can build one in any language, but TypeScript and Python have the best SDK support.

The core concepts:

// Tools: functions the AI can call
server.tool("query_users", async ({ filter }) => {
  const users = await db.users.find(filter);
  return { users };
});

// Resources: data the AI can read
server.resource("schema://database", async () => {
  return { tables: await db.getSchema() };
});

The AI discovers available tools and resources at connection time. It can then use them to accomplish tasks.

When To Use MCP

MCP shines when:

  • Investigation requires querying multiple systems
  • Operations are repetitive and well-defined
  • Context is too large to paste into chat
  • Actions need to happen in external systems

MCP is overkill when:

  • You’re doing one-off tasks that are faster to do manually
  • The system is too sensitive for any AI access
  • The task requires judgment that can’t be verified

The Bigger Picture

MCP is part of a broader shift toward agentic AI. Instead of chatbots that talk, we’re building agents that work.

The agent reads your error logs, queries your metrics, checks your recent deploys, and tells you what went wrong. It doesn’t just suggest fixes. It opens a PR with the fix.

This changes what developers do. Less time being the bridge between AI and systems. More time defining what the AI should do and verifying it did it right.

The AI gets eyes to see your systems and hands to change them. Your job shifts from operator to supervisor.