A year ago, connecting your company’s internal systems to an AI assistant was a science project. Today it’s a Jira ticket — the Model Context Protocol turned “wire the AI to our order database” from custom integration work into something a mid-level engineer can prototype in a week. If you need the protocol itself explained, the MCP explainer covers that ground.
This post is the other conversation — the one I have with CTOs and platform leads after the prototype demo goes well. Because the demo is the easy part, and the questions that follow (“so can we roll this out?”) are architecture, security, and economics questions wearing an AI costume.
What does MCP actually change for a team?
MCP standardizes the plumbing of AI-to-system integration, which moves the hard work from “how do we connect it” to “what should it be allowed to do.” One server exposing your issue tracker works in every MCP-capable client your team uses — same integration, written once. That’s real leverage: before the standard, every AI surface needed every integration rebuilt.
What it doesn’t change: your internal API’s actual contract, auth model, and data sensitivity all pass straight through the new pipe. An MCP server is a presentation layer over your systems for a very literal-minded consumer — if the underlying API lets a caller read every customer’s orders, the MCP server now offers that capability to every conversation with the AI. The protocol standardized the connection, not the judgment.
Where does the security boundary belong?
In the MCP server itself — never delegated to the model’s good behavior. The rule I hold teams to: the server enforces exactly what the user behind the session may do, using your existing auth (scoped tokens, row-level permissions), so that even a fully confused model cannot request data the human couldn’t already access. “The model usually doesn’t ask for other customers’ data” is not a security posture; “the token can’t read other customers’ data” is.
Three specific decisions deserve design time before rollout. Read/write split: read-only tools are a different risk class than tools that mutate state — start read-only, add writes tool-by-tool with explicit approval flows. Prompt-injection reality: any tool output containing user-generated content (ticket text, emails, reviews) can carry instructions the model may follow, so treat tool outputs as untrusted input, exactly like the classic web-security posture. And logging: every tool call, with arguments, attributed to the human session — because “what did the AI touch last Tuesday” will eventually be asked by someone with a compliance title, and the answer must not be a shrug.
What does an MCP rollout actually cost?
The server is the cheap line item; the contract work around it is the real budget. Building a first read-only server over a well-documented internal API is genuinely days, not months — the mechanics are learnable in course form (building MCP servers exists for exactly that). The costs that surprise teams: tool-schema design (descriptions precise enough that the model picks the right tool for the right job — bad descriptions produce an AI that’s confidently wrong about your own systems), evaluation (a test suite proving the tools get used correctly across realistic conversations, not just that they return 200), and ongoing ownership, because every schema change upstream now has a second consumer to break.
Cost of the runtime itself follows agent economics: every tool result lands in the model’s context window and gets paid for, so a server that returns 200 rows when 5 would do quietly multiplies your token bill. Result shaping — filtering, summarizing, paginating inside the server — is both a quality and a cost decision, and it’s where production LLM-app discipline pays for itself.
Should you build it in-house or bring someone in?
Build in-house when the integration is read-only, the underlying API is well-owned, and you have at least one engineer who has shipped an LLM feature to production — the profile that knows why tool descriptions are load-bearing and what an eval suite is for. The learning compounds: the first server teaches the team patterns every later server reuses, and that knowledge is worth owning rather than renting.
Case by case, the line falls roughly here:
| The situation | Build in-house | Bring in review first |
|---|---|---|
| Read-only server over a well-owned internal API | Yes — days of work, and the team keeps the pattern | Not needed |
| Your first write-capable tool | Risky alone | Yes — pressure-test boundaries before they’re production facts |
| Regulated, customer or financial data | No | Yes — auth model and injection posture reviewed before launch |
| Tool-schema design across a large surface | Doable; expect iteration | Helpful — vague descriptions make the AI confidently wrong about your systems |
| Eval suite for correct tool use | Yes, and own it long-term | Optional |
Bring in outside review when writes are involved, when the data is regulated, or when the integration touches systems whose failure is expensive — not to outsource the build, but to pressure-test the tool boundaries, auth model, and injection posture before they’re production facts. That design-review-first shape is exactly what our AI integration consulting engagement is: a senior second opinion on the architecture while it’s still cheap to change, with your team keeping the build. The honest heuristic: the demo took a week, so the temptation is to believe production is two more weeks; the teams that get this right budget the demo-to-production gap as the actual project — the same gap context engineering exists to close.
The one-paragraph version for your next leadership meeting
MCP made the connection cheap. It made safe, correct, economical connection exactly as hard as it always was. The protocol is a standard now; the judgment still isn’t.
MCP made connecting AI to internal systems cheap; it made safe, correct, economical connection exactly as hard as it always was, and moved that hardness into tool design, auth boundaries, evals, and result shaping. Start read-only, enforce permissions in the server with the user’s own credentials, treat tool outputs as untrusted, log everything, and shape results like tokens cost money — because they do. Build the first one in-house on a low-stakes system; buy review before the first write-capable or regulated one ships. The protocol is a standard now. The judgment still isn’t.
