Mindfront Fiber vs MCP

Open in ChatGPT ↗ Explain this page with GPT Open in Claude ↗ Explain this page with Claude Open in Perplexity ↗ Search and explain this page
3 min read

If someone already publishes a connector for your system, use it. Fiber is for the systems nobody publishes for.

That is the whole decision, and Mindfront speaks both. This page is for when you want the reasoning.

Not sure which applies to you? The guided setup works it out from the system’s name.

The rule

Your systemUseEffort
On the built-in listNothing: sign inTwo minutes
Commercial software with a published MCP serverMCPFive minutes
Built in-house, on-prem, or abandoned by its vendorFiberAn afternoon

Most orgs are mostly in the first two rows. The third row is where Fiber matters, and it matters a lot, it’s the row where every other AI platform tells you to file a feature request.

Why MCP wins where it applies

An MCP server is a connector the vendor writes, hosts and maintains. Paste a URL and Mindfront reads the entire tool catalogue from it. You write nothing, and you inherit the vendor’s maintenance instead of owning it.

Writing a Fiber bridge for a system that already has an MCP server is work you’re doing for no reason.

The catch is trust: an MCP server describes tools your AI will read and act on, and a poisoned description is a real, documented attack. So provenance is not optional:

  • The official registry authenticates who published a server through reverse-DNS namespace ownership. Only the proven owner of stripe.com can publish com.stripe/*. It explicitly does not review security, it delegates that downstream.
  • Docker’s MCP registry does review it: every entry pinned to a git commit in CI, signed with Cosign against a public transparency log, and put through behavioural code review.

The guided setup prefers Docker-vetted servers, shows registry-only ones as unvetted, and says which is which. We publish other people’s verdicts rather than inventing our own.

Why Fiber exists

No vendor publishes an MCP server for a fifteen-year-old in-house ERP, and no vendor ever will. That system runs the business anyway.

Fiber is deliberately small so this case stays a one-afternoon job:

  • Two endpoints. GET /meta returns what your service can do; POST /action/<name> does one of those things. Both JSON, both plain HTTP.
  • No SDK, nothing installed. Your code, your language, your servers. Mindfront never sees inside it.
  • Stateless. No connection lifecycle, no handshake, no session to manage. Return HTTP 200 and put logical errors in the body.
  • Risk levels are enforced by the host. An action marked humanApprovalRequired cannot execute without a person signing off, checked before the request reaches your service, not left to your implementation.

That last point is the one real architectural difference worth naming. MCP’s destructiveHint is a non-binding annotation; the client decides what to do with it. Fiber’s riskLevel is a contract Mindfront enforces. For an in-house system with no vendor standing behind it, that guarantee is worth having.

Both, usually

These are not competing choices and you will probably run both. A typical deployment has MCP servers for the bought software and one or two Fiber bridges over the systems the org built itself. They appear identically in Mindfront once connected: modules with actions, same permissions, same audit trail.

Next