Build your own connector (MCP)

Your agent probably knows which emails you have not read yet, or which tickets are assigned to you in Jira. Now ask it for today’s weather, or how much disk space is free on a remote server. Either it cannot tell you, or it gives you a slightly different answer every time you ask.

The reason is simple. For some jobs it has a real tool, through the connectors you wired up. For everything else it improvises.

That gap is yours to close, and closing it is what this course is about.

If you are not technical, building your own connector sounds like a big ask. It is not one any more. You saw in the vibe coding track how good agents are at building things alongside you, and with the right skill in hand this is one of the easier things to build.

Why build your own connector

Your agent can only act in the systems it can reach, and out of the box that list is short. It can talk about your booking tool all day. It cannot book the room.

An MCP server is how you extend that list yourself. It tells the agent what an app can do and how to do it: book a room, check the weather, look up a customer. Then the agent does it mid-task, without you switching windows.

Think of it as an API, but for agents. Programs have talked to each other this way for decades. MCP is the same idea in a form any agent understands, with authorization built in. The agent acts with your access, so it reaches whatever you can reach.

So when do you build one? If a connector already exists, use it. If you only need something once, a quick script is fine. You build an MCP server when you want your agent to reach a service again and again, on its own, inside bigger tasks.

An MCP tool gives you less flexibility than letting the agent write the code itself, and in exchange you get consistency. The same call, the same shape, every session. Permissions get much easier to manage too, because the tool is a named thing you can allow or deny. For anything you plan to repeat often, that trade is worth making.

The previous course was about making sure your agent knows the right things. This one is about which external systems it can reach, and how you connect them, so it ends up with the visibility it needs and the ability to act on it.

We are building a personal connector that runs on your own machine. That is the right place to start, and often the right place to stay. It piggybacks on the access you already have, so there is no server to stand up and nothing to keep secure on someone else’s behalf.

Once it works, you can ask Claude to turn it into something you host, or something a colleague installs. Build a plugin closes this track with exactly that.

Step one: decide the tools

A tool is one thing your agent can do, or one thing it can look up. Get the forecast. Look up a customer. Nothing grander than that.

Usually a tool bundles a few steps against a system you already use into one clean action. Our example wraps Open-Meteo, which is free and needs no sign-up or key.

Give each tool a single job and a name that says so. get_current_weather and get_forecast beat a vague weather that leaves the agent guessing. The short description matters just as much, because the agent reads it when deciding whether to call the tool at all.

Then decide what comes back, and the rule is the one from memory and context. The agent wants the most relevant answer and the most complete one, with as little else attached as possible. Hand back “18 degrees and clear” rather than forty lines of raw data. If something will not help the agent decide anything, leave it out.

Let a tool come back empty-handed when that is the honest answer. One that finds nothing should say so plainly, and one asked to do something it should not do can decline and explain why.

For each tool, note whether it only reads or whether it changes something. Your permission rules hang off that later.

The best way to get all of this right is to work it out with your agent. Describe the system and what you want from it, and have it propose the tools. What you end up with is a short list: each tool, what it does, what you give it, and whether it reads or writes. That list is the scope of the whole project, and you approve it before any code exists.

Step two: let the skill build it

Once the tools are decided, the skill writes the code and you review it. The build-mcp skill, from TechWolf’s tool-build-kit plugin, walks you through the build. It hands the code itself to Anthropic’s mcp-builder, which handles the structure, the input checks, and the error handling better than a from-scratch prompt would.

You do not need to follow every line. You need to know it works, and there are three plain signs.

• The code builds without errors.
• Connect it, then ask your agent what tools it sees. Every one you asked for shows up.
• It can actually call a tool and get a sensible answer back.

The third one matters most. A server your agent cannot call is not finished, however tidy the code looks.

Step three: use it and iterate

A connector that works on day one is rarely the one you want by day ten. This is the same as building a skill. The first version does the job, and then real use shows you the version you actually wanted.

Watch for friction and fix it as you go, because that is where most of the leverage turns up.

If your agent keeps making six separate calls to get the weather for six locations, add a tool that takes a list and returns them all at once. That is five fewer steps and five fewer chances to go wrong.

If it calls the wrong tool, or calls nothing when it should have, the description is usually the problem. Rewrite it for the agent reading it, and the same goes for anything else the agent sees before deciding.

And pair the connector with skills. The connector gives your agent the ability to act. A skill tells it how you want a particular job done with that ability. Together they turn a set of tools into something that just works when you ask.

Keep doing that and the connector gets smoother every week, until asking for the thing is genuinely less work than going and getting it yourself.

Hands-on

/plugin marketplace add techwolf-ai/ai-first-toolkit
/plugin install tool-build-kit@techwolf-ai-first

Reflect

• You picked a tool to wrap next. Is it the one that would genuinely save you the most, or just the easiest one to build? Be honest about which one it is.
• Does that thing have an API, or any way in that a program could call? If yes, you can almost certainly wrap it. If no, finding a way in is the problem to solve first.

Recommended reading

Want to go deeper on any of this?

• Model Context Protocol (Anthropic). What MCP is, and the open spec every agent understands.
• Connect Claude Code to tools with MCP (Anthropic). How to add a server to Claude Code and call it from a session.
• build-mcp skill (TechWolf). The skill this course mirrors. Run it on your own tool.