If you would like to go through video version of this article, you can find it here.

I'll start with a basic architecture and then, show the basic test cases that can be performed.

What is MCP?

Think of MCP as a standard way for AI applications to talk to external systems. Instead of hard coding integrations, MCP provides a structured way for:

  • AI apps
  • clients
  • and servers

to communicate with each other.

None
Before MCP was introduced: A fragmented Mess (dev.to)

But why did we introduce MCP?

Imagine having to manually wire up every single API connection for each service your AI needed to talk to.

You had to:

  • Create custom authentication for each service
  • Write specific data transformation logic for different APIs
  • Build specialized error handling for each integration

And as soon as you wanted to add another tool to your AI application, you'd have to do it all over again.

Think of MCP as creating a universal translator between AI models and external tools. Instead of building custom connections for each tool, developers can now use a single, standardized protocol. It's like we suddenly agreed on one type of power outlet for the entire world!

None
Model Context Protocol (source: dev.to)

Architecture

  • First, we have the MCP Host — this is your AI application, like ChatGPT or any AI agent.
  • Then we have the MCP Client — this acts like a middleman. It connects to servers and fetches data.
  • And finally, the MCP Server — this is where the actual data or functionality lives.
None
Source: https://medium.com/@tahirbalarabe2/

Layers

MCP works in two layers.

First is the Data Layer — this defines how messages look.

It uses something called JSON-RPC, which is just a structured JSON format for sending requests and responses.

Second is the Transport Layer — this defines how the messages are sent.

Basically:

  • Data layer = what we send
  • Transport layer = how we send it

Transport Types

STDIO

This is used when the client and server are running on the same machine. The way it works is outlined below:

  • The client starts the server as a process
  • The client sends messages through standard input — stdin
  • The server replies through standard output — stdout

So basically, they're talking directly through the terminal pipes.

No network. No HTTP. Just direct communication

HTTP + SSE

Now this is the one we care about for testing — Streamable HTTP transport.

Here:

  • The client sends requests using HTTP
  • The server responds normally or
  • It can stream responses using something called SSE — Server-Sent Events

Now what is SSE? — Think of SSE like a live feed.

Instead of sending one response and closing the connection, the server keeps the connection open and keeps sending updates.

Kind of like:

  • live scores
  • notifications
  • or streaming logs
None
Source: gelembjuk.hashnode.dev

Primitives

  • Tools — These are functions the AI can call. For example, get weather, query a database, etc.
  • Resources — This is just data. Like files, API responses, or records.
  • Prompts — These are templates that help structure AI responses.

Handshake

  • Every MCP Integration beings with something called an initialize request.
  • The server responds with an initialize response
None
The initialize request

Session Handling

When using HTTP transport:

  • The server may return something called an Mcp-Session-Id
  • This acts like a session token
  • Every request MUST include this header

Look at the above screenshot, there's a Mcp-Session-Id header in the response.

Listing Capabilities

Now that we can interact with our MCP server, let's list the tools supported by the MCP server. We can do it through the tools/list method. Also, note that we've included the Mcp-Session-Id header token in the request.

Our MCP server supports:

  • Four functions/operations (add, subtract, multiply and divide)
  • Two arguments (a and b)
None
Listing the tools

Interacting with the Tool

The next step is to interact with the tool. We can do it through the tools/call method. We'll pass the name of the function/operation and the arguments that it accepts.

None
The tool is called.

This brings us to the end of the article. We can use this article as a baseline to check for authentication, authorization, session management and input validation test cases. So, testing MCP became quite simpler.

Interacting with the MCP server using an AI chatbot or similar test cases are out of scope for this article. Maybe we can discuss them in future.

Hope you enjoyed reading the article. Please consider subscribing and clapping for the article.

In case you are interested in CTF/THM/HTB writeups consider visiting my YouTube channel.