Getting Started with Model Context Protocol (MCP): A Hands-On Guide for Developers

 Getting Started with Model Context Protocol (MCP): A Hands-On Guide for Developers

AI applications are becoming less interesting when they can only answer questions and far more useful when they can work with the software and data around them.

An AI assistant might need to search a database, read project documentation, access GitHub, query an internal API, or call a business tool. The problem is that every integration can require its own custom connection.

Model Context Protocol (MCP) is designed to solve that problem by giving AI applications a standardized way to connect models and agents with external tools and data.

The protocol has matured significantly in 2026. The latest 2026-07-28 MCP specification introduced a stateless protocol core, improved authorization, cacheable list results, extensions, and updated TypeScript, Python, Go, and C# SDKs.

If you are building AI agents, MCP is becoming a technology worth understanding.

What Is Model Context Protocol?

Model Context Protocol is an open protocol for connecting AI applications to external capabilities.

Think of it as a common interface between an AI application and the systems it needs to use.

Without MCP, an application might need custom integrations for every service:

AI App → Custom GitHub Integration

AI App → Custom Database Integration

AI App → Custom Slack Integration

AI App → Custom File Integration

With MCP, the architecture can become:

AI App → MCP Client → MCP Server → Tool / Data / Service

The model does not need to understand the internal implementation of every service. The MCP server exposes standardized capabilities that the client can discover and use.

The Three Core MCP Primitives

The most important concepts to understand are tools, resources, and prompts.

Tools

Tools allow an AI application to perform actions.

Examples include:

• Search a database
• Create a GitHub issue
• Query an API
• Run a calculation
• Send an approved message
• Execute a business operation

The official MCP SDK describes tools as capabilities that can perform computation, network calls, or other side effects.

Resources

Resources provide read-oriented information.

A resource might expose:

• Documentation
• Files
• Database records
• Configuration
• Application data

The important distinction is that resources represent information the client can retrieve, while tools are intended for actions.

Prompts

Prompts are reusable templates that help structure interactions with models.

For example, an MCP server could expose a reusable prompt for:

“Review this repository for security issues.”

The application can then use that prompt consistently rather than rebuilding the instruction every time.

How MCP Actually Works

At a high level, the workflow looks like this:

User → AI Application → MCP Client → MCP Server → Tool/Data → MCP Client → AI Model → User

Suppose you ask an AI coding assistant:

“Find the open security issues in my repository.”

The AI application can discover an appropriate MCP server and its available tools.

The model decides that a repository-search tool is useful.

The MCP client sends the request to the server.

The server communicates with GitHub or another connected system.

The result comes back through MCP.

The model then uses that information to produce the response.

The important part is that the AI application does not need a completely custom protocol for every tool.

MCP Client vs. MCP Server

These two terms are easy to confuse.

MCP Client

The client lives inside the AI application.

It manages communication with MCP servers and exposes their capabilities to the application or model.

MCP Server

The server exposes capabilities.

It can provide:

Tools + Resources + Prompts

An MCP server might connect to GitHub, PostgreSQL, a filesystem, a CRM, or an internal company API.

The server does not necessarily contain an AI model.

That distinction is important.

MCP is a connectivity protocol, not a replacement for the model.

Your First MCP Server

For developers, Python is one of the easiest ways to start experimenting.

The official Python SDK provides a high-level FastMCP interface for creating servers.

A simple server can expose a calculator tool:

from mcp.server.fastmcp import FastMCP

mcp = FastMCP("Calculator")

@mcp.tool()
def add(a: int, b: int) -> int:
    """Add two numbers."""
    return a + b

if __name__ == "__main__":
    mcp.run()

The interesting part is not the calculator.

It is the pattern.

You define a normal function and expose it as an MCP tool.

An MCP-compatible client can then discover that capability and make it available to an AI workflow.

Adding a Resource

You can also expose read-only information.

For example:

@mcp.resource("docs://getting-started")
def getting_started():
    return "This application uses MCP to connect AI systems with external tools."

Now the server provides a resource that an MCP client can retrieve.

This creates a useful separation:

Tool = Do something

Resource = Read something

Prompt = Start something in a structured way

Choosing a Transport

MCP supports different ways for clients and servers to communicate.

For local applications, stdio is common because the client can launch the server as a local process.

For remote deployments, Streamable HTTP is important.

The 2026-07-28 specification moved MCP toward a stateless HTTP-oriented architecture, removing the protocol-level handshake and session requirement and making it easier to run servers behind ordinary load balancers.

That is an important change for developers building production MCP infrastructure.

Instead of designing around persistent protocol sessions, remote MCP servers can increasingly behave like conventional scalable HTTP services.

TypeScript Developers Have a First-Class SDK

If your stack is JavaScript or TypeScript, the official MCP TypeScript SDK provides server capabilities for tools, resources, and prompts.

The current v2 SDK implements the 2026-07-28 specification and is the stable release line. The package has also been split into more focused modules compared with the older monolithic v1 SDK.

Installation starts with:

npm install @modelcontextprotocol/server

This makes MCP a natural fit for developers already building AI applications with TypeScript, Node.js, or modern web frameworks.

MCP and AI Agents

MCP becomes especially interesting when combined with agents.

An agent might have access to:

MCP Server	Example Capabilities
GitHub	Issues, pull requests, repositories
PostgreSQL	Queries and data access
Filesystem	Project files
Documentation	Search and retrieval
CRM	Customer information
Internal API	Business operations

Instead of hard-coding every integration into the agent, MCP provides a standardized interface for exposing capabilities.

That makes it easier to build systems where an agent can discover and use tools dynamically.

A Practical Project: Build a Database Assistant

A good first MCP project is a small database assistant.

