Model Context Protocol (MCP) extends what your AI agent can do beyond its built-in tools like database access, internal APIs, Confluence, Jira, Bitbucket, and more. You connect your agent to an MCP server, and it gains new capabilities.

But do you know how much your MCP is actually costing you? Or your users?

Wait, MCP’s cost money?!​

Your MCPs are eating your context window

Every time you send a request, your MCP tools and their parameters are loaded into the context window, before your prompt even gets processed. Unless your agent app supports tool search (many don’t), all tools from all enabled MCP servers are injected into every single request.

A real example that happened to me: adding just 2 MCP servers injected 13,000 tokens into the context. That’s roughly 9,750 words, or about 16–17 A4 pages of text sent with every. single. request.

That’s not free.

A smaller, purpose-built toolset often works better

The sweet spot for an MCP server is up to 10-15 tools. Push to keep it lower if you can.

Tools aren’t just names! Every parameter, description, and enum value counts toward your token budget. A server with only 5 tools but 20 parameters each can hurt more than one with 15 lean tools.

Beyond 30-40 tools, performance degrades noticeably. The model struggles with choice paralysis, and context bloat leaves less room for your actual data and instructions.

Group by domain

Real life example: a service exposed a single MCP with 30+ tools, but most users only needed a small subset. The rest were admin-only, so every user had to load a lot of irrelevant tools into context. A better design would be to split it into separate user-facing and admin MCPs, so each group only loads the tools they actually need.

Instead of one monolithic server with 50 tools, create multiple focused servers with 5-10 tools each:

• Client-facing MCP – customer data, orders, support tickets
• Internal admin MCP – infrastructure, monitoring, deployments
• Knowledge base MCP – docs, wikis, search

Then enable only the servers relevant to your current project. If you’re debugging an API, you don’t need the HR system’s tools loaded.

An MCP is a service, not an API wrapper

This is the mistake most teams make: treating MCP as a 1:1 mapping to their REST API.

It’s not. An MCP tool is a capability, not an endpoint. One tool can and should call multiple API endpoints, aggregate results, and transform data into something the model can actually use.

❌ Bad: createUser, updateUser, getUser, listUsers, deleteUser, getUserPermissions, setUserPermissions... ✅ Good: manage_user - handles creation, updates, permission changes, and returns a clean summary

Think of your MCP as a service layer, not a pass-through proxy. The model doesn’t need to orchestrate 7 API calls, it needs to accomplish a task.

What goes out matters as much as what comes in

Your MCP’s output gets loaded right back into context. If your tool returns raw API responses, you’re burning tokens on JSON scaffolding the model doesn’t need.

For example, we had a custom MCP that simply wrapped an internal service and returned its raw response. The problem was that the service was built for the web app, not as a clean API, so it included a lot of extra metadata. In some cases, the response was so large it could overwhelm the context window almost immediately.

Transform your output before returning it to the model:

• Strip metadata, headers, and internal IDs the model won’t use
• Summarize large text fields instead of returning full bodies
• Return structured summaries, not raw API dumps
• Use MCP resources for large static datasets, they’re fetched on demand, not injected into every request

The principle: return only the information the model needs to answer the question. Nothing more.

For dynamic queries, let the user constrain the output

If a search could return 10,000 results, your tool should require filters, limits, or pagination. Never let a single tool call potentially flood the context.

Do’s and don’ts

Disable MCPs you’re not actively using. Every enabled server costs tokens on every request. Move project-specific servers to the project config instead of your global user config, different projects should use different tools.

MCP is powerful, but it’s not magic. Treat it like a curated service layer – intentional tools, minimal surface area, and output shaped for the model, not a raw API passthrough. Your context window (and your token bill) will thank you.

Before you go – put MCPs at the right level

Most agent tools let you register MCP servers at two levels: user (global, applies everywhere) and project (scoped to a specific repo or workspace). Where you place your servers matters just as much as how many you have.

MCPs registered at the user level are loaded into every session, every project. That Jira MCP you added last month? Still eating tokens while you’re doing local refactoring that has nothing to do with tickets. The database MCP for project A? Still loaded when you switch to project B’s frontend work.

Rule of thumb:

• User level – only general-purpose servers you genuinely use across all projects (e.g., a file system tool, a web search MCP)
• Project level – everything else. Project-specific APIs, team dashboards, domain-specific databases. These belong in your project config, not your global settings.

Think of it like your toolbox: you don’t carry a welding torch, a pipe wrench, and a soldering iron to every job. You only grab what the task actually needs. Same with MCPs. Keep your global config lean and let each project pull in only what it uses.

And regularly audit what’s enabled. That experiment from three months ago? The MCP you added for a one-off migration? Disable them. They’re still costing you tokens on every request.

