MCP gave four reference servers a 1.0.0 badge. Permissions still decide the risk

THE SIGNAL IN ONE SENTENCE

Software loves a reassuring number. Version 1.0.0 is the number that says the experiment has acquired a front desk. It suggests that maintainers are ready to describe changes with a stable contract, operators can pin a release without feeling as though they grabbed a moving ladder and downstream tools can stop treating every update as a fresh species. The official Model Context Protocol reference-server repository crossed that line on October 11 for four TypeScript packages: Everything, Filesystem, Memory and Sequential Thinking. That is useful. It is also very easy to misunderstand. The plain signal is that 1.0.0 improves release discipline. It does not certify a deployment as secure, approve every tool inside the package or decide which files an AI agent should be allowed to touch. The release record is unusually concrete. The maintainers say all 15 jobs in the release workflow succeeded. The four packages were published to npm under their stable names, tagged as latest and accompanied by SLSA provenance. The repository's Python reference servers did not make the same versioning move. Fetch, Git and Time remain on calendar versions, listed at 2026.10.10 in the release record. That split matters because the headline is not MCP is now 1.0.0. MCP is a protocol with several specifications, SDKs, clients and servers moving on their own schedules. This release concerns four TypeScript reference-server packages. Even inside the repository, cleanup remains. The maintainers still list deprecation of date-stamped TypeScript releases and reconciliation of the v2 development line with the release branch as follow-up work. So what did operators actually gain? First, a clearer version contract. Semantic versioning uses three numbers: major, minor and patch. In broad terms, a patch should fix compatible behavior, a minor release may add compatible features and a major release may introduce breaking changes. Teams can write upgrade rules around that promise, pin an exact package when they need control and review a major version before it crosses the gate. That is much better than guessing whether a date-stamped package from next Tuesday will behave like the one from last Thursday. Second, the published provenance gives consumers evidence about how a package was built and where it came from. SLSA provenance can help a team verify that an artifact is associated with the declared source and build process. It raises the cost of quietly substituting a mystery package. It does not prove the code has no vulnerability. It does not prove the configuration is sensible. It certainly does not prove an agent needed the power the server exposes. That last distinction is the important one. MCP servers connect models and agent systems to tools or data. The protocol gives clients a common way to discover capabilities and call them. A filesystem server can read files, write files, create directories, list folders, move content, search paths and inspect metadata. These are normal computer operations. They become consequential when a probabilistic system can request them at machine speed. The official Filesystem server therefore asks for allowed directories. It can receive them as command-line arguments or through MCP Roots, a protocol feature by which the connected client supplies the working boundaries. The package documentation says a Roots update replaces the server's current directory set. It also describes a useful failure mode: when no directories are supplied and the client does not support Roots, the server refuses to initialize instead of silently exposing a convenient default. That is the sort of boring behavior safety depends on. It is not the end of the permission design. If a client can provide or update roots, the trust boundary includes that client, its configuration and the person or policy allowed to approve changes. A beautifully pinned server cannot rescue a client that is authorized to hand it the wrong directory. The practical unit of review is therefore not package plus version. It is package plus version plus transport plus client plus identity plus tools plus roots plus data plus approval policy. That inventory sounds fussy until an incident begins. Then it becomes the shortest path to an answer. Consider a coding agent that needs to repair one project. The easy configuration is to expose a whole home directory. The defensible configuration is to give it the one repository, use a read-only mount for references, provide a separate writable worktree for changes and keep credentials outside both. If the task requires a deployment token, grant it through a separate, narrowly scoped path with an explicit approval gate. The model may be identical in both setups. The blast radius is not. The Memory server deserves the same treatment. A local knowledge graph can make an assistant more consistent across sessions. It can also retain names, relationships and operational details longer than a user expects. Teams should decide where that data lives, who can read it, when it expires and whether a test environment is quietly accumulating production facts. Sequential Thinking is less obviously destructive, but intermediate reasoning and planning data can contain sensitive task context. Logging, retention and observability choices still matter. The Everything server is a broad reference and test surface, useful for exercising protocol features. Its name should not be mistaken for a production permission strategy. Reference servers are examples and building blocks. They demonstrate how clients and protocol features work. They are not a universal approval for every environment in which they can be launched. The new version line makes a disciplined rollout easier. Start by recording the exact server name, version and package source. Verify provenance when the registry and tooling support it. Lock dependencies so a rebuild does not fetch a different artifact by accident. Read the release notes and the actual permission changes, not just the semver label. Then draw the permission map. List every root, credential, network destination, tool and external system the server can reach. Mark which paths are read-only, which are writable and which can trigger an irreversible action. If the map contains a home directory, a shared secrets folder or a production credential because that was easier than choosing, the review has already earned its lunch. Next, separate duties. A file server does not need network egress merely because the agent using it also calls an API. A memory store does not need deployment credentials. An analysis tool should not inherit write access from the shell that launched it. Containers, operating-system permissions and separate service identities are not glamorous, but they make protocol-level mistakes smaller. Add an approval boundary where intent becomes consequence. Reading one named file may be routine. Replacing a directory, moving a batch of files, writing outside a task worktree or changing the roots list deserves a visible decision. Approval should show the concrete target and operation, not a foggy sentence about allowing the assistant to continue. Keep a usable trail. Record the client, server version, negotiated capabilities, root changes, tool calls, target paths, outcomes and approval events. Protect sensitive contents, use retention limits and avoid turning audit logs into a second data leak. The goal is to reconstruct what happened without storing every secret the system encountered. Finally, test the stop path. Remove a root while a session is active. Deny a write. Roll back the package. Rotate the service identity. Restore a clean workspace. A permission boundary that exists only in the happy-path diagram is a suggestion. Semantic stability can help with all of this because it reduces surprise. A team can canary a patch release, compare behavior, hold a minor update for review and treat a future major version as an explicit migration. It can also automate alerts when the locked version, provenance or declared tool surface changes. But semver has limits. Compatible does not mean behaviorally identical in every workflow. A minor feature can add a tool that expands the attack surface. A bug fix can change a parser or path check in a way that matters to an application. A dependency update can alter the artifact even when the public server API looks familiar. The safest policy is not never upgrade. Old code accumulates known problems, and abandoning security fixes is its own risk. The useful policy is controlled change: exact inventory, staged deployment, observable behavior, narrow permissions and a tested rollback. There is a healthy maturity signal in the release process itself. The maintainers moved the TypeScript packages to semver, ran the release workflow, published provenance and documented unfinished migration work. That gives the community something specific to inspect rather than a hand-wavy stable label. Now clients, platforms and operators have to meet it halfway. A tool picker should show what a server can do before connection. A client should make roots visible and changes auditable. An enterprise platform should let administrators set maximum boundaries that a user or model cannot widen. Registries should surface provenance and version history. Security teams should test composed systems, not scan one package and declare the workflow safe. The milestone deserves attention because MCP has become plumbing. Plumbing benefits from boring versions, reproducible packages and predictable upgrades. Plumbing also needs valves. Four reference servers now wear a 1.0.0 badge. Keep the badge. Verify the package. Pin the release. Then look at the permission map, because that is where the water can still go.