How to add MCP to an existing software stack: architecture, security, and rollout

Most companies considering MCP do not need another platform. They need a safe way for AI agents to use the platforms they already have.

The data is already in PostgreSQL. Customer activity already lives in the CRM. Operational rules are already encoded in APIs and backend services. Authentication, roles, audit logs, and approval flows already exist. Rebuilding those systems for agents would be expensive and risky. A Model Context Protocol layer can make the useful parts available through a standard agent interface while leaving the source of truth where it belongs.

That sounds simple: wrap an API, describe a few tools, and connect a client. A prototype can be that small. A production integration cannot. The real work is deciding what an agent should be allowed to see and do, translating business operations into stable tools, preserving authorization boundaries, and making failures observable.

This guide explains how we approach that work at Gorilli.

What MCP changes—and what it does not replace

MCP is an open protocol for connecting AI applications to external capabilities. An MCP server can expose three primary building blocks defined by the protocol:

• Tools let a model request actions, such as creating a support ticket, looking up an order, or scheduling a report.
• Resources provide context, such as a customer record, a knowledge-base document, or a schema description.
• Prompts offer reusable interaction templates for specific workflows.

The official MCP server documentation describes these primitives and how clients interact with them.

MCP does not replace your API gateway, database permissions, business services, or application interface. It is an adapter between an agent-capable host and controlled parts of your software. The strongest implementations treat the existing system as authoritative and the MCP server as a deliberately narrow interface.

That distinction matters. If the current API allows a user to refund an order only when several conditions are met, the MCP tool should call that same business operation. It should not reproduce a looser version of the rule inside the protocol layer.

A practical reference architecture

A production setup usually contains five logical layers:

1. Agent host. The product in which the model runs: a desktop assistant, coding agent, internal copilot, or custom application.
2. MCP client. The component that discovers server capabilities and exchanges protocol messages.
3. MCP server. The boundary that publishes tools and resources, validates inputs, and translates requests into application operations.
4. Identity and policy layer. Authentication, authorization, user context, consent, rate limits, and approval rules.
5. Existing systems. APIs, databases, SaaS platforms, queues, document stores, and internal services.

The flow is:

User intent → agent host → MCP client → authenticated MCP server → existing service → validated result

The MCP server should be thin enough that business rules stay in the application, but opinionated enough that an agent receives safe, useful operations instead of unrestricted backend access.

Start with jobs, not endpoints

A common mistake is converting every REST endpoint into an MCP tool. That produces a large, confusing surface and pushes orchestration work onto the model.

Start by listing the jobs an agent should complete:

• Retrieve the status of a customer order.
• Prepare a support-case summary for an operator.
• Create a draft CRM follow-up after approval.
• Compare usage against a plan limit.
• Find deployment errors associated with a release.

Then design one coherent tool for each job. A tool named getcustomercontext can safely combine account, recent activity, and support status behind one schema. That is usually more reliable than asking the model to call four low-level endpoints in the correct order and join their results.

A good MCP tool has:

• A name that expresses the business action.
• A precise description of when it should and should not be used.
• A small, typed input schema.
• Predictable structured output.
• Explicit error states the agent can act on.
• A permission requirement tied to the current identity.
• An idempotency strategy for write operations.

The goal is not to expose everything. It is to expose the smallest set of capabilities that lets an agent complete valuable work reliably.

Decide whether to wrap an API or add an application service

Not every existing system is ready to sit behind MCP. We normally encounter three cases.

The existing API already represents business operations

This is the easiest case. The MCP server can call stable application services, pass authenticated user context, and translate the response into an agent-friendly structure. The protocol layer remains small.

The API is too low-level

CRUD endpoints often expose database mechanics rather than useful jobs. Instead of teaching the agent to coordinate them, add an application service that performs the operation deterministically. Both the product UI and MCP server can call that service.

There is no API

Direct database access may be acceptable for narrow, read-only resources, but write access should usually go through a service that owns validation and business rules. For third-party SaaS systems, create a dedicated connector with retries, pagination, rate-limit handling, and normalized errors before publishing MCP tools on top.

This is why MCP implementation is often full-stack integration work. The protocol endpoint may be the visible result, while the important engineering happens in the systems behind it.

Authentication is only the first security boundary

Knowing who connected is necessary, but it is not enough. The server must also decide which capabilities that identity can discover and invoke, which records it can access, and which actions require additional confirmation.

We separate the controls into layers:

• Authentication: establish the user, service, or organization behind the session.
• Authorization: check permissions for every tool and resource request, preferably by calling the same policy layer used by the application.
• Tenant isolation: bind organization context on the server; never trust a tenant identifier supplied only by the model.
• Input validation: validate every argument independently of the tool schema presented to the client.
• Output filtering: remove secrets, internal fields, and personal data the caller does not need.
• Action controls: require confirmation or human approval for destructive, financial, external-communication, or high-impact operations.
• Rate and cost limits: prevent loops, runaway tool use, and accidental load on downstream systems.
• Auditability: record who requested an action, which tool ran, the validated inputs, the result category, and the correlation ID—without logging sensitive payloads indiscriminately.

Prompt injection does not disappear because the tool is typed. Treat model-generated arguments as untrusted input and design each operation so a compromised instruction cannot expand its authority.

Read and write tools need different rollout strategies

Read-only tools are a good first release because they reveal how agents choose tools and interpret results without changing business state. Start with a limited audience and watch real traces.

For write operations, introduce risk progressively:

1. Return a proposed action without executing it.
2. Let a user review and approve the proposal.
3. Execute only reversible or idempotent actions.
4. Add narrow autonomous execution where the risk and expected value justify it.

