AniUI Academy

Connecting Tools With MCP

An open standard for giving Claude access to systems outside your codebase — issue trackers, databases, design files — and what each connection costs you.

9 min read

Everything in this section so far has been about the inside of your project: files you write, settings that shape a session. But a lot of the information you need while coding is not in the repository at all. It is in the ticket, in the staging database, in the design file, in yesterday's error report.

The usual way to get that information to Claude is to copy and paste it. This lesson is about not doing that.

What the protocol actually is

The Model Context Protocol, always shortened to MCP, is an open standard for connecting an agent to external tools and data. That is genuinely all it is: an agreed way for a program to say "here are the tools I offer, here is what each one does" and for a client to call them.

The value of it being a standard rather than a feature is that the work only happens once on each side. A company publishes an MCP server for their service. Any client that speaks the protocol can use it. Nobody writes a Claude-specific integration, and nobody writes a Sentry-specific feature inside Claude Code.

A server can be one of two shapes, and the distinction shows up when you connect one. A hosted server lives at a URL and you reach it over HTTP — most commercial services work this way. A local server is a program Claude Code starts as a subprocess on your machine, which is what you want for anything that needs access to a local resource like a database socket or a browser.

Issue trackers and project tools

Jira, Linear, Notion, GitHub. Claude reads the ticket itself rather than the summary you retyped, which means it sees the acceptance criteria, the comments, and the thing someone added on Tuesday that you forgot about.

Databases and monitoring

A PostgreSQL server so Claude can check what the data actually looks like instead of assuming. Sentry so it can read the stack trace for the error you are fixing rather than working from your description of it.

Design and browsers

Figma for reading a design directly. A browser server so Claude can open your local dev server, navigate it, and check that the page still renders after a change.

The through-line is the same in each case: Claude works from the source rather than from your summary of the source. Summaries lose the detail that turns out to matter.

Connecting one

Servers are added from your shell rather than from inside a session:

claude mcp add --transport http notion https://mcp.notion.com/mcp

Four parts. claude mcp add registers a server. --transport http says it is hosted at a URL. notion is a name you invent — it labels the server's tools in Claude's output and identifies it in later commands, and calling it docs would work identically. The URL is where the server lives.

A local server takes a command instead of a URL, after a -- separator:

claude mcp add playwright -- npx -y @playwright/mcp@latest

There is no --transport flag here because local servers use the default stdio transport, and everything after -- is the command Claude Code runs to start the process.

Many hosted services need you to sign in. Adding them works the same way, and then the server shows as needing authentication until you run /mcp inside a session, select it, and choose to authenticate — which opens your browser.

Checking what you have

Two commands. From your shell, claude mcp list shows every configured server with a status beside it: connected, needs authentication, failed to connect. Inside a session, /mcp does the same thing and more — it is where you authenticate, reconnect, toggle a server off without deleting it, and see how many tools each server is exposing.

That tool count is worth glancing at. It is the closest thing to a price tag.

claude

  1. WhyThe Linear server was connected before this session started, with a browser sign-in. The point of what follows is not the setup — it is what Claude reaches for without being told.

  2. You typed: Pick up ENG-2214 and implement it.

  3. Claude ran: linear - get_issue(ENG-2214)

  4. Output: ENG-2214  Export button times out on large workspaces
Description: CSV export blocks the request thread. Times out past ~50k rows.
Comment (Priya, 3 days ago): we agreed to stream the response rather than
buffering. Do NOT add a row cap — finance needs full exports.

  5. WhyThat comment is the whole lesson. Adding a row cap is the obvious fix and would have looked completely reasonable in review. The decision not to do it was made three days ago in a comment nobody would have thought to paste in.

  6. Claude replied: The agreed approach is streaming, and a row cap is explicitly out. Let me look at how the export is built today.

  7. Claude ran: Search: csv export

  8. Claude ran: Read src/exports/csv.ts

  9. You typed: How big does this actually get in practice? Don't guess.

  10. Claude ran: postgres - query

  11. Output:  workspace_id | rows
