0:01Last time we said connecting a server is a trust decision, ours to make. This video looks at the other side, the server itself, and what wrapping a real service takes.
0:11This is GitHub itself, the real service we want our agent to work with. Its API can read and change things that really exist, like the issues on a repository.
0:21A real API also pushes back. Most of what it offers needs a caller it can identify. Long results come back a page at a time, and a bad request fails with an error code.
0:32For MCP, GitHub's engineers ship a server of their own. We didn't write this one, the people who run the service wrote it, against their own API.
0:41Both boxes belong to the same company. The server is part of the product, maintained beside the API it wraps.
0:47To our agent, it is simply another server, same client, same protocol. Everything the service demands gets handled on the other side of this connection.
0:56Let's plug it in.
0:58Here is our agent's file again. The loop that serves the model is unchanged, what changed is the server list at the top.
1:05One entry now. It starts the GitHub server as a local process on this machine, the same way our own servers started.
1:12The command names the binary we installed, GitHub's own code. The last argument sends its log to a file, so the terminal stays readable.
1:21The rest of the entry hands the server one secret - a personal access token. That token is its identity at GitHub. Everything it touches, it touches as our account.
1:32How much that account risks is decided where the token is made. GitHub can limit a token to chosen repositories and permissions, least privilege again, set at the source.
1:42That is the whole configuration, one entry, and one token. Let's run it.
1:47We'll give it a real piece of housekeeping from this repository.
1:49The task has two parts, check the open issues for a license request, and file the issue only if it is missing.
1:57One server this time. It reports its name, and offers the model forty four tools.
2:02Forty four tools, from one server. GitHub's team picked them out of everything their API can do, and wrote each name and description for a model to read.
2:11That choosing is the craft in a server. A tool does one job the model would ask for. Its description says when it fits, and each argument is something the model can supply from the task.
2:21The model starts with reads. It searches the issues, then lists the open ones, checking for an existing request before it creates anything.
2:30Below the reads comes the write.
2:32One tool call creates the issue, the title and the body are the model's own wording.
2:37The answer names what it made, with the address. That issue now exists on GitHub, filed by the account behind our token.
2:45That is the whole run. Let's read it once more on the picture.
2:50Here is the picture again, the run we just watched, seen from the server's side.
2:54Every call was a round trip, through their server, into the service, and back again.
2:59What came back was already sized for a model. A repository can hold thousands of issues, the server pages and caps what a single call hands over.
3:08When a call fails, what comes back is a message naming what went wrong. A host can hand that message to the model, ours would simply stop.
3:16And one call left something behind. The issue is really there, anyone who opens the repository will see it, filed by the account whose token we handed over.
3:24The run never paused to ask us anything. That approval gap is still ours to close, and a write is exactly where a real host puts the question.
3:32Put together, the division of labor is plain. Their server faces everything the service demands, our model faces tools it can call correctly.
3:41That division is the whole job, and it is what wrapping a real API means.
3:46This is the video in one line. A server takes a real service, with everything it demands, and makes it callable for a model.
3:53The demands don't go away. They're handled inside the server, once, by the people who know the service best, for every host that connects.
4:02Ours ran as a process on our machine. Servers also run remotely, behind a network address, and that changes the connection itself. That's the next video.

Wrap a Real API

Created by Abhyuday DesaiPublished 2 Oct, v1Runs 4 min 17 sec

0 views

About this video

In Episode 12 of MCP Explained, the service is real. GitHub's own engineers ship an MCP server for their API, and we plug it into our agent with one entry and one scoped token. A real housekeeping task runs: check the open issues for a license request, and file one only if it is missing. Then we read the run from the server's side: forty four curated tools, results sized for a model, errors as messages, and a write that left a real issue behind.

You'll learn how to:

See what a real API demands, identity, paged results, and error codes, and where those demands get handled
Configure a production server with one list entry and a personal access token, scoped at the source
Learn what makes a tool well made: one job each, a description that says when, and arguments a model can fill
Watch the model read before it writes, and see the write land as a real issue on GitHub
Understand the division of labor: their server faces the service, your model faces tools it can call correctly

This video is for developers comfortable with Python and calling a model API. Every command is shown on screen and runs from the companion repo.

What changed

v102 Oct 2026abhydesai4 min 17 sec805b43c

First published version.

0 views0 likes on this version