For example, an agent might first draft a CRM note, then save it after approval. Only after the team trusts the workflow should it create low-risk notes automatically. Sending customer email, moving money, deleting data, or changing permissions should retain stronger controls.

Test the contract and the agent behavior

Traditional integration tests remain essential: schema validation, authentication, authorization, downstream failures, timeouts, pagination, concurrency, and retries. MCP adds another layer: how models discover and use the interface.

Build an evaluation set containing realistic user requests and expected outcomes. Measure at least:

• Whether the agent selects the correct tool.
• Whether it provides valid arguments.
• Whether it avoids a tool when the request is outside scope.
• Whether it handles a recoverable error correctly.
• Whether the final answer reflects the tool result without inventing facts.
• How many tool calls and how much latency the workflow requires.

Include adversarial cases: ambiguous identities, cross-tenant requests, instructions hidden in retrieved content, oversized results, duplicated write attempts, expired credentials, and partial downstream failure.

The test target is not only “the server returned 200.” It is “the user’s job was completed safely and the system behaved predictably when it could not complete it.”

Observability must connect both sides of the boundary

Production debugging becomes difficult when agent traces and application logs live in separate worlds. Use a correlation ID that follows the request from the host through the MCP server and into downstream services.

Useful operational signals include:

• Tool discovery and invocation rates.
• Success, validation-error, permission-denied, and downstream-error rates.
• Latency by tool and dependency.
• Result size and truncation.
• Repeated or looping calls.
• Approval acceptance and rejection rates.
• Cost per completed workflow where model usage is measurable.

Do not store every prompt and response by default. Define retention, redaction, and access rules based on the sensitivity of the workflow and applicable privacy obligations.

A rollout that does not require rebuilding the stack

A sensible delivery sequence is usually:

1. Discovery and capability map

Choose one or two valuable agent jobs. Identify data sources, business operations, identities, permission rules, and failure consequences. Decide what remains outside the first release.

2. Contract design

Define tool and resource schemas before implementation. Review them with both domain experts and engineers. The interface should describe the business, not mirror accidental details of the backend.

3. Vertical slice

Connect one real client to one real workflow using production-like identity and data. Add traces and evaluation cases immediately so decisions are based on evidence rather than demo quality.

4. Controlled pilot

Release to a small internal group. Keep writes behind approval, observe tool behavior, and improve descriptions, schemas, errors, and result shape.

5. Production hardening

Complete threat modelling, load and failure testing, alerts, runbooks, credential rotation, privacy review, and ownership handover. Expand the capability surface only after the first tools are stable.

Common MCP implementation mistakes

• Publishing the whole API. More tools make selection harder and increase the security surface.
• Duplicating business rules. Rules drift when they live separately in the application and MCP server.
• Trusting model-supplied identity. User and tenant context must come from verified session state.
• Returning UI-shaped payloads. Agent responses should be concise, structured, and stable rather than copies of frontend view models.
• Giving write tools too much authority. Approval and reversibility should match the consequence of the action.
• Skipping evaluation. A valid protocol response does not prove that agents use the interface correctly.
• Ignoring ownership. Every server needs a team responsible for schemas, downstream changes, credentials, monitoring, and incident response.

What we learned from building Storm

Gorilli built Storm, a decentralized marketplace for MCP tools developed during the AI Blueprints hackathon with Filecoin Recall, where it won second place.

The marketplace framing made one lesson especially clear: an MCP capability is a product contract, not just a function signature. A developer has to understand what the tool does, an agent has to select it correctly, and an operator has to trust its behavior. Clear descriptions, bounded permissions, predictable results, and observable usage determine whether a tool is genuinely reusable.

That experience is one reason our MCP development and integration service focuses on the surrounding architecture as much as the server implementation itself.

MCP integration readiness checklist

Before implementation, confirm that you can answer these questions:

• Which user job should the agent complete?
• Which existing service owns the underlying business operation?
• How is user and tenant identity established?
• Which permissions apply to each tool and resource?
• Which actions need confirmation or approval?
• What is the maximum acceptable consequence of a wrong call?
• Are writes idempotent or reversible?
• Which data must be filtered or redacted?
• What should the agent do when a dependency is unavailable?
• Which evaluation cases prove the workflow is useful and safe?
• How will traces connect to downstream application logs?
• Who owns the server after launch?

If several answers are unclear, that is not a reason to abandon MCP. It means the first phase should be architecture and policy design rather than coding.

Frequently asked questions

Do we need to replace our existing APIs to use MCP?

No. A well-designed MCP server normally sits in front of existing APIs and application services. You may need to add a higher-level service when the current API is too low-level, but a rewrite is rarely the starting point.

Should an MCP server connect directly to a database?

Read-only access can be appropriate for narrow, controlled resources. Writes should generally pass through application services that enforce business rules, permissions, validation, and audit behavior.

Can one MCP server support multiple clients?

Yes, when the clients implement the protocol features the server uses. Test against the clients relevant to your workflow because product behavior, authentication support, and user experience can differ.

Is MCP secure by default?

MCP defines how clients and servers exchange capabilities; it does not remove the need for application security. Authentication, authorization, tenant isolation, approvals, validation, rate limits, privacy, and monitoring remain implementation responsibilities.

How should we choose the first MCP tool?

Choose a frequent, valuable workflow with clear permissions and limited consequences when something goes wrong. A read-heavy internal task is usually a better first tool than an irreversible external action.

If you want to make an existing product or internal system available to agents, tell us what you want to connect. We can help map the capability surface, build the MCP layer, and take the integration through production.