# MCP Servers Are Not the Hard Part > Source: > Published: 2026-06-05 03:00:50+00:00 The MCP demo is easy now. That is the part people keep underestimating. Once a protocol gets enough examples, SDKs, docs, and copy-pasteable server templates, the first win becomes cheap. Your agent calls a tool. It reads a resource. It pulls context from somewhere that used to require glue code. The screenshot looks great. Then the second server shows up. Then the fifth. Then someone gives an agent access to browser debugging, issue trackers, a database console, internal docs, shell commands, deployment scripts, or all of the above because "it needs context." That is where MCP stops being a connector story and becomes an operating model story. The hard question is not "can the agent call this?" The hard question is "who decided it was allowed to call this, with which credentials, under which conditions, and what receipt do we have afterward?" The official Model Context Protocol framing is clean: MCP standardizes how applications provide context and tools to models. Instead of every AI application inventing its own custom integration layer, you get a common client/server mental model. Hosts run clients. Servers expose capabilities. Models can work with tools, resources, prompts, and other structured context through a more predictable interface. That is a real improvement. Integration sprawl was already becoming gross. But standardization does not remove risk. It normalizes the surface area. A shared protocol makes it easier to add more tool access, and more tool access means more decisions that need to be explicit. The mistake is treating MCP servers like editor plugins. An editor plugin mostly extends a human's workspace. An MCP server can extend an agent's authority. Those are not the same thing. A tool call can mutate state. A resource can expose sensitive context. A prompt template can shape behavior in ways reviewers never see. A task flow can let work continue after the initial user intent has become fuzzy. If you collapse all of that into "the agent has MCP access," you have already lost the plot. The early version of MCP adoption is usually direct wiring: That works for a demo. It might even work for a solo workflow. It gets weird as soon as more people, more agents, or more environments are involved. Credential handling is the first smell. If secrets live in scattered local configs, copied setup docs, or prompt-adjacent instructions, you are depending on vibes and memory. OAuth refresh, secret rotation, and environment-specific access should not be reinvented per agent. Inventory is the next one. Most teams can tell you which production services they run. Fewer can immediately answer which agent can call which MCP server, which tools are write-capable, and which resources expose internal data. Then comes logging. A normal app integration leaves traces in service logs, API logs, database logs, or deploy logs. Agent tool calls need the same level of reviewability, but tuned for developer workflow: what did it read, what did it call, what changed, what failed, what did it skip, and which approval gate did it pass? Without that, MCP access becomes invisible infrastructure. Invisible infrastructure is where expensive mistakes go to hide. One practical starting point: stop using "MCP access" as a single permission. Break it down. **Tools** are active capability. They can search, inspect, create, update, delete, deploy, comment, file tickets, trigger workflows, or run commands. A read-only tool and a write-capable tool should not share the same approval path. **Resources** are context. They might be harmless docs. They might also be customer data, internal strategy, private code, credentials by accident, logs, or sensitive operational state. "The model only read it" is not a serious security model when context can steer later actions. **Prompts** are policy-shaped inputs. If a server exposes prompts, those prompts can become part of how the agent decides what to do. They deserve review like any other behavior-affecting artifact. **Task flows** add lifecycle. Once an agent can start, track, resume, or coordinate work, you need boundaries around duration, scope drift, and handoff state. This is why the gateway/control-plane discussion is more interesting than it first looks. The useful part is not the enterprise label. It is the recognition that auth, policy, observability, and tool discovery want a central place to live once the system grows past a few direct connections. Small teams do not need a giant governance program. They do need a boring list: That list is not bureaucracy. It is the minimum viable map. Browser and DevTools access is one of the clearest examples because the value is not theoretical. A frontend agent that can inspect the page, read console output, watch network requests, test layout, and profile runtime behavior is much more useful than one staring at static files. Static code tells you what the app claims it should do. The browser tells you what it actually did. That is exactly why the boundary matters. Runtime visibility can expose auth state, API responses, cookies, tokens, user data, unpublished UI, feature flags, and debugging surfaces. It can also tempt teams into giving an agent broad "just inspect everything" authority because the workflow feels magical when it works. The right lesson is not "do not connect agents to DevTools." That would be throwing away the good part. The right lesson is: powerful runtime access needs scoped authority. For a frontend workflow, that might mean: That is a much healthier mental model. The agent gets enough access to be useful, but not so much that "debug the page" quietly turns into "operate the product." The community arguments around AI coding-agent cost are easy to reduce to model pricing, but that misses part of the point. Context is not free just because the model window got bigger. Tool exposure is not free just because the call succeeded. Every extra server gives the agent another path to spend tokens, time, credentials, and trust. This is where governance and developer ergonomics meet. A good MCP setup should make the cheap path obvious: That last part matters. Developers do not want a compliance archive they will never read. They want receipts that help them review work. For an agent change, the useful receipt is simple: Apply the same idea to MCP calls. If an agent used a server to inspect browser state, query a repo, read internal docs, or trigger a workflow, the reviewer should not have to reconstruct that from a vague final message. You do not need to build the perfect MCP gateway before using MCP. You do need to avoid the trap where every new server becomes a permanent exception. Start with five rules. Write down every MCP server, what it exposes, who uses it, and what environment it touches. Keep it close to the repo or platform config, not buried in someone's notes. The inventory should distinguish tools, resources, prompts, and task flows. A server that only exposes public docs is not the same as a server that can operate a browser or mutate tickets. Read access is still access, but write access is where blast radius spikes. Separate them before the system becomes hard to change. For example, an agent may be allowed to inspect issues, logs, docs, and local app state freely. Creating issues, changing labels, posting comments, editing files, triggering deploys, or calling production APIs should go through a narrower path. Prompts are a terrible place to manage secrets. So are random local snippets copied between machines. If more than one person or agent uses the workflow, credentials need lifecycle: scoped access, rotation, revocation, and environment separation. Even a simple wrapper that centralizes credential lookup is better than sprinkling secrets across agent configs. Asking for approval once at the beginning of a session is lazy design. Approval should happen when the action changes category: read to write, local to remote, draft to publish, inspect to mutate, test to deploy. That makes the interruption meaningful. It also gives the reviewer a better question to answer. If the agent cannot explain what it touched, the work is not done. This does not need to be fancy. A markdown note, JSONL log, PR comment, or final run summary can work. The format matters less than the habit: every meaningful tool-using agent run should leave behind enough evidence for another developer to review it. The mature MCP question is not "how many servers can we connect?" It is "how quickly can we tell what authority this agent has, what it used, and whether that authority matched the task?" That is the shift teams need to make. MCP is a good answer to integration chaos, but it also makes agent tool access easier to spread. If you treat that spread as plugin installation, you will eventually get a mess of invisible permissions, drifting credentials, and unreviewable actions. Treat it like production integration design instead. Inventory the surface. Separate read from write. Scope credentials. Gate risky actions. Leave receipts. The server is the easy part. The operating model is where the real engineering starts. **Source notes**