When NOT to Build an MCP Server (Part 2): Specific Anti-Patterns

In our previous article, we looked at when not to use MCP and why traditional APIs, automation platforms, and custom integrations can still be the right choice for predictable workflows. This part covers the MCP anti-patterns that appear after you have decided to build one.

The reason this question matters is simple. MCP is attractive because it gives AI agents a flexible way to interact with tools, data, and external systems. But that flexibility can also encourage teams to introduce MCP where a simpler approach would have been enough.

That practical distinction is what made the original discussion important.

This follow-up takes the question one step further.

What happens when you have already decided to use MCP, but the implementation itself starts becoming too complicated?

A team can build an MCP server that technically works while still creating unnecessary security risks, context management problems, maintenance work, or authentication issues.

These are some of the specific MCP anti-patterns teams should consider before building or expanding an MCP server.

Anti-Pattern 1: Giving an Agent More Tools Than It Needs

One of the easiest ways to overcomplicate an MCP implementation is to expose every available operation to an AI agent.

Imagine a customer support application connected to an order management system.

The underlying API might allow the application to:

• Search customers
• View customer records
• Search orders
• View order details
• Update orders
• Cancel orders
• Issue refunds
• Change account settings
• Delete records

The customer support agent may only need to search customers, view orders, and check delivery status.

There is little reason to give that agent access to every other operation.

This is known as MCP tool overexposure.

The official MCP documentation on tools explains how MCP servers expose callable functions that clients can discover and use.

Why Tool Overexposure Matters

Every tool exposed to an agent represents another action the system can potentially take.

This becomes especially important when tools can modify or delete information.

For example, an agent answering:

"What is the status of order 5821?"

does not need permission to cancel the order.

Likewise, an agent helping a customer find account information does not automatically need access to billing changes or administrative settings.

This is where the principle of least privilege becomes useful.

Instead of asking:

"What tools can we expose?"

ask:

"What tools does this agent actually need?"

That small change in thinking can make the architecture safer and easier to manage.

Separate Read and Write Capabilities

A practical approach is to separate read operations from write operations.

A support agent that only answers customer questions may need the first three tools but not the remaining ones.

This does not mean write tools should never be exposed. It means they should be exposed deliberately, with appropriate permissions and safeguards.

The more sensitive the action, the more carefully its access should be designed.

Anti-Pattern 2: Building a Custom Server When an Existing One Already Covers Most of the Need

Another common form of MCP overengineering is building a custom server before checking whether an existing public, vendor-supported, or community server already covers most of the requirement.

Suppose a team wants an AI agent to interact with a common SaaS platform.

The development team could build a new MCP server from scratch. But before starting development, it is worth checking whether an existing server already provides the required integration.

An established public or community server may already cover approximately 90 percent of the team's use case.

When 90 Percent Is Already Enough

It may seem reasonable to build an entirely new server to get complete control.

But custom development also means taking responsibility for the infrastructure around that integration.

That can include:

• Authentication
• Authorization
• Error handling
• Logging
• Monitoring
• Documentation
• Security updates
• Deployment
• Compatibility testing
• Ongoing maintenance

The missing 10 percent may not justify rebuilding the other 90 percent.

This does not mean existing community or public servers are always the right answer.

A custom MCP server may make sense when an existing solution does not meet important security, compliance, performance, or business requirements.

The important question is:

What do we gain by owning this integration ourselves?

If the answer is simply a few additional convenience functions, the team should carefully consider whether the additional maintenance is worth it.

Evaluate Before You Build

Before starting a custom MCP server, ask:

• Is an official, public, or community server already available?
• Does it support the required authentication model?
• Does it meet our security requirements?
• Which required capabilities are missing?
• Can the missing functionality be handled separately?
• Who will maintain the custom server?
• What happens when the underlying API changes?

Anti-Pattern 3: Ignoring the Context Window Budget

MCP can give an AI agent access to many tools.

That does not mean the agent should receive every tool available in your organization.

Tool names, descriptions, parameters, schemas, and instructions all contribute to the information the model has to work with.

As the number of available tools grows, the agent has more information to process and more possible actions to consider.

When Too Many Tools Become a Problem

Imagine an agent with five clearly defined tools.

