This guide explains what MCP is, why it matters, and how to build and connect your first server. As in my previous article, we'll go in small steps and verify each one before moving on.

What is MCP?

MCP is an open protocol, introduced by Anthropic, that defines how an AI application (the client) talks to an external program (the server) that exposes capabilities. A server can offer three kinds of things:

• Tools: functions the model can call, like "search orders" or "create ticket".
• Resources: read-only data the model can load, like files or database records.
• Prompts: reusable prompt templates.

Client and server exchange JSON-RPC messages, either over stdio (the client launches the server as a local process) or over HTTP for remote servers.

Here is what a single tool call looks like end to end:

Why it matters for AI tooling

• Build once, use everywhere. The same server works in any client that speaks MCP.
• Clear boundaries. The model only sees what your server exposes, and you control the code that touches real systems.
• Composable. A client can connect to several servers at once: one for GitHub, one for your database, one for internal docs.
• Less glue code. You write plain functions; the SDK handles the protocol.

Step 1: Decide what your server exposes

Before writing code, write down, in a short list:

• The 1 to 3 tools you need, with inputs and outputs.
• What data the tools may read or change, and what they must never do.
• 2 or 3 real requests a user might make, and the result you expect. These are your acceptance tests.

For this guide we'll build a tiny server with two tools: add (adds two numbers) and get_weather_note (returns a canned note for a city). Simple on purpose, so we can focus on the protocol.

Step 2: Set up the project

We'll use the official Python SDK.

mkdir my-first-mcp && cd my-first-mcp
python -m venv .venv
source .venv/bin/activate        # Windows: .venv\Scripts\activate
pip install "mcp[cli]"

Verify the install before going further:

python -c "import mcp; print('ok')"

Step 3: Write the server, one tool at a time

Create server.py with just one tool first:

from mcp.server.fastmcp import FastMCP

mcp = FastMCP("my-first-mcp")

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

if __name__ == "__main__":
    mcp.run()  # uses stdio by default

The function's type hints and docstring become the tool's schema and description, which is what the model reads to decide when to call it. Write the docstring for the model, clearly.

Step 4: Test it before connecting any AI

The SDK ships with a development inspector:

mcp dev server.py

This opens the MCP Inspector, where you can list the tools and call add with test inputs. Only move on when add(2, 3) returns 5.

Now add the second tool:

@mcp.tool()
def get_weather_note(city: str) -> str:
    """Return a short demo weather note for a city."""
    return f"Demo note: it's a nice day in {city}."

Run the inspector again and test it. One tool, one test, every time.

Step 5: Connect it to an AI client

Claude Desktop. Add your server to Claude Desktop's config file (claude_desktop_config.json):

{
  "mcpServers": {
    "my-first-mcp": {
      "command": "/full/path/to/my-first-mcp/.venv/bin/python",
      "args": ["/full/path/to/my-first-mcp/server.py"]
    }
  }
}

Restart Claude Desktop, and the tools appear. Ask "What is 17 plus 25? Use the add tool." and check that it calls your server.

Grok and other clients. Any assistant or agent framework that supports MCP connects the same way: either it launches your server locally over stdio, or you deploy the server over HTTP and give the client its URL. Check your client's documentation for how it registers MCP servers; the server code doesn't change.

Step 6: Loop until your acceptance tests pass

Go back to the requests you wrote in Step 1. Run each one through the client. If the model picks the wrong tool or passes bad arguments, the fix is usually a clearer docstring or tighter parameter types. Adjust, retest, repeat.

Tips before going to production

• Least privilege. Give the server only the permissions it needs; prefer read-only tools until you trust the flow.
• Validate inputs. Treat everything the model sends as untrusted user input.
• Log every call. You'll want to see what the model asked for and what your server did.
• Keep secrets out of tool output. Anything a tool returns goes into the model's context.

The key principle

Same as with any AI-assisted build: don't try to build the whole thing at once. Define a small set of tools, add them one at a time, test each in the inspector, then connect a client and verify with real requests.

MCP turns "integrate this model with our system" into "write a few well-described functions." Start with one tool, get it working end to end, and grow from there.

About the author

I write about Applied AI, MCP, Azure AI Search, and RAG. Follow me on Dev.to and Hashnode for more.

Here's the workflow I actually use, with integrating a SQL database into Azure AI Search as the example.

The workflow at a glance

Step 1: Prepare the requirements document

It doesn't need to be long, but these four sections must be clear.

1. Data Source

• Which SQL database, and whether it's accessed through a connection string or a managed identity.
• Which tables and fields get synced into the index.
• Which fields stay out of the index and are only used to fetch full records back from the database.

2. Retrieval Requirements

• Query type: keyword, semantic, vector, or a combination.
• How many results each query returns.
• Whether matching snippets should be highlighted.

3. Sync Strategy

• Full sync or incremental sync.
• How often it refreshes.
• Who triggers it: a schedule, data changes, or a manual run.

4. Acceptance Criteria

• Write down 3 to 5 real questions and the result you expect for each.
• This is your pass standard: the feature is done only when all of them return the right results.

Step 2: Upload the doc and ask for a plan, not code

Upload the requirements document to Grok and say explicitly: "Don't write any code yet. Give me a phased implementation plan."

Review the plan yourself. Are the phases sensible? Is anything missing, like sync or permissions? Is the order right? Ask it to adjust until you're happy with the plan.

Step 3: Write the code one small piece at a time

Following the plan, ask Grok for just one small piece at a time, such as "create the index schema" or "set up the data source connection."

Run it right away. If it errors, paste the full error back and have it fix it. If it works, paste the result back too, then move on to the next piece.

Step 4: Loop until everything is checked off

Repeat Step 3, checking off each feature in the plan. Finally, run the acceptance questions from Step 1 one by one. You're done only when they all pass.

The key principle

Never let it generate the whole project at once. Small steps that can be verified and rolled back at any point are what make AI-assisted coding both fast and reliable.

The Azure AI Search + SQL architecture

• Azure AI Search is the retrieval layer. It handles keyword, semantic, and vector search.
• The SQL database is the storage layer. It holds the complete, authoritative data.
• Azure Data Factory or Synapse syncs SQL data into the Search index.
• At query time, search in Azure AI Search first, take the IDs from the results, then use those IDs to fetch the full records from SQL.

You get a strong search experience while keeping a single source of truth in the database.

Recommendation: use text embeddings

Add text vector fields to your index. Azure AI Search has a built-in embedding skill that generates vector fields automatically while the index is created and data is imported, so you get vector and hybrid search without deploying or running a model yourself.

Write clear requirements, get a plan first, code in small steps, and verify each one. Follow that workflow and your AI coding assistant will actually help you finish the project, instead of handing you a pile of code that won't run.