ZopDev MCP

npx add-mcp 'https://api.zop.dev/mcp-server'

ZopNight MCP Server: Access, Write Tiers and Audit

How the ZopNight MCP server lets Claude, Cursor and Codex read cost and resource data, how write access is tiered and gated, and what is audited.

Source: https://zop.dev/learn/mcp-server Published: 2026-07-01 · Updated: 2026-09-24 · Author: avinash-gaurav · Tags: zopnight, zopday, learn, mcp-server, mcp, integrations

---

An AI assistant gets the same view of your estate you have in the app, and only as much power to change it as your organization allows.

The Model Context Protocol (MCP) is an open protocol for connecting AI applications to external systems. A server exposes tools, which are functions the model can call, plus optional resources and prompts; a client such as Claude Desktop discovers the tools with a tools/list request and invokes one with tools/call, all encoded as JSON-RPC. The ZopNight MCP server exposes ZopNight's data and actions this way, so an assistant can answer questions about cost, resources, and recommendations from live data instead of from what someone pasted into the chat.

Which clients

ZopNight's MCP server is used from AI assistants including Claude Desktop, Cursor, Codex, and Claude Code. Because MCP is an open protocol, the server is not tied to one assistant.

What an assistant can read

Read tools cover resources, schedules, costs, recommendations, teams, budgets, audit logs, billing sync, dashboards, the autoscaler, event readiness, governance and policy, and the ZopDay delivery surface. List tools forward the full filter and pagination set, such as provider, status, region, search, and sort, so the assistant can ask narrow questions instead of pulling everything, and results from expensive aggregation tools are cached for up to 30 minutes, so a repeated question is fast but can trail the app slightly. Tool counts change between releases, so this page does not quote one; your client's tool list is the authoritative answer.

Authentication and who you are

Access is enabled per organization by an org-level MCP toggle (an organization created through an MCP client's OAuth sign-in starts with it on). A client either signs in with OAuth, limited to the organizations you approve on the consent page, or authenticates with a personal access token (prefixed zn_pat_); both are validated at ZopNight's gateway. Authorization happens at the gateway against the same RBAC that governs the app; the MCP server itself holds no authorization logic. In practice this means an assistant connected with your token can see what your role can see, including team-scoped limits on which resources are visible. Create tokens for the person with the narrowest role that does the job.

Write access is opt-in and tiered

Every organization starts at write tier none: read tools only. An organization can raise its tier, and each tier admits the ones below it:

Tier	What it admits
None (default)	Read tools only
1, metadata only	Metadata-only changes
2, reversible	Changes that can be undone
3, irreversible	Changes with no undo; also requires an organization-bound token

A write call must pass the organization's tier, the caller's live role, and the token's own scope; the gateway checks all three. The write surface also sits behind a platform-wide kill switch that is off by default, so it is inert until enabled. Role and member management tools sit at tier 1, and bulk start and stop sit at tier 3. Four operations have no MCP tool at any tier: deleting the organization, deleting a cloud account, reading credentials, and assigning org-level roles. The service-configuration tool redacts every environment variable value, and no tool reveals one.

Only what you may call is listed

The tools/list response is filtered at the gateway to exactly the tools the caller may invoke: a tool is advertised only if the gate would allow it. Two people connected to the same organization can therefore see different tool lists.

Everything is audited, including reads

MCP calls land in the audit log with a source marker. Read calls are audited too, recorded with the request but without the response payload, while a failure message is kept. In the audit-log viewer, reads show as Read rows described by their tool, and bursts of reads at the same instant collapse into one row.

A caution before raising the tier

A read tool hands the model strings that other people can influence: resource names, tags, and descriptions. With write tools enabled, that text becomes a possible instruction to an agent. The MCP specification itself says there should always be a human able to deny tool invocations, and that clients must treat tool annotations as untrusted unless they come from trusted servers. Raise the tier only as far as the task needs.

For what tools are and how they are grouped, see MCP tools explained; for why this matters, see MCP and AI cloud management and the Claude setup how-to.

Frequently asked questions

Can the MCP server change my cloud resources?

Only if your organization raises its write tier. Every organization starts with read tools only, the write surface sits behind a kill switch that is off by default, and each write must also be allowed by the caller's role and the token's scope.

Why is my tool list different from a colleague's?

tools/list is filtered at the gateway to the tools each caller may invoke, so it reflects your role, your organization's write tier, and your token.

Are read-only questions logged?

Yes. Reads are audited with the request recorded and the response payload dropped; failure messages are kept.