# ZopDay's MCP Assistant Adds Observability, Not Just More Tools > An assistant connected through MCP could already deploy a service, trigger a build, and create a revision. What it couldn't do was much of what surrounds a deploy in practice. Registering the… Source: https://zop.dev/resources/blogs/zopday-mcp-tool-coverage-321 Published: 2026-09-16 · Author: riya-mittal · Tags: autonomouscloud, devops, mcp --- An assistant connected through [MCP](https://github.com/modelcontextprotocol/modelcontextprotocol) could already deploy a service, trigger a build, and create a revision. What it couldn't do was much of what surrounds a deploy in practice. Registering the infrastructure a service runs on, setting up the namespace and networking it needs, installing the component it depends on, running the database migration that has to happen first, reading the logs that explain why any of that failed: all of it needed a human. A tool that can act but can't diagnose ends up needing a human for exactly the moments it would be most useful to have covered. ## 289 Tools Became 321, Split Almost Evenly Between Reading and Writing The new tool groups cover infrastructure lifecycle, namespaces and networking, components, migrations, observability, catalog, and provisioning. Of the 321 total tools, 182 are read tools and 139 are write tools, a split that stays close to even rather than skewing toward either pure inspection or pure action. The ship group, covering deploys and related actions, grew from 24 tools to 54. The diagnose group grew from 9 to 11. | Tool group | Covers | Read or write | |---|---|---| | Infrastructure lifecycle | Register and remove infrastructure | Both | | Namespaces and networking | Create namespaces, check custom domain DNS | Both | | Components | Install and upgrade components | Both | | Migrations | Run and retry database migrations | Write | | Observability | Read build and service logs, diagnose a failing deploy | Read | Every one of these is available to the same assistant that could already deploy. That matters because the value of the new groups is mostly in how they combine with what already existed: an assistant that can read a service's logs and then retry the migration that log points to is doing something neither capability could do alone. ## A Bigger Write Surface Only Stays Safe If Every Tool Passes the Same Gates Adding 58 new write tools without weakening anything meant every one of them has to pass through the same four checks a write tool already had to pass. A fleet-wide kill switch can shut off writes entirely. The organization's own MCP write tier decides what that org is allowed to authorize at all. The token has to be bound to that specific organization. The token's own scope has to cover the specific action being attempted. Architecture diagram None of that is new by itself. What's new is a pair of fleet-wide invariants added specifically to keep this guarantee from depending on each new tool's author remembering to wire it correctly by hand: every tool-manifest binding must fold to a real policy, and no tool that mutates anything is allowed to fold to a view-only policy. A binding that fails either check is a configuration error the system catches on its own, not a gap that ships quietly and gets discovered later. This works when a new tool's manifest entry declares a policy the fleet-wide check recognizes. It fails the deploy outright, rather than shipping a silent gap, when a mutating tool's binding folds to view-only. ## Database Migrations Got Their Own Permission, Not a Shared One Most of the new write tools slot into the same permission tiers that governed writes before this release. Migrations didn't. Running or retrying a database migration now requires a permission specific to that action, separate from the general write gates everything else shares. A migration [failure mode](https://zop.dev/resources/blogs/self-healing-infra-the-4-signals-that-trigger-autonomous-rollback) looks nothing like a bad deploy: it can leave a schema half-changed in a way a simple revert doesn't cleanly undo, which is exactly the kind of action that deserves its own explicit yes rather than inheriting a broader one. Across all three write tiers, the counts land at 34, 76, and 29 tools. That distribution puts the largest group in the middle tier rather than at either extreme, consistent with most new capabilities being real but bounded actions rather than either trivial toggles or org-wide changes. ## Refusing to Answer Is Sometimes the Correct Fix Two smaller fixes shipped alongside the new tool groups, and both are about what a tool says when it can't fully answer. `get_service_logs` used to report "no replicas" when it genuinely couldn't resolve which workload was meant. That reads as "nothing is running" when the real problem is "I don't know which service you mean." It now refuses the read outright in that case, which is a worse-looking answer that's a more honest one. `get_build_logs` gained a byte limit alongside its existing chunk-count limit, closing off a case where a small number of very large chunks could still return an unbounded amount of data. None of this shipped behind a new flag. `MCP_WRITE_ENABLED` and `MCP_AUTHZ_ENFORCE_READS` are unchanged, and both still default closed. The 321 tools exist in the manifest either way; whether an organization's assistant can actually call the write ones still comes down to the same four gates that governed the smaller tool set, just applied to more of it.