What is Model Context Protocol (MCP)?

Model Context Protocol (MCP) is an open standard created by Anthropic that provides a universal way for AI models to connect to external tools and data sources. Think of it as USB-C for AI — one protocol that lets any AI model talk to any tool, whether it is Jira, Slack, a database, or your own internal API.

How can a CTO use MCP to integrate AI into their engineering workflow?

A CTO can use MCP connectors to wire AI assistants directly into the tools the team already uses — Jira for ticket management, Slack for communication, Google Drive for documents, and Git for code. Instead of building custom API integrations for each AI tool, MCP provides a standard interface that works across AI models and tools.

What is the difference between MCP and building custom AI tool integrations?

Custom integrations require writing and maintaining bespoke API code for every tool-model combination. MCP standardizes this: you write one MCP server for your tool, and any MCP-compatible AI client can use it. This reduces integration effort from N x M (tools times models) to N + M, and the integrations stay consistent across different AI providers.

Can MCP work with NestJS and Flutter projects?

Yes. MCP servers can be built in any language, including TypeScript with NestJS. For Flutter projects, MCP helps AI assistants understand your Dart codebase, access project documentation, and interact with your build and deployment pipeline. The protocol is language-agnostic — it works over JSON-RPC, so any stack can implement an MCP server.

← All posts

How MCP Is Changing the Way We Connect AI to Real Tools — A CTO's Hands-On Experience

May 14, 2026Faisal KCAI · Developer Tools

Six months ago, if you wanted an AI assistant to create a Jira ticket, you had two options: copy-paste between windows, or write a custom integration that would break the next time the API changed. Today, I open Claude, say “create a bug ticket for the payment timeout in the NPZ app,” and it creates the ticket in the right Jira project with the right fields — because it's connected through MCP.

Model Context Protocol has quietly become one of the most practically useful things to happen to AI tooling this year. Not because of what it is — a JSON-RPC-based protocol for connecting AI models to external tools — but because of what it lets teams like mine stop doing: building and maintaining brittle glue code between every AI tool and every service we use.

The Integration Tax We Were Paying

At MVP Apps, we run a multi-stack operation. Our projects span Flutter for mobile, React and Next.js for web, NestJS and Laravel for backends, and we deploy across AWS, Nginx, and cPanel depending on the client. We use Jira for project management, Slack for communication, Google Drive for documents, and GitHub for code.

When AI coding assistants started getting good enough to actually use in production workflows, we hit a wall immediately: every tool was its own island. The AI could write code, but it couldn't see the Jira ticket that described what needed to be built. It could draft a message, but it couldn't check Slack to see what the team had already discussed. Every integration was a custom project — an API key here, a webhook there, a middleware service that someone had to maintain.

For a team our size, that integration tax adds up fast. We were spending engineering hours maintaining the connections instead of building the products our clients needed — AWQAF UAE, National Payment of Zakat, Emirates Red Crescent. These are government-scale projects with real deadlines. We don't have slack in the schedule for plumbing.

What MCP Actually Changed

MCP flipped the integration model. Instead of building a custom bridge for every tool-model pair, you write one MCP server per tool (or use an existing one), and any MCP-compatible AI client can talk to it. The analogy I keep coming back to is USB-C — one connector, many devices. Before USB-C, every phone had its own charger. Before MCP, every AI tool had its own integration story.

Here's what our setup looks like now: Jira is connected through an Atlassian MCP connector. Slack has its own. Google Drive has one. Our GitHub repos are accessible. When I'm working inside Claude, I can search Jira tickets, read Slack threads, pull up Google Drive documents, and navigate our codebase — all from the same interface, all through the same protocol.

The shift isn't just convenience. It's about context. The reason AI assistants give generic answers is usually because they don't have access to the specific context of your project. MCP gives them that context. When the AI can read the actual Jira ticket, see the actual Slack discussion, and look at the actual code — its suggestions go from “here's a general approach” to “here's what you should do given what the team discussed yesterday and what the ticket says.”

A Real Example from Our Workflow

Last week, we had a deployment issue on one of our NestJS services — a payment gateway timeout that was affecting the National Payment of Zakat platform. Normally, debugging this would mean: check the Jira ticket for context, read the Slack thread where the QA engineer reported it, pull up the relevant service code, check the AWS CloudWatch logs, and piece together what happened.

With MCP connectors in place, I pulled up the Jira ticket directly, read the Slack thread where our QA lead had posted the error logs, and looked at the relevant NestJS controller code — all in one conversation. The AI had enough context to suggest that the timeout was likely a connection pool exhaustion issue, based on the error pattern in the logs and the recent traffic spike the team had flagged in Slack.

That's the difference MCP makes. Not magic — just the right context in the right place at the right time.

Building Our Own MCP Server

The off-the-shelf connectors cover the major tools, but every team has internal tools and APIs that are specific to their operation. We're currently building an MCP server for our internal deployment pipeline — a system that manages how we push Flutter apps through staging and into the App Store and Play Store.

The protocol itself is surprisingly straightforward if you're comfortable with TypeScript. An MCP server exposes tools (functions the AI can call), resources (data the AI can read), and prompts (reusable templates). You define them using a schema, handle the JSON-RPC messages, and the AI client does the rest.

For our deployment server, the tools include things like check_build_status, list_recent_deployments, and get_release_notes. The resources include our deployment configuration files and environment variables (read-only, obviously). The whole thing runs as a Node.js process alongside our existing NestJS services.

Rashid, one of our senior backend developers, led the implementation. He had it running in three days — and that includes the time spent reading the MCP specification and writing tests. For comparison, our last custom AI integration (a Slack bot that could query our internal APIs) took two weeks and still breaks occasionally when the API changes.

What I'd Tell Other CTOs

Start with the connectors you already have. Don't build custom MCP servers on day one. Connect your Jira, Slack, and Drive first. See how your team uses them. The pattern of usage will tell you which internal tools to build servers for next.

The value is in the compound context. One connected tool is nice. Five connected tools is transformative. When the AI can cross-reference a Jira ticket with a Slack thread and a code change, it starts making connections that would take a human ten minutes of tab-switching to piece together.

Security matters more than you think. MCP connectors have access to your tools. That means access controls, token management, and audit logging are essential. We run our MCP servers with the minimum permissions needed and rotate tokens on a schedule. This isn't optional — especially for government projects where data sensitivity is non-negotiable.

The protocol is still young. There are rough edges. Some connectors don't handle pagination well. Error messages can be cryptic. The ecosystem is growing fast, but it's not mature yet. Go in with realistic expectations and you'll be fine.

The Bigger Picture

I've been in this industry since 2017. I've seen hype cycles come and go. MCP doesn't feel like hype — it feels like infrastructure. The same way REST APIs standardized how services talk to each other, MCP is standardizing how AI talks to tools. That's not exciting in a headlines kind of way, but it's the kind of boring-but-essential change that actually moves the industry forward.

At MVP Apps, we're betting on it. Not as a replacement for our engineering team — as a multiplier. The same team that builds AWQAF UAE and the National Payment of Zakat and Emirates Red Crescent can now move faster because the AI assistants they use every day actually understand the context of what they're building.

That's not a future prediction. That's what's happening right now, in our office, on our projects. And if you're a CTO wondering whether MCP is worth the time to set up — it is. Start small. Connect one tool. Watch what happens.