The post MCPs Aren’t APIs – Stop Treating Them Like One appeared first on ShiftMag.

Picture this scenario: You’ve just joined a new tech company, excited to start onboarding and dive into your first projects. But soon, it hits you – the tension.

Developers gripe about sluggish and obstructive DBAs, while Database Administrators grumble and murmur about the constant stream of poorly optimized queries, chaotic code, and last-minute demands from developers.

Did you stumble upon a toxic workplace? Not exactly. It’s the age-old clash that’s been brewing for decades between two ‘tribes’: those who want to build quickly and those who safeguard stability.

So, do DBAs play the role of protectors, or are devs just a tad bit spoiled?

How did we get here?

The friction comes from a classic disconnect: speed vs. stability.

Developers are eager to ship features as fast as they can (preferably yesterday), often under pressure from clients, management, or some other deadline-driven force, while DBAs are focused on ensuring the database doesn’t crash tomorrow.

When these priorities clash, chaos is inevitable – and I know this firsthand because I’ve been on both sides.

Let’s take a closer look at it from a developer’s angle

• ‘We need to speed up our delivery!’

The main argument is that developers often work under tight deadlines. To them, a database is just a tool – the simpler, the better. Why involve DBAs early if it slows down prototyping?

There’s also a prevailing ‘good enough for now’ mentality, where getting a working prototype is the priority.

• ‘Setting up new databases takes ages.’

Waiting for approvals, scheme checks, or infrastructure setups feels like watching paint dry.

• ‘Getting DBAs involved can feel like pulling teeth.’

When DBAs push back on quick fixes or demand documentation, developers see red tape rather than guardianship.

Now, let’s dive into the DBA’s side of the story

• ‘We’re called in too late!’

DBAs often inherit poorly designed schemas or performance nightmares. Fixing a burning database at 2 a.m. is never fun, especially when you don’t know anything about it or where to begin.

• ‘Devs don’t listen.’

Recommendations about indexing, query optimization, or security often fall on deaf ears – until an outage happens. No matter how many times you share documentation, hold knowledge-sharing sessions, or discuss the topic, it sometimes feels like no one listens.

• ‘We’re the unsung janitors.’

While devs chase innovation, DBAs clean up the mess. Their priorities – backups, scalability, and compliance – may not be glamorous, but they’re non-negotiable.

If a company wants to make it in the worldwide market, it needs to be compliant with numerous regulations. And that is just the beginning – data needs to be secured, and data leaks and privacy concerns aren’t fun for anyone. We need backups and replication set up for disaster recovery, satisfy numerous architecture decision records, and all that complicates the process. It will never be as simple and fast as just deploying a DB locally in Docker.

So, what do devs and DBAs really want?

DBAs just want preventative care – they’re like doctors urging you to eat your veggies, not just treating heart attacks.

On the other hand, devs need speed without fallout. They want to innovate without waking up to a dumpster fire.

But do devs really want to own databases?

Sure, devs can deploy their own database, but maintaining performance, security, and costs? That’s a full-time job – one many devs aren’t signing up for.

It may sound great at first, but once you deploy it, the database works fine – until it doesn’t. It’s just a matter of time before the first issues arise. And surely, devs would rather spend their time programming than maintaining and troubleshooting a database.

Think it can’t get worse? Well, say hello to AI

Enter AI and vector databases – tools promising lightning-fast analytics.

The number of new vector databases is skyrocketing, and devs want them all, each with a specific feature they need. But for DBAs, this is a nightmare. Integrating a new database is a slow and painful process, as all checks for security, compliance, and requirements need to be tested and approved. New database types (e.g., vector DBs for ML) often lack mature tooling or expertise. DBAs scramble to secure and scale them, while devs resent the learning curve.

So, who is right?

They both are, and at the same time, they both aren’t – much like the relationship between devs and clients.

Devs often complain about clients’ broad demands, tight deadlines, and constant changes. Sound familiar? The Dev vs DBA battle is similar: devs forget that, as clients of DBAs, they’re the ones pushing for deadlines and changes, just like clients do to them.

So, devs must make compromises with clients because the company’s revenue depends on it. However, I think DBAs tend to be ‘harder’ on their clients since they don’t face the same pressure of potentially losing business.

Is there hope for peace?

There isn’t – at least not a simple one.

But we can all work together to reduce tension and aim for some kind of truce. We need to be more understanding.

Devs should recognize that DBAs aren’t just complicating things for no reason and should involve them in the service architecture process. On the other hand, DBAs should view devs as clients, understand the need for compromise, and simplify the process of providing databases by using automation or internal tools whenever possible.

The post Devs and DBAs can’t find peace, but could they call a truce? appeared first on ShiftMag.