Module 3 — Connecting to MCP

Your First MCP Handshake

Before you can build anything, you need to know the language. MCP servers talk to clients through three types of primitives — tools, resources, and prompts — and every interaction you'll ever have with an MCP server comes down to one of those three things. This lesson is your decoder ring.

By the end of this lesson
1Understand the difference between tools, resources, and prompts — and why it matters for how you write your requests
2Create your first MCP request in Postman and connect to a live server
3Know when to use STDIO vs streamable HTTP transport — the two modes MCP supports
4Read and decode a real MCP server response without the documentation open
 

The Three Primitives Explorer

If MCP is the telephone system connecting your AI to the world, then tools, resources, and prompts are the three types of calls that telephone system can handle. They look similar at first glance — they're all things a server "has" — but they do fundamentally different things. Getting these straight is the difference between knowing what to ask for and guessing.

🎛️
Interactive: Click each tab below to explore the three primitives. Each one shows you what it is, a real-world analogy, and what the actual JSON looks like when you call it.
Primitive 1

Tools

Tools are actions the server can perform on your behalf. When an AI model uses a tool, something actually happens — a calendar event gets created, a database query runs, a file gets written. Tools have inputs and produce outputs, and they can have side effects.

Tools are like ordering from a menu. You pick a dish, the kitchen does the work, and you get the result. You don't need to know how to cook.
Common examples
create_calendar_event send_slack_message query_database search_docs create_github_issue
Request — calling a tool
// POST to MCP server
{
  "method": "tools/call",
  "params": {
    "name": "create_calendar_event",
    "arguments": {
      "title":    "Team standup",
      "datetime": "2026-03-10T09:00",
      "duration": 30
    }
  }
}
✓ Server response
{ "content": [{ "type": "text", "text": "Event created: Team standup on March 10 at 9:00 AM (30 min)" }], "isError": false }
Primitive 2

Resources

Resources are data the server exposes for reading. They're identified by a URI and can contain files, database records, API responses, logs — anything a model needs as context. Resources are read-only by nature; they give the model information without triggering side effects.

Resources are like a reference library. You check out a book to read it, but checking it out doesn't change the book — or the library.
Common examples
file:///project/README.md db://users/profile/{id} api://metrics/today git://repo/main/diff
Request — reading a resource
// POST to MCP server
{
  "method": "resources/read",
  "params": {
    "uri": "file:///project/src/main.rs"
  }
}
✓ Server response
{ "contents": [{ "uri": "file:///project/src/main.rs", "mimeType": "text/x-rust", "text": "fn main() {\n println!(\"hello\");\n}" }] }
Primitive 3

Prompts

Prompts are reusable message templates the server provides for interacting with a language model. Think of them as pre-written conversation starters with variable slots. A server might offer a "code review" prompt that already has the right instructions baked in — you just fill in your code.

Prompts are like mad libs written by an expert. The server fills in the tricky structural parts; you supply the details that change each time.
Common examples
summarize_document code_review explain_error draft_reply
Request — getting a prompt
// POST to MCP server
{
  "method": "prompts/get",
  "params": {
    "name": "code_review",
    "arguments": {
      "code": "def hello():\n  print('world')",
      "language": "python"
    }
  }
}
✓ Server response (a messages array)
{ "messages": [{ "role": "user", "content": { "type": "text", "text": "Review this Python code for style, correctness, and edge cases: ..." } }] }

One more thing worth knowing: the three primitives aren't mutually exclusive in a single server. A well-designed MCP server might expose resources (your calendar data), tools (create an event), and prompts (a scheduling assistant template) all at once. Postman's MCP request lets you browse all three from one place — more on that in a minute.

 

Two Transport Modes: STDIO vs HTTP

Every MCP server picks a transport layer — the plumbing that carries messages back and forth. There are two options, and which one you use depends on where the server lives and how it's running. The good news: Postman handles both, and swapping between them is just a dropdown.

 
Transport 1
🖥️

STDIO

Standard Input/Output — the server runs as a local process on your machine. Postman spawns it for you with a command like npx @company/mcp-server.

Best for: Local CLI tools, development, anything you install via npm/pip.

 
Transport 2
🌐

Streamable HTTP