Now imagine another agent with 80 tools covering:

• Customer management
• Billing
• Inventory
• Project management
• Reporting
• Internal databases
• Cloud services
• Administrative functions

Some of those tools may have similar names or overlapping capabilities.

At some point, the agent has so many tools to consider that tool selection itself becomes part of the problem.

The issue is not simply the number of tools.

The issue is exposing tools that the agent does not need for the current workflow.

Plan the Toolset Around the Agent

A better approach is to think about what each agent is actually responsible for.

A customer support agent might need:

• Search Customer
• Get Order
• Check Delivery
• Create Support Ticket

An operations agent might need:

• Search Inventory
• Update Inventory
• Create Purchase Order
• View Supplier

A finance agent might need:

• Search Invoice
• Check Payment Status
• Generate Financial Report

These agents may use the same underlying business systems, but they do not necessarily need the same tool catalog.

This is why context window budget planning should happen before the MCP server grows.

If an agent repeatedly considers irrelevant tools, consumes excessive context, or struggles to select the appropriate operation, the toolset may need to be simplified.

More tools do not automatically create a more capable agent.

Sometimes they simply create a more complicated one.

Anti-Pattern 4: Skipping Authentication Propagation Testing Before Production

Authentication can become complicated when an MCP server sits between an AI application and other services.

A typical request may travel through several layers:

The user may successfully log in to the application.

That does not automatically mean the downstream API receives the correct identity and permissions.

For example, an MCP server might successfully authenticate the request but then use a shared service account when communicating with another system.

The request works technically, but the downstream system may no longer know which individual user initiated the action.

Imagine that User A can update an order while User B can only view it.

The MCP workflow should preserve those permissions.

If both users can trigger the same update tool because the MCP server uses one highly privileged service account, the application may have bypassed the original permission model.

This is why authentication propagation needs to be tested across the complete request path.

Test Real Permission Scenarios

Before production, test situations such as:

• A user with read-only access attempts a write operation
• A user with appropriate permissions performs the operation
• An expired token is rejected
• A revoked permission is respected
• Invalid credentials cannot access the MCP tool
• The downstream API receives the appropriate authorization context
• A failed authorization request does not fall back to a more privileged account

Testing only the initial login is not enough.

The question is not simply:

"Can the user authenticate?"

It is also:

"Does the correct identity and permission model remain intact all the way to the downstream system?"

For healthcare, financial, enterprise, or other sensitive applications, this becomes especially important because MCP tools may provide access to systems containing sensitive information.

A Practical Checklist for Avoiding MCP Anti-Patterns

Before deploying an MCP server, teams can use a simple review checklist.

This type of review can identify architectural problems before they become production problems.

When a Custom MCP Server Still Makes Sense

Avoiding MCP anti-patterns does not mean avoiding custom MCP servers.

There are situations where building a custom server is reasonable.

A custom MCP implementation may make sense when:

• Your organization has proprietary systems
• No existing server supports the required workflow
• Existing integrations do not meet important security or compliance requirements
• You need specialized business logic
• You need precise control over exposed tools
• The integration provides enough business value to justify ongoing maintenance

For example, a company may have an internal construction management platform containing proprietary workflows and no suitable existing MCP integration.

In that situation, a custom server may provide meaningful value because the underlying system itself is unique.

The key is to distinguish between customization that solves a real requirement and customization that simply adds another layer of infrastructure.

FAQs

Conclusion

Building an MCP server is not the end of the architecture decision.

Even when MCP is the right technology, the implementation can still become unnecessarily complex.

Tool overexposure can give an agent permissions it does not need. Building a custom server can duplicate functionality that already exists. A large tool catalog can increase context usage and make tool selection more complicated. And incomplete authentication testing can allow permission problems to reach production.

The solution is not to avoid MCP.

Instead, start with a focused implementation.

Expose only the capabilities the agent actually needs. Check public, official, and community solutions before building a custom server. Plan the toolset around the agent's workflow and context requirements. Then test authentication and authorization across the complete request path.

MCP can be a useful part of modern AI integration architecture, but good architecture still depends on restraint.

The goal is not to expose every possible capability.

The goal is to expose the right capabilities, to the right agent, with the right permissions.