Start with the job, not the protocol.
An API exposes an application’s capabilities to software. MCP provides a shared interface between AI applications and servers that expose tools, resources or prompts. A custom MCP server can call existing APIs behind the scenes; it does not remove the need to understand them.
For a buying decision, ask what should happen without anyone opening an AI assistant. If every paid order must reach finance, design that integration as an operational workflow. If an account manager wants an assistant to retrieve an order’s status, scope that lookup as an AI-access use case.
| Approach | A good fit | Work still required |
|---|---|---|
| API integration | Moving approved records between applications after an event or on a schedule. | Mapping, identity, retries, reconciliation and operational ownership. |
| iPaaS | Managing integrations using an existing platform and suitable connectors. | Connector fit, licensing, business rules, testing and support. |
| Custom MCP server | Giving an AI assistant bounded access to application tools and context. | Tool design, service authorization, input validation and evaluation. |
Example: Salesforce, SAP Business One and an assistant.
Consider a sales team that closes opportunities in Salesforce and fulfills orders through SAP Business One. A possible first scope is an approved opportunity-to-order integration. The team defines the required customer, item, currency and price references, and records the SAP document number against the originating opportunity.
The operating design must account for duplicate events, missing items and rejected orders. A person should be able to see why a transfer failed and decide what to correct. Reconciliation checks whether an expected order actually arrived; an HTTP success response alone is not the business outcome.
Separately, a read-only MCP tool could let an authorized user ask for an account’s open orders. It should return relevant records and identifiers, not an unrestricted database export. This is an illustrative architecture, not a claim that a prebuilt connector or every product edition supports the complete workflow.
A protocol is not a security policy.
Describe the identity at every boundary: the employee, the AI workspace, the MCP service and the destination application. Decide whether a tool uses the employee’s own permissions or a service identity with narrower business rules. Test with a user who should be denied access, not only with an administrator.
Enforce authorization in the service for each request. Tool descriptions and prompts help the assistant understand intended behavior, but they are not access controls. For a consequential action, define the approval step and the recovery procedure before exposing it.
- List permitted objects, fields and actions for each tool.
- Separate retrieval from changes to financial or customer records.
- Validate inputs and reject requests outside the approved scope.
- Exclude tokens and unnecessary personal information from logs.
- Test untrusted content, expired credentials and revoked permissions.
Reference: OpenAI guidance on MCP authorization and tool behavior
Ask where the information goes.
Hosting an MCP server in your cloud does not, on its own, mean that data never leaves that cloud. Draw the request and response path, including the chosen model service, connectors, logs and any indexing. Review the selected products’ retention, residency and commercial terms with your security team.
A useful design document distinguishes data stored in an application from data returned to an assistant for processing. Keep tool results as narrow as the workflow allows. A user who needs the amount and due date of one invoice usually does not need the full customer record.
What to include in the implementation brief.
A useful brief lets a delivery team identify dependencies before giving a price. Start with one business workflow and the people who own it. List existing integrations as well as the new connection: replacing an established sync may create more risk than adding a controlled access layer.
The estimate should distinguish platform subscriptions, usage charges, implementation, training and ongoing operations. Compare proposals by scope and acceptance tests rather than by an unqualified promise of “real-time” or “enterprise-ready.”
- Application names, editions, deployment model and available API access.
- Required records, source of truth, matching identifiers and direction of each flow.
- Expected daily volume, peak periods and acceptable delay.
- Sandbox availability, data restrictions and security review requirements.
- Failure handling, reconciliation, support ownership and change management.
- What documentation, source access and technical training must be handed over.
Choose the smallest useful first step.
For a broken order handoff, start with the system-to-system integration. For an assistant that lacks business context, begin with a read-only tool against one approved source. If both problems exist, keep their acceptance criteria separate so a successful demo is not mistaken for a reliable operations process.
AIONDATA can assess an existing connector, implement custom API workflows, or build an MCP service around your applications. The choice follows the required behavior, security boundaries and ownership model—not a requirement to use every technology in the same project.
Put the plan into practice.
Bring one workflow and the systems involved. We can help define the implementation, integration or training scope.