Rafał Nagrodzki presents

MCP: Connect Less, Ship More

How the Model Context Protocol lets an AI model use your tools, data, and prompts, and why every capability you connect is paid for in context, tokens, and reliability.

01 Part One

MCP replaced custom integrations with one standard

Before MCP, every AI-to-tool connection was custom-built

An AI app had to speak each tool's own API by hand.
Ten apps times ten tools meant a hundred separate integrations.
Every vendor did it differently, so nothing was reusable.
Connecting agents to real systems simply did not scale.

Integrate once.

what MCP changed

MCP is one shared standard between AI apps and your systems

It is an open standard, like HTTP for the web or USB for devices.
A tool speaks MCP once, and any MCP app can use it.
The app and your system no longer need custom glue between them.
Build the connection one time, then reuse it everywhere.

Every MCP connection has two sides

The app side

The AI product you already use.

Host: the app itself, like Claude Code or an IDE.
Client: the connection the host opens to one server.

The server side

Whatever you connect it to.

Server: a small program that exposes capabilities.
It offers tools, data, and prompt templates.

02 Part Two

A server gives the model tools, data, and prompts

A server exposes three kinds of capability

Tools: actions the model can take in the world.
Resources: data the model can read for context.
Prompts: saved templates a person can start from.
Together, these three are everything a server offers the model.

Make it concrete: one database server

What it exposes

One server, all three capabilities.

A tool: run a read-only SQL query.
A resource: the table schema.
A prompt: a saved "analyze this table" template.

How each gets used

A different driver for each.

The model calls the query tool to fetch rows.
It reads the schema resource to learn the columns.
You pick the analyze prompt to start the task.

Tools are the capability the model drives itself

The model chooses which tool to call, and when.
You do not pick for it; it decides from the list it is given.
That freedom is what makes an agent useful.
But to choose, the model must first see every tool available.

The exact exchange behind one tool call

tools/listserver lists each tool: name, description, inputstools/call  { name: run_query, arguments }server runs the query and returns the rowsnothing about run_query was wired in advancethe model discovered and called it at runtimeresources and prompts use the same list-then-fetch shape

The same protocol works locally or over the network

Messages use JSON-RPC 2.0, a simple request-and-reply format.
A local server runs as a subprocess and talks over stdio.
A remote server talks over HTTP, using Streamable HTTP.
Either way, the tool behaves identically to the app.

Tools aren't free.

what nobody budgets for

03 Part Three

Everything you connect is paid for in tokens

Every tool you connect lives in the context window

The model can only call a tool it can currently see.
So every tool's full definition is loaded before your request.
Name, description, and input fields, for every tool, every call.
You pay for that surface whether or not the tool is used.

This is one tool definition, and all of it loads into context

name: run_querydescription: Run a read-only SQL queryinputSchema: { sql: string, required }outputSchema: { rows, rowCount }annotations: { readOnlyHint: true }about 500 tokens, before the model reads your requestnow multiply by every tool you connected

/ The definition tax

What tool definitions cost before you type a word

~500 tokens

to describe one average tool, loaded on every request

25K tokens

already gone at 50 connected tools (500 × 50)

500K tokens

at a thousand tools, before your request is read (500 × 1,000)

Big raw results are paid twice, and hard to use

A query tool can hand back tens of thousands of raw rows at once.
That whole dump lands in the context window first.
To use it, the model must read back over every row.
Raw dumps are paid for twice, and hard to reason over.

One export, the same rows through the model twice

db.query('SELECT * FROM orders')tens of thousands of rows load into context as JSONthe model reads them all to answer one questionevery row is paid for on the way inand again as the model works back through themone small answer, tens of thousands of tokens

Return the answer, not the data

Dump

Raw rows, straight to the model.

Tens of thousands of rows land in context.
The model parses the whole table itself.
Paid for twice, and easy to get wrong.

Aggregate

The answer, computed on the server.

The server groups and totals the rows first.
It returns a few numbers, not a table.
Typed by an output schema, easy to use.

It gets worse.

cost was only half of it

04 Part Four

What you connect also makes the model worse

A crowded toolbox makes the model choose worse

Before every step, the model weighs all the tools it can see.
Similar tools blur together and get confused.
It picks the wrong one, or invents bad arguments.
Long multi-step tasks get more fragile as tools pile up.

Same task, fewer tools, far better results

60% 50+ tools loaded

92% 5 to 7 relevant tools

92 %

success with a focused toolset

Task succeeded

Task failed

It is not only tools: any full window reasons worse

Everything you load competes for the model's attention.
Chroma tested 18 leading models as inputs grew; every one lost accuracy.
A fuller window means worse reasoning, not just a bigger bill.
No error fires, you just get a confident, worse answer.

Build it to advise.

the fix starts with the server

05 Part Five

A good server advises the model, it doesn't just answer

The same information reads differently to every model

Two models can read one tool description and disagree on its use.
The same error text guides one model and stalls another.
You cannot assume the model fills in what you left implicit.
So spell it out: clear names, explicit inputs, unambiguous docs.

A server is business logic, not a thin API

Thin API

Passes the raw call straight through.

Returns whatever the underlying system returns.
Leaves every decision to the model.
Dumps data and hopes the model copes.

Advisor

Wraps the system with judgment.

Returns the answer the task actually needs.
Shapes and labels the result for the model.
Adds guidance, not just data.

A bare error stalls the model; a good one teaches it

A tool can fail and still return a helpful message, not a crash.
An error like 400 with no detail gives the model nothing to act on.
Say what failed, why, and what valid input would look like.
Flagged as an error, that message lets the model fix its own call.

For dangerous actions, the server asks first

Runs on its own

Safe, reversible calls.

Reading a record or running a query.
No confirmation needed, so the agent stays fast.

Stops to ask

Destructive or costly calls.

Deleting data, sending money, emailing a customer.
The server pauses and the client asks you to confirm.
You accept, decline, or cancel before it runs.

Connect less.

the other half of the fix

06 Part Six

Connect less, and ship more

Two habits that keep agents fast and accurate

Curate what you expose

Give each agent only the tools its job needs.

Scope tools to the workflow, not the whole catalog.
Cut overlapping tools so nothing blurs together.

Move work out of context

Keep big data out of the window.

Load only the tools a task actually touches.
Aggregate and filter results before they hit the model.

How sky4me builds MCP integrations

We connect only the tools a workflow truly needs.
We keep servers lean and tool definitions tight.
We make servers return answers, not raw data dumps.
We track the token bill, so it never surprises you.

Build agents that stay sharp

Let's audit what your agent connects

Book a working session and leave with a leaner, faster, more reliable tool surface.

Talk to sky4me