--------------+---------
  8821        | 412,006
  1190        | 96,338
  4402        | 71,915

  12. WhyTwo servers in one turn, and neither was named in the prompt. Claude picked the database because the question was about data. That is the usual experience — you stop thinking about which tool and just ask.

  13. Claude replied: The largest workspace is 412k rows, eight times the reported failure point, so streaming is the right call rather than raising a buffer. I'll stream the CSV and add a test that exports 500k synthetic rows without holding them in memory.

  14. WhyNotice the shape of the win. Nothing here was impossible before — you could have opened Linear, read the comment, run the query and pasted all three in. What changed is that Claude got the real numbers instead of your recollection of them.

The constraint that would have been missed was in a comment, not the ticket.

What it costs

Every connected server occupies some of your context window, because its tool names and its server instructions load into every session. That is the honest version, and it used to be worse.

By default, MCP tool definitions are deferred. Rather than loading the full schema of every tool from every server at startup, Claude Code loads the names, and Claude searches for the tools a task actually needs when it needs them. Only the ones it uses enter context. This is called tool search, and it is why you can connect several servers without immediately halving the room you have to work in.

  1. Step 1

    Session starts

    Tool names and each server's instructions load. Cheap.

  2. Step 2

    A task needs something

    Claude searches the available tools for one that fits.

  3. Step 3

    The definition loads

    Only the schemas Claude actually calls end up in the conversation.

The same pay-on-use idea behind skills, applied to tool schemas.

If that pattern feels familiar, it should. It is the same shape as a skill: advertise cheaply, load on demand. The recurring lesson of this whole section is that context is the scarce resource and everything good is designed around spending less of it.

Still, cheap is not free. A server you added to try once and never used again is a small permanent tax on every session, and there is no reason to keep paying it. Remove it with claude mcp remove.

Sharing with your team

Scope works the way it has everywhere else in this section, with one practical wrinkle: you choose it when you add the server and there is no command to change it afterwards, so moving a server between scopes means removing it and adding it again.

By default a server is added at local scope — yours, and only in the project you added it from. --scope user makes it yours across every project. --scope project writes it to a .mcp.json file at the project root, which you commit like any other configuration.

That last one has a safety step attached. When a teammate clones the repository and starts Claude Code, they are asked to approve the server before it connects. The prompt exists so that cloning a repository cannot silently start a process on your machine.

Be honest about the tradeoff

Which brings us to the part that deserves more than a footnote.

Every server you connect is more surface area. You are granting an external system a channel into your working session, and depending on what it is, it may see your requests and it may be able to act. A database server that can write is a different proposition from one that can only read.

The subtler risk is worth naming properly. Content that comes back from an MCP server lands in Claude's context, and it is text — which means it can contain instructions. An issue description, a web page, a comment on a ticket: any of these could contain something written to influence an agent reading it. This is called prompt injection, and it is the reason the docs tell you to verify that you trust a server before connecting it, and the reason permissions still apply to MCP tools the same way they do to anything else. There is a lesson on security later in the course that goes further.

None of this is an argument against using MCP. It is an argument for connecting servers deliberately, one at a time, because you had a reason — not collecting them because they were available.

What to take away

MCP is an open standard for connecting an agent to tools and data outside your codebase, which means a service publishes one server and every client that speaks the protocol can use it. You add one with claude mcp add, giving it a transport and a URL for a hosted server or a command after -- for a local one, and you check on it with claude mcp list from your shell or /mcp inside a session. Tool definitions are deferred by default and loaded on demand, so only names and server instructions occupy context until a task actually needs something — the same pay-on-use design as skills. Scope decides who gets the server, with .mcp.json at the project root as the committed, team-shared option. The real value is that Claude reads the ticket, the table or the design directly rather than your paraphrase of it, and the real cost is that every connection is a system you have chosen to trust.

Next: subagents, which solve the other half of the context problem by letting work happen somewhere other than your main conversation.

Check yourself

5 questions · pass 4/5 to unlock Subagents

up to 50

  1. 1.What is the Model Context Protocol?

  2. 2.What does claude mcp add --transport http notion https://mcp.notion.com/mcp do?

  3. 3.Why does connecting several MCP servers not immediately consume a large amount of your context window?

  4. 4.You want your whole team to get a server automatically. Where does it belong?

  5. 5.What is the main risk of connecting an MCP server?

5 left to answer