How SoLo Engineering Approached MCP Without Duplicating Business Logic

🔌How we designed an agent-facing interface (MCP) while keeping authorization, data access and product behavior in their existing source of truth

    By SoLo Engineering · September 2026 · 8 min read

At a glance: MCP gives an AI application a governed path into existing product workflows. The diagram is conceptual and does not represent internal topology.

The architectural problem

Adding MCP support can look like a small integration project. The difficult part is deciding where the new interface should connect.

Attach it too high and the agent inherits API-specific behavior that was designed for a different kind of client. Attach it too low and the team starts rebuilding product rules around the database. Put it in a separate service and that service can slowly become another version of the application.

At SoLo Funds, we build financial technology where authorization and predictable behavior matter. An agent cannot get a separate, looser set of rules just because the interface is conversational.

The Model Context Protocol gives AI applications a standard way to discover and call tools. Getting the protocol connection working is not the difficult part. The real work is finding a boundary that makes the model useful without creating another place to maintain authorization, data access and business logic.

💡How we designed an agent-facing interface while keeping authorization, data access and product behavior in their existing source of truth

That left us with one practical question:

• How could we make existing product capabilities available to agents without building a second version of our system?

Why agents need a different interface

A normal application follows a workflow that engineers define ahead of time. The client knows which endpoint to call, what to send and what comes next. We build that sequence, test it and ship it.

An agent starts with a goal.

Imagine someone telling an assistant:

• “I need $150 until Friday. Show me the lowest-cost option and ask before accepting it.”

The model understands the request. It does not automatically know which systems exist, which actions are allowed or what a result actually means. It needs a clear set of capabilities to choose from.

• With an API, engineers usually assemble the workflow at build time. With MCP, engineers define the available capabilities and the agent can assemble an allowed workflow at run time.

We were not designing another predictable client. We were designing for a caller that might choose tools in an order we had not explicitly programmed. That required a smaller, clearer interface than the APIs underneath it.

Four implementation paths we considered

The quickest options were tempting. We could put a generic bridge in front of the API or generate tools from an existing specification. Either approach can produce a fast prototype. The problem is that the API ends up deciding what the tools look like.

We compared four common approaches:

We landed on the application-layer adapter. It meant doing more thinking for each tool, but that was useful work. We had to decide which capabilities mattered, what each response meant and where the safety checks belonged.

⚖️How we designed an agent-facing interface while keeping authorization, data access and product behavior in their existing source of truth

The fastest implementation was not the one we wanted to maintain. We kept coming back to one rule:

• Put tools as close as possible to the application logic the product already uses. Do not place them any closer to the datastore than the product itself.

Why we chose the application layer

We treated MCP as another way into the application, alongside the interfaces our product already used. Both paths end up in the same application workflows, authorization checks and business rules.

Figure 1: MCP adds another interface to existing application behavior. It does not introduce another implementation of authorization, business rules or data ownership.

The split is straightforward:

• Shared protocol infrastructure handles transport, authentication hooks, schema validation and logs, metrics and traces.
• Product teams decide what each tool means, which fields it returns and what needs to be redacted.
• Existing application workflows continue to own orchestration and business behavior.
• Existing systems continue to own data and state.

The interface itself can stay thin. Choosing the right tools is where the judgment comes in.

• A tool can call an API. That does not mean every API operation should become a tool.

What we refused to duplicate

Some of our most important decisions were about what to leave out.

• No duplicate authorization model. Agent tools use the same authorization and policy boundaries as the rest of the application.
• No direct database access. Direct access would bypass product rules and move responsibility into the wrong layer.
• No second implementation of business rules. Two copies of the same rule will eventually disagree.
• No automatic serialization of internal objects. We map responses explicitly so a new internal field cannot become external by accident.
• No tool for every endpoint. Internal APIs are designed for known clients. That shape is not always helpful to a model.

These constraints keep the MCP layer small. More importantly, they prevent it from turning into a second application that we would have to maintain alongside the first.

Designing tools around product intent

Consider a generic marketplace where someone can create a request, inspect responses and choose an option. Instead of copying every underlying operation, an agent might see four tools:

• create_request
• get_request_status
• accept_option
• decline_option

The names are simple. Getting the contracts right takes more care.

• Name the user’s intent. “Accept this option” is clearer than “update record.”
• Say what happened. not_found, never_occurred, temporarily_unavailable and accepted_not_completed are different outcomes. The response should keep them separate.
• Keep results bounded. Use filters, stable ordering and server-side limits. If a response is incomplete, say so.
• Let the agent check its work. After a write, provide an authorized way to see whether the action is pending, complete or failed.
• Write descriptions like contracts. Explain when to use the tool, when not to use it and what a successful response actually proves.

We review descriptions, schemas and field mappings together. Tool metadata such as read-only, destructive and idempotent hints can help clients understand risk, but they do not replace authorization.

Writes still use the same safeguards

Read and write tools have different consequences. A bad read wastes time. A bad write changes something real.

We still want the user to approve sensitive actions. That approval is part of the experience, not the security boundary. The server has to check the caller, permissions, target and current state again when the tool runs.

Figure 2: User approval happens in the conversation. Authorization and state checks still happen on the server.

For writes, we use the same controls we would expect on any sensitive production interface:

• Least-privilege permissions
• Separate validation of the caller and target
• Protection against running the same action twice
• Rate limits, timeouts and strict execution limits
• Redacted logs and durable audit records
• Clear differences between accepted, completed and failed
• Tests for ambiguous, partial and malicious inputs

When identity, permission, approval or state is unclear, the safer answer is not to proceed.

What this boundary lets us reuse

We judge the architecture partly by what it allows us not to duplicate.

• Existing product workflows. Product interfaces and agent tools can use the same underlying behavior.
• Existing authorization policies. The tool layer does not invent a separate permission model.
• Existing validation rules. Inputs pass through the same product checks as other interfaces.
• Existing operational practices. Teams can apply familiar logging, monitoring and testing standards.
• Existing ownership. Product teams continue to own what each capability means.

The leverage does not come from building another platform. It comes from finding the narrowest useful boundary in the platform we already trust.

What we would recommend to other teams

1. Start with the user’s intent. Decide what the agent should accomplish before deciding how to expose it.
2. Reuse the rules you already trust. Keep MCP above the layer that owns authorization and business behavior.
3. Be explicit about uncertainty. Empty, partial, unavailable and still processing are not the same result.
4. Keep enforcement on the server. Confirmation helps the user understand an action. Authorization protects the system.
5. Treat descriptions as part of the product. Review and test them with the same care as schemas.

Our goal was not to build a separate application for agents. It was to give agents a carefully designed way into the application we already trusted. MCP supplied the protocol. The engineering work was finding the boundary that let us add a new interface without adding a second copy of the product.

• The best MCP architecture is not the one that exposes the most tools. It gives agents enough capability to be useful while granting no more authority than the product already allows.