You Already Have the Tools for Building AI Agents: Why MCP Is an Option, Not a Prerequisite

Every vendor in the AI ecosystem right now is racing to ship a Model Context Protocol (MCP) server. Which means every team building an agentic strategy is getting the same message from every direction: stand up MCP, or you are behind. Our customers keep asking us a different question. If this vendor’s MCP server is just a wrapper around an API I already have, why would I stand up and govern a whole new system to get the same result?

That question is the right instinct, not a knowledge gap. It deserves a real answer.

Every Integration You’ve Already Built Is Already an Agent Tool

Getting started with agentic AI for infrastructure does not require new infrastructure. If you have already invested in adapters, integrations, controllers, secrets management, and SSO, that work does not get thrown away the moment AI enters the picture. It becomes exactly what an agent needs: a scoped, governed tool it can call.

In practice, that means opening an agent builder and seeing your existing adapters, integrations, compliance plans, and gateway services already listed as tool types you can associate directly, before you have touched a single MCP server.

Not All MCP Servers Are Created Equal

The same rule that has always applied to APIs applies to MCP servers: some vendors have done real work curating a toolset that goes well beyond a single endpoint, and some have shipped a thin, one-to-one translation of their existing API, wrapped in MCP’s format. A curated MCP server is worth using. A wrapper that mirrors an API you can already call directly is not worth standing up and governing separately just to say you have one.

That is why waiting is a legitimate strategy, not a delay. Teams already automating today can keep using the APIs and integrations they trust, and add a vendor’s MCP server later, once that vendor has actually built something worth adding.

Federate the Good Ones, Skip Waiting on the Rest

When a vendor does ship a genuinely useful MCP server, the FlowMCP Gateway extends the Itential Platform‘s governance, authentication, and policy enforcement to it, the same way it already does for existing integrations. NetBox, pyATS, Selector, Forward Networks, or any other MCP-compatible service become scoped, callable tools for your agents, alongside everything you were already using. No rip-and-replace. No custom glue code holding production together.

That is the actual choice teams get: not MCP versus existing integrations, but MCP added to existing integrations, under the same governance either way.

FlowMCP Gateway vs. the Itential MCP Server

It is worth being precise about which piece does which job here, since the names are easy to conflate. FlowMCP Gateway is how Itential’s own FlowAgents reach out and call external MCP servers (NetBox, pyATS, Selector, and the rest) as tools.

The Itential MCP Server runs the opposite direction: it exposes the Itential Platform itself as a set of governed MCP tools that any external LLM or AI client (Claude, ChatGPT, Gemini, or a model built in-house) can call. One lets your agents reach out to other tools. The other lets any AI client reach into Itential.

How The Two Compare

Both run through the same RBAC, schema validation, and audit trail, so it does not matter which direction the request came from or which model made it.

Is MCP a Security Question?

MCP itself is a well-designed protocol, and it deserves credit for that. It gives a server clear boundaries: a server only sees what it needs to do its job, never the full conversation and never what other servers are doing. Since Anthropic released the standard in late 2024, more than 16,000 MCP servers have shown up, and it has been adopted by Microsoft, Google, OpenAI, GitHub, and AWS. This is not an experimental protocol. It is a maturing one.

But MCP governs how an agent talks to a tool. It does not govern what happens after that tool call reaches your infrastructure. That is a separate question, and it is the one that actually determines whether an AI-initiated change is safe: is every action, MCP-triggered or not, running through the same RBAC, approval gates, and audit trail as a change a human made?

If a platform’s only way to connect AI to infrastructure is whatever MCP server a vendor happens to ship, that question does not have an answer yet. The platform has no governance layer of its own to fall back on. It is inheriting whatever the MCP server does, or does not, enforce.

This is where having a decade of deterministic execution underneath matters.