What MCP is in one page · ZopDev University

Outcome

By the end of this lesson, you will be able to explain what MCP (Model Context Protocol) is without jargon, identify the tool surface ZopNight exposes, and reason about why a default-read posture with an opt-in write tier is the right tradeoff for cloud cost.


Prerequisites	T0 (foundations) · T1 (ZopNight surface awareness)
Time	9 minutes

1. Concept

MCP stands for Model Context Protocol. It is an agreed way for an AI assistant to talk to a service.

Claude Desktop, Cursor, Codex and Claude Code all speak it. Once a service is connected, the assistant can call that service’s functions, after proving who it is, and gets back structured data rather than a page of text to guess at.

Anthropic published it openly at the end of 2024. ZopNight implements it as something that reads by default, with writing available only if you turn it on.

WITHOUT MCP:
  Engineer asks Claude: "What's our biggest idle resource?"
  Claude: "I don't have access to your cloud data."
  Engineer: pastes data manually into the conversation
  (slow, error-prone, doesn't scale, no chain calls)

WITH MCP:
  Engineer asks Claude: "What's our biggest idle resource?"
  Claude (via MCP): calls get_recommendations on ZopNight
  Claude: "i-0xyz123 has been stopped for 47 days, costs $69/month
  in attached EBS volumes alone."

On a default-configured organisation the agent has read access only, which is what makes this walkthrough safe to try on production data.
The engineer never leaves the conversation.

Why this matters in 2026

Before MCP, AI assistants were limited to what the engineer could paste. With MCP, the agent’s knowledge boundary shifts; it can query real systems, get current data, and answer with specifics rather than generalities. For cloud cost in particular, this changes the workflow: engineers ask their AI assistant questions about real infrastructure rather than navigating the dashboard.

What ZopNight’s MCP server exposes

The MCP server exposes more than 300 tools, most of them read-only, across these families:

TOOL FAMILIES (more than 300 tools)
─────────────────────────────────────────────────────
Resources         Costs / billing      Recommendations
Schedules         Overrides            Teams / showback
Budgets           Audit logs           Cloud accounts
Notifications     Organisation         Billing sync
Dashboards        Autoscaler           Event readiness
Governance        Smart Tags           IaC policy +
/ policy                               validation runs
Projects /        Services /
Environments      Infrastructure
─────────────────────────────────────────────────────
More than 300 tools, most of them read-only. The mutating
surface is gated (see The contract, below).
Never hand-copy a count: the MCP server's own
catalog is the source of truth and new tools land per release.

What a given caller sees is narrower than the catalog. The
advertised tool list is filtered at the gateway to exactly the
tools that caller is allowed to call, so discovery and
authorisation always agree: a tool you cannot call is a tool
you never see.

See the MCP integration docs for setup and usage. New tools land per release.

The contract

Reads are always available. Writes are opt-in per organisation and off by default, so an agent connected to a default-configured organisation can observe the estate and change nothing.

WRITE TIER (per organisation, default none):
  none          reads only. The default.
  metadata-only ZopNight's own records, no cloud state
  reversible    bounded blast radius, may affect cost
  irreversible  no undo, or it incurs cost

Every write tier also needs a token bound to the organisation.
Enforced at the gateway, together with the caller's live role
and the token's own scope. A global kill switch sits above all
of it and is off by default.

Two capabilities have no tool at any tier: deleting the organisation and deleting a cloud account. Role and member management (tier 1) and bulk start/stop (tier 3) do have tools, so they are reachable once an organisation opts in that far. No tool returns a configuration secret; get_service_config redacts every environment-variable value.

The important architectural point is where the decision is made: the gateway resolves it, and the MCP server itself holds no authorisation logic. That is covered fully in the module on what is not writable via MCP.

Why MCP matters (the engineering case)

Two practical reasons MCP changes the workflow:

1. NATURAL LANGUAGE INTERFACE
   Engineers ask questions in their IDE, chat, or CLI without
   switching contexts. The AI assistant becomes a query layer over
   ZopNight. "Show me the biggest cost growth this week" is faster
   than navigating to Costs → Reports → Summary → filter.

2. AGENT COMPOSITION (chain calls)
   Agent chains MCP calls with other tools:
     "Find the top idle EC2 instance.
      Look up the owner from the tag.
      Draft a Slack message asking them about it."

   Three calls, three different systems, one conversation.
   The MCP server gives the agent the data; agent chains it
   with Slack, source-control, ticketing systems.

Architecture

Claude Desktop / Cursor / Codex / Claude Code
    ↓ (MCP protocol: JSON-RPC over HTTPS)
ZopNight gateway (OAuth token or PAT checked, write tier and role enforced)
    ↓
ZopNight MCP server (hosted by ZopNight)
    ↓
ZopNight backend services

The MCP server is a stateless proxy behind the gateway, which authenticates every call. It routes calls to the right backend service. No customer data is stored on the MCP server itself: every call retrieves fresh data from the backend.

Where MCP runs

HOSTED (the only mode):
  ZopNight runs the MCP server behind its gateway
  AI tool connects over HTTPS to one Server URL
    (e.g. https://api.zop.dev/mcp-server)
  Sign in with OAuth (default) or send a PAT as a bearer header
  Nothing ZopNight-specific is installed on the engineer's machine
  Still subject to the org's MCP toggle (M6.3)

Every organisation can use both OAuth and PATs; there is no local mode to choose.

MCP vs API

RAW ZOPNIGHT API:                       MCP:
  Direct REST calls                       Through AI assistant
  Engineer writes code                    Engineer asks in natural language
  Used by: integrations, custom tools     Used by: agent workflows
  Read + write                            Read by default; writes
                                          opt-in per organisation

Both are available. MCP is the agent-friendly path; API is the
programmer-friendly path. They share the same underlying data.

How ZopNight uses MCP internally

ZopNight engineers use MCP to query their own ZopNight installations during product development. The dogfooding matters; the team uses MCP daily, which catches usability issues fast and ensures the tool surface is curated for real workflows.

2. Demo

A typical engineer’s session with MCP connected:

ENGINEER IN CURSOR (MCP connected to ZopNight):

  Engineer: "What's our biggest idle resource right now?"
  Cursor (via MCP):
    Calls get_recommendations (idle-resource recommendations)
    Returns: 12 idle EC2 instances
  Response: "i-0xyz123 (m5.2xlarge, stopped 47 days, $69/mo) is
            the biggest single idle resource. Combined idle: $810/mo."

  Engineer: "Get the top 10 recommendations by savings."
  Cursor (via MCP):
    Calls get_recommendations, sorted by savings
    Returns: 10 recommendations
  Response: "Top 10 by potential savings:
            1. Right-size i-0abc → $1,200/mo
            2. Terminate i-0def (idle 60d) → $480/mo
            ... (full list)
            Total potential: $4,800/mo"

  Engineer: "Describe the business-hours-eu schedule."
  Cursor (via MCP):
    Calls get_schedule for business-hours-eu
    Returns: cron config, attached resources, recent firings
  Response: "business-hours-eu fires 8AM and 8PM Mon-Fri Europe/London.
            Attached to 14 resources in the eu-west-1 region.
            Last 5 firings all succeeded. No overrides active."

  Engineer: "Show me overrides created in the last week."
  Cursor (via MCP):
    Calls list_audit_logs(filter={action: "override_create",
                                  time: "7d ago"})
    Returns: 3 override creations
  Response: "3 overrides created in the past week:
            1. jane@platform on 2026-05-15 (24h override on dev-eks)
            2. bob@product on 2026-05-17 (override on staging-rds)
            3. alice@data on 2026-05-19 (until-cancel on ml-cluster)

            One of these (alice's) is still active: worth a check."

The engineer never opens the ZopNight UI. The AI assistant is
the working surface; ZopNight is the data layer.

3. Hands-on (5 min)

Identify which AI tool your team uses:

YOUR AI TOOL:
  □ Claude Desktop
  □ Cursor
  □ Codex (GitHub Copilot, OpenAI Codex CLI)
  □ Claude Code
  □ None of the above
  □ Multiple

WHO USES IT:
  □ All engineers
  □ Some engineers (~__%)
  □ FinOps team specifically
  □ Pilot phase

MCP READINESS:
  Does your AI tool support MCP?    Yes / No / Unsure
  Is MCP enabled at the user level?  Yes / No / Unsure

PLAN to connect:
  □ Set up MCP for one engineer as pilot
  □ Enable org-wide (covered in M6.3)
  □ Defer until later (acceptable; not all teams need this yet)

If your team doesn’t use any AI tool with MCP support, this track is still relevant background: but the practical setup waits until you adopt one.

4. Knowledge check

Q1

MCP enables AI agents to:

A. Modify cloud resources directly, including start, stop and delete
B. Query ZopNight through the tools its token is allowed to call
C. Replace the dashboards with a conversational interface
D. Train on the organisation’s own cost data over time

Show answer

Correct: B. Reads are always available; mutating tools exist but are opt-in per organisation and off by default, so on a default-configured org the agent answers questions and drafts changes while a human executes them. A is wrong as a default but is not impossible: it is what the higher write tiers allow, and every write tier needs an organisation-bound token on top of the opt-in.

Q2

A natural-language query about cost savings from an engineer:

A. The agent calls MCP tools (get_recommendations, get_cost_trends) and answers in natural language with specifics
B. Must reference a specific dashboard before it is able to answer
C. Requires the numbers to be pasted in by hand from the web UI
D. Is answered entirely from the model’s own training data rather than from the live cost figures held in ZopNight

Show answer

Correct: A. No manual data copying; no dashboard navigation. The AI assistant becomes the query layer over ZopNight. The dashboard remains available; MCP just routes around it for query-style workflows.

Q3

ZopNight’s MCP server is:

A. Read-only and hardcoded, so the customer has no configuration surface they can change
B. Write-enabled by default, with RBAC as the only control over what actually runs
C. Read by default, with writes configurable per organisation across four tiers (none, metadata-only, reversible, irreversible) and a global kill switch above them that is off by default
D. Customizable per tier, but only by ZopNight support staff rather than by the customer themselves, and then only on the enterprise plan tiers with a signed addendum

Show answer

Correct: C. Agents can hallucinate, so the write surface is something an organisation opts into deliberately rather than something it inherits. Configurable, not hardcoded, and the decision is enforced at the gateway rather than inside the MCP server. Note what stays off the table at every tier: organisation deletion and cloud-account deletion, which have no tool.

5. Apply

Read the MCP integration docs. Connect your preferred AI tool (M6.2 covers each tool), signing in with OAuth, or with a PAT for CI and non-browser clients (M6.3 covers PAT management).

To turn the workflows you repeat into saved, shareable prompts, see M6.4.

Glossary terms touched

MCP · PAT · Tool call

Outcome

1. Concept

Why this matters in 2026

What ZopNight’s MCP server exposes

The contract

Why MCP matters (the engineering case)

Architecture

Where MCP runs

MCP vs API

How ZopNight uses MCP internally

2. Demo

3. Hands-on (5 min)

4. Knowledge check

Q1

Q2

Q3

5. Apply

Related lessons

Glossary terms touched

Start with the bill.