Imagine a PostgreSQL database containing product information.

You could build an MCP server exposing a tool such as:

search_products(query)

The agent could then receive:

“Find our products related to enterprise security.”

The workflow becomes:

User request → Model → MCP tool → Database → Results → Model → Answer

Start with read-only access.

Do not immediately give an experimental agent permission to modify production records.

MCP Security Matters

MCP creates a standardized way for AI systems to interact with external capabilities.

That is powerful.

It is also a security boundary.

A poorly configured MCP server could expose sensitive information or give an agent more authority than it should have.

Security controls should include:

• Authentication
• Authorization
• Least-privilege permissions
• Input validation
• Output filtering
• Audit logging
• Rate limiting
• Secret management
• Tool-level access controls

The latest MCP specification includes authorization hardening, including issuer validation and changes around OAuth-oriented deployments.

But protocol-level security is only one layer.

Your application still needs to decide:

Who is allowed to call this tool?

What data can they access?

What actions can the agent perform?

Never Trust the Model With Authorization

This is one of the most important rules when building agentic applications.

Suppose you create an MCP tool:

delete_customer(id)

Do not rely on the model's instructions to determine whether the deletion is allowed.

The application should independently verify:

• User identity
• User permissions
• Requested customer
• Operation scope
• Business rules

The model can request an action.

Your application should decide whether that action is authorized.

This distinction becomes critical as MCP servers move from local experiments to enterprise systems.

MCP Registry and Discoverability

As the MCP ecosystem grows, developers also need ways to discover servers.

The official MCP Registry provides a community-driven service for discovering MCP servers and publishing server metadata.

That creates the possibility of an ecosystem similar to package registries:

Build once → Publish → Discover → Connect

For developers, this could eventually make integrations much easier to reuse across different AI applications.

MCP Apps and the Next Stage

MCP is also expanding beyond simple tool calls.

The 2026 specification introduced a formal extensions framework, while MCP Apps allows servers to provide interactive user interfaces alongside tools. The official MCP Apps documentation describes a model where a tool is paired with a UI resource that the host can render.

This matters because some tasks are difficult to express as plain text.

Imagine an AI assistant accessing:

• A data visualization
• A project management board
• A financial dashboard
• A configuration interface

Instead of returning only text, an MCP-enabled workflow could provide an interactive interface.

That moves MCP closer to being a general-purpose interaction layer for AI applications.

Common MCP Mistakes

Giving Tools Too Much Access

Start with read-only capabilities wherever possible.

Building Huge Tools

A tool that does ten unrelated things becomes difficult for both developers and models to reason about.

Prefer focused tools with clear descriptions.

Ignoring Validation

Validate every important argument before executing a tool.

Treating External Content as Trusted

Data returned by a tool can still contain malicious or misleading content.

Skipping Observability

Log important tool calls, errors, latency, and authorization decisions.

Using MCP Where You Don't Need It

Not every application needs MCP.

If your application has one internal function and no interoperability requirement, a direct function call may be simpler.

MCP becomes more valuable when multiple AI clients, models, tools, or services need a consistent integration layer.

A Practical Learning Path

If you are new to MCP, follow this progression.

Step 1: Build One Local Server

Create a simple server with one tool.

Step 2: Add a Resource

Expose a small piece of read-only information.

Step 3: Connect an MCP Client

Use an MCP-compatible AI application to discover the server.

Step 4: Connect a Real Service

Add GitHub, a database, filesystem access, or another API.

Step 5: Add Authentication

Move beyond local experiments and introduce proper authorization.

Step 6: Add Observability

Track tool calls, errors, latency, and access decisions.

Step 7: Deploy Remotely

Use Streamable HTTP and production infrastructure when your use case requires remote access.

Step 8: Build an Agent

Allow an AI system to decide when to use your tools while keeping application-level authorization in control.

The Bigger Picture

MCP is becoming important because AI applications are moving from answering questions to interacting with software.

A model by itself is limited.

A model connected to the right tools can search, analyze, update, calculate, retrieve, and execute.

MCP provides a standardized way to make those connections.

The 2026-07-28 release is particularly important because it pushes the protocol toward a more scalable, stateless architecture while adding extensions, stronger authorization, caching behavior, and support for long-running workflows through Tasks.

That makes MCP increasingly relevant to production AI engineering rather than just experimentation.

Conclusion

Model Context Protocol is best understood as an interoperability layer for AI applications.

It does not replace your model.

It does not replace your backend.

It does not magically make an agent intelligent.

What it does is provide a standardized way for AI applications to discover and interact with external tools, resources, and prompts.

For developers, the best way to learn MCP is not by memorizing the specification.

Build something.

Create a small server. Expose one useful tool. Connect it to an AI application. Add authentication. Test what happens when inputs are wrong. Then connect it to a real service.

Once you see the complete loop—

Model → MCP Client → MCP Server → Tool → Result → Model

—the purpose of MCP becomes much easier to understand.

And as AI agents become more deeply connected to real software systems, that kind of standardized connectivity could become one of the most important building blocks in the AI application stack.

Frequently Asked Questions

What is MCP in AI?

Model Context Protocol is an open protocol that standardizes how AI applications connect to external tools, data, and reusable prompts.

Is MCP the same as an AI agent?

No. An agent is an AI system capable of reasoning and taking actions. MCP is a protocol that can provide the agent with standardized access to external capabilities.

What can an MCP server do?

An MCP server can expose tools, resources, and prompts. Tools can perform actions, resources can provide information, and prompts can provide reusable interaction templates.

Should developers learn MCP in 2026?

If you are building AI agents or applications that need to connect with multiple external tools and services, MCP is increasingly useful to understand. The protocol's 2026-07-28 release also makes it more relevant for scalable production deployments.