{"slug": "mcp-servers-are-not-the-hard-part", "title": "MCP Servers Are Not the Hard Part", "summary": "A developer argues that the hardest part of adopting the Model Context Protocol (MCP) is not building the servers, but managing the operational and security model once multiple servers are in use. The developer warns that MCP servers extend an agent's authority, not just a human's workspace, and that treating tool access as a single permission leads to invisible infrastructure where mistakes hide. The post calls for breaking down MCP access into separate controls for tools, resources, and prompts, with explicit credential handling, inventory tracking, and logging.", "body_md": "The MCP demo is easy now.\n\nThat 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.\n\nThen the second server shows up.\n\nThen the fifth.\n\nThen 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.\"\n\nThat 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?\"\n\nThe 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.\n\nThat is a real improvement. Integration sprawl was already becoming gross.\n\nBut 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.\n\nThe mistake is treating MCP servers like editor plugins.\n\nAn 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.\n\nIf you collapse all of that into \"the agent has MCP access,\" you have already lost the plot.\n\nThe early version of MCP adoption is usually direct wiring:\n\nThat works for a demo. It might even work for a solo workflow.\n\nIt gets weird as soon as more people, more agents, or more environments are involved.\n\nCredential 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.\n\nInventory 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.\n\nThen 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?\n\nWithout that, MCP access becomes invisible infrastructure. Invisible infrastructure is where expensive mistakes go to hide.\n\nOne practical starting point: stop using \"MCP access\" as a single permission.\n\nBreak it down.\n\n**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.\n\n**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.\n\n**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.\n\n**Task flows** add lifecycle. Once an agent can start, track, resume, or coordinate work, you need boundaries around duration, scope drift, and handoff state.\n\nThis 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.\n\nSmall teams do not need a giant governance program. They do need a boring list:\n\nThat list is not bureaucracy. It is the minimum viable map.\n\nBrowser and DevTools access is one of the clearest examples because the value is not theoretical.\n\nA 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.\n\nThat is exactly why the boundary matters.\n\nRuntime 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.\n\nThe right lesson is not \"do not connect agents to DevTools.\" That would be throwing away the good part.\n\nThe right lesson is: powerful runtime access needs scoped authority.\n\nFor a frontend workflow, that might mean:\n\nThat 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.\"\n\nThe 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.\n\nEvery extra server gives the agent another path to spend tokens, time, credentials, and trust.\n\nThis is where governance and developer ergonomics meet. A good MCP setup should make the cheap path obvious:\n\nThat last part matters. Developers do not want a compliance archive they will never read. They want receipts that help them review work.\n\nFor an agent change, the useful receipt is simple:\n\nApply 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.\n\nYou do not need to build the perfect MCP gateway before using MCP.\n\nYou do need to avoid the trap where every new server becomes a permanent exception.\n\nStart with five rules.\n\nWrite 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.\n\nThe 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.\n\nRead access is still access, but write access is where blast radius spikes. Separate them before the system becomes hard to change.\n\nFor 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.\n\nPrompts are a terrible place to manage secrets. So are random local snippets copied between machines.\n\nIf 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.\n\nAsking for approval once at the beginning of a session is lazy design.\n\nApproval 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.\n\nIf the agent cannot explain what it touched, the work is not done.\n\nThis 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.\n\nThe mature MCP question is not \"how many servers can we connect?\"\n\nIt is \"how quickly can we tell what authority this agent has, what it used, and whether that authority matched the task?\"\n\nThat 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.\n\nTreat it like production integration design instead.\n\nInventory the surface. Separate read from write. Scope credentials. Gate risky actions. Leave receipts.\n\nThe server is the easy part. The operating model is where the real engineering starts.\n\n**Source notes**", "url": "https://wpnews.pro/news/mcp-servers-are-not-the-hard-part", "canonical_source": "https://dev.to/hefty_69a4c2d631c9dd70724/mcp-servers-are-not-the-hard-part-1e7d", "published_at": "2026-06-05 03:00:50+00:00", "updated_at": "2026-06-05 03:10:59.075221+00:00", "lang": "en", "topics": ["ai-agents", "ai-safety", "ai-infrastructure", "ai-tools", "ai-ethics"], "entities": ["Model Context Protocol", "MCP"], "alternates": {"html": "https://wpnews.pro/news/mcp-servers-are-not-the-hard-part", "markdown": "https://wpnews.pro/news/mcp-servers-are-not-the-hard-part.md", "text": "https://wpnews.pro/news/mcp-servers-are-not-the-hard-part.txt", "jsonld": "https://wpnews.pro/news/mcp-servers-are-not-the-hard-part.jsonld"}}