The server lives at a URL — deployed in the cloud or running locally on a port. You point Postman at an endpoint like https://mcp.example.com/mcp.

Best for: Remote servers, production deployments, team-shared integrations.

Here's what the setup looks like in Postman for each. The configuration fields change slightly, but the workflow — connect, browse capabilities, run a request — stays exactly the same.

Postman MCP Request Setup
// ── STDIO Transport ──────────────────────────────
// The server runs on YOUR machine as a subprocess.
// Postman spawns it using the command you provide.

Transport: STDIO

Command:   npx -y @postman/mcp-server

// Authentication: use the Environment tab
// Add key-value pairs for any API keys your
// server needs. Postman passes these as env vars.

Environment:
  POSTMAN_API_KEY  =  {{postman_api_key}}

// Then click "Load Capabilities" — Postman
// starts the process and shows available
// tools, resources, and prompts.
// ── Streamable HTTP Transport ────────────────────
// The server lives at a URL — cloud or local port.
// Postman connects over HTTP.

Transport:  HTTP

URL:        https://mcp.postman.com/mcp
            (or http://localhost:3001/mcp for local)

// Authentication: use the Authorization tab
// Select your Auth Type (Bearer, API Key, OAuth)
// and fill in your credentials.

Authorization:
  Auth Type:  API Key
  Key:        x-api-key
  Value:      {{api_key}}
  Add To:     Header

// Then click "Load Capabilities" — Postman sends
// an initialize request and displays the server's
// tools, resources, and prompts.
💡
Not sure which to use? If there's a URL, use HTTP. If the setup instructions say "install via npm" or "run npx", use STDIO. When in doubt, check the server's README — any well-documented MCP server will tell you.
 

Watch: Creating Your First MCP Request

Here's a full walkthrough of creating an MCP request in Postman from scratch — connecting to a real server, browsing its capabilities, and running your first tool call.

 
Demo: Creating Your First MCP Request in Postman
Video placeholder — replace with embed
 

Decode This Response

Theory is good. Practice is better. Below is a real MCP server response — the kind Postman shows you in the Response tab after you run a tools/call request. Click each line to see exactly what it means and why it's there.

Read the Room
Click any highlighted line in the JSON to see its annotation.
1"jsonrpc": "2.0",
2"id": 42,
3"result": {
4 "content": [{
5 "type": "text",
6 "text": "Calendar event created."
}],
7 "isError": false
}}
Line 1
JSON-RPC version
MCP is built on the JSON-RPC 2.0 spec. This field is always "2.0" — it's a protocol handshake, not a version you'd ever change.
Line 2
Request ID
This echoes back the id from your original request. Useful when you're sending multiple requests — it's how you match responses to requests in async flows.
Line 3
Result vs. Error
A successful call gets a "result" field. A failed one gets "error" instead — with a code and message. If you see "result", the server did what you asked.
Line 4
Content array
Tool responses always return a content array — because a single tool call can return multiple items (text, images, embedded resources). Most common case: one text item.
Line 5
Content type
Each content item declares its type. The spec supports text, image, and resource. For most tool calls you'll see text — the human-readable result.
Line 6
The actual payload
This is what the tool returned — the real output you care about. If an AI model called this tool, this text would be injected into its context for the next response.
Line 7
Application-level error flag
isError: false means the tool ran successfully. isError: true means the tool ran but encountered a problem — like a calendar API that rejected the event. Note: this is different from an HTTP error or a JSON-RPC error.
🔍
In Postman: when you run an MCP request, this full JSON structure appears in the Response tab. You can also watch real-time server notifications appear in the Notifications tab — useful for servers that stream progress updates as they work.
 
🤝
Try This

Make Your First MCP Handshake

Open Postman and connect to a real MCP server — right now. The Postman API Network has a growing catalog of servers ready to test, no setup required.

1In the Postman left sidebar, click + → MCP to open a new MCP request tab.
2Choose HTTP transport, then search for a server from the Postman MCP Catalog. Try the Postman MCP Server as a starting point.
3Click Load Capabilities. Browse the Tools, Resources, and Prompts tabs — notice how each primitive looks different.
4Pick a tool, fill in its arguments, and click Run. Check the response JSON — can you identify the result.content and isError fields?
🔧
Up Next

Teaching Your Agent New Tricks