TL;DR (for CxO)
- Our AI apps need 'tool' branches to act on real data/systems.
- MCP Server = tool shelf exposed by a third party via a standard protocol → speed & prototypes.
- Limitations: what the tool can do is limited by its API description, plus risks (security, external SLAs).
- MFO Connector Provider = native connector that we control from end to end → latency, traceability, security.
- We choose MCP to prototype quickly with external capabilities; MFO for sensitive core business in production.
Context (basic principles)
A tool is a concrete capability ("enrich a customer", "generate a summary", "verify an identity").
A protocol is a set of simple rules that allow two systems to understand each other.
An MCP Server is therefore a shelf of tools provided by a third party, which our AI assistants can call upon.
An MFO Connector Provider is an in-house connector: we take an internal source (database, API, model) and expose it as a tool, using our standards. MFO architecture makes it easy to expand the functionality required for OA apps.
Where it comes from
Initially, MCP servers ran locally on a developer's laptop for rapid prototyping: perfect for testing ideas. Today, we want these same capabilities at the enterprise level: stability, security, observability and controlled costs.
What it enables
- Customer service: the assistant cross-references a ticket with the CRM and suggests a prioritised response.
- Finance: extraction of data from an ERP to generate a closing summary.
- Compliance: KYC check by calling a certified external service.
Limitations and risks to be aware of
- Scope: a tool only does what is described in its API; if it is not documented, the assistant cannot guess.
- Protocols & interoperability: versions, schemas and network latency ultimately matter at scale.
- Security: risks of prompt injection (causing an unintended action to be executed), data exfiltration, secret management.
- Governance: with an external MCP server, SLAs and patches depend on the provider.
Why MFO Connector Providers?
When data is critical, latency must be very low, or traceability is imperative, we internalise the connector: same language as the rest of the platform, unified observability, code reviews, access controls, and the ability to add exactly what the business needs — without being limited by a third-party API.
The table below compares MCP Server (standardised, fast, external) and MFO Connector Provider (native, governed, high-performance) to help you make an informed choice based on your priorities.
MCP Server vs. MFO Connector Provider – Executive view
| Axis | MCP Server | MFO Connector Provider |
|---|---|---|
| Role | Exposes a catalogue of tools (AI functions, data, business services) via the Model Context Protocol. | Adapts an internal source or engine (database, API, LLM, etc.) so that it becomes a tool that can be used directly by the MindFlight orchestrator. |
| Organisational boundary | Generally external: third party, independent BU or product team that chooses its stack and release cycle. | Internal: developed and maintained by our platform team according to our standards. |
| Language/stack | Agnostic; implementation can be Node, Python, Rust, etc., as long as it speaks MCP (JSON-RPC). | 100% Go, aligned with the rest of MFO → same runtime, same observability library, same performance patterns. |
| Governance & Security | We negotiate an interface contract: MCP version, auth (token), quotas. Audits and patches depend on the provider. | Total control: internal code review, CI/CD-integrated SAST/DAST scans, secrets managed by our vault, container hardening. |
| Scalability & SLA | Scalability managed by the MCP server host; we are subject to their SLO. | Sizing controlled by our team: Kubernetes autoscaling, memory/CPU budgets, Prometheus instrumentation. |
| Tool lifecycle | Publish a new tool = deployment on the MCP server, then rescan by MFO. | Add a tool = merge a Go provider + build pipeline → unified deployment with MFO. |
| Coupling with MFO | Low: standard network communication. Replaceable or multipliable without redeploying MFO. | Tight: compile-time, package sharing, maximum benefit in terms of performance/latency. |
| When to choose? | - Function already available from a partner - Need to isolate a regulated domain - Fast time-to-market without touching our code - Quick Prototyping in dev to validate scopes |
- Critical or sensitive data - Very low latency requirement - Need to trace all code in our value chain |
In summary:
- MCP Server = standardised external black box, ideal for quickly connecting third-party or experimental capabilities.
- MFO Connector Provider = native Go extension, fully integrated and governed; the preferred choice when you want performance, security and scalability under your control.
