HTTP and Bearer Tokens: A Primer for Python Devs (2026)

The moment an agent tutorial leaves your laptop, the vocabulary shifts: POST this endpoint, send an Authorization: Bearer header, watch for a 401. If HTTP was always something other people’s code handled, that’s where deploy and MCP guides start to blur. This bearer token and HTTP primer covers just enough of the web’s plumbing to make those parts legible.

You don’t need to become a networking expert. You need a handful of ideas — methods, status codes, JSON bodies, and how a token rides along to prove who you are. Get those, and the MCP server and deploy tutorials stop assuming knowledge you were never handed.

HTTP in one picture: request and response#

HTTP is the protocol the web runs on, and the whole model is a conversation: a client sends a request to a URL, and a server sends back a response. Nothing is remembered between requests — each one stands alone, which is why APIs make you send your credentials every time (MDN).

A request carries four things worth knowing: a method (what you want to do), a URL (where), headers (metadata, including auth), and sometimes a body (data you’re sending, usually JSON). The response carries a status code (how it went) and a body (what you got back). That’s the entire shape — everything else is detail on top.

The methods and status codes you’ll actually read#

You don’t need all of HTTP, just the common verbs and replies. The methods:

• GET — read data (“give me this resource”).
• POST — send data or create something (“here’s a new chat message”).
• PUT / PATCH — update an existing resource.
• DELETE — remove one.

And the status codes, grouped by their first digit: 2xx worked (200 OK, 201 Created), 4xx you messed up (400 bad request, 401 unauthorized, 404 not found), 5xx the server messed up (500 server error). Read the first digit and you instantly know who’s at fault — your request or their server. That single habit makes debugging an API call far faster.

The bearer token: proving who you are#

Most useful endpoints aren’t open to the world — you have to prove you’re allowed. The standard way is a bearer token: a secret string you put in the Authorization header on every request. The name is literal — whoever bears the token gets access — so it’s a credential you guard like a password and only send over HTTPS (RFC 6750).

The header has one fixed shape:

Authorization: Bearer <your-token-here>

The literal word Bearer, a space, then the token. The server reads that header, validates the token, and either serves your request or replies 401 Unauthorized. A 401 almost always means a missing, malformed, or expired token — check the header before anything else.

Making an authenticated request in Python#

Here’s the whole thing in code, using httpx (an async-friendly client agents favour). A POST, a JSON body, and a bearer token in the headers:

import httpx
 
headers = {"Authorization": f"Bearer {token}"}      # the auth header
payload = {"message": "Hello", "session_id": "abc"} # the JSON body
 
resp = httpx.post("https://api.example.com/chat", json=payload, headers=headers)
 
if resp.status_code == 200:
    print(resp.json())          # parse the JSON response into a dict
elif resp.status_code == 401:
    print("Bad or missing token")

Read it against the four parts: method (post), URL, headers (with the bearer token), and a JSON body. The response gives you a status code to branch on and .json() to turn the reply into a dict. That’s the exact pattern an agent uses to call an MCP server or any authenticated tool — there’s nothing more to it.

Why agents and MCP servers lean on this#

Pulling it together: once an agent talks to the outside world, every tool call is an HTTP request, and every protected tool needs a token. A production MCP server validates a bearer token on each request before it runs a single tool — that’s what separates a deployed tool from a public API anyone can hit.

The build-an-MCP-server guide is built entirely on this idea, and the MCP client is the other half: it attaches the token so the agent is allowed in. Read HTTP and bearer tokens fluently and both stop being walls.

Quick recap#

The whole primer, in five lines:

• HTTP is request → response: method, URL, headers, body in; status code and body back.
• Know GET/POST/PUT/DELETE and 200/201/400/401/404/500 (first digit = who’s at fault).
• A bearer token proves identity, sent as Authorization: Bearer <token>.
• In Python, post a JSON body with the token in headers and branch on status_code.
• Agents and MCP servers validate that token on every protected request.

Frequently Asked Questions#

What is a bearer token? A secret string sent in the Authorization header to prove a client may call an API — whoever holds it gets access, so keep it secret and use HTTPS.

What does the header look like? Authorization: Bearer <token> — the word Bearer, a space, the token. A bad one returns 401.

Which methods and codes matter? GET/POST/PUT/PATCH/DELETE, and 200/201/400/401/404/500.

Why do agents use bearer tokens? Their tools are HTTP endpoints; a token per request lets the server authorise the caller before running a tool.

Conclusion#

HTTP is just request and response, and a bearer token is just a password that rides in a header to prove you’re allowed in. Learn the handful of methods, read status codes by their first digit, and recognise Authorization: Bearer for what it is, and the deploy and MCP chapters of any agent series stop assuming a background you were never given. It’s the web’s plumbing, demystified to exactly the depth an agent developer needs.

What tripped you up first — status codes, headers, or where the token goes? Tell me in the comments.