Drive it through MCP

Outcome

By the end of this lesson, you will be able to run the loop on your own account through an assistant, make one tier 2 write, judge when an override is the right answer, and read who or what changed a resource’s state.

1. Concept

One assistant, one question. The loop you did by hand in L1 is now a conversation:

"Is my sandbox VM running, what is it costing,
 and did last night's schedule fire?"

state:      stopped since 19:02, by schedule nightly-sandbox
cost:       the VM's cost so far this month
schedule:   stopped at 19:02, started again at 08:01

Start with reads. They change nothing, and they tell you whether the assistant sees the same account, resource and schedule you set up in the console.

Then one write, at tier 2

The capstone asks for one write, and it should be a tier 2 one: a reversible change to ZopNight’s own objects. Two good choices:

A SCHEDULE CHANGE    update the schedule, or attach the resource to it
                     (update_schedule, attach_resource_to_schedule)

AN OVERRIDE          force the resource on or off until a set time
                     (create_override)

Starting or stopping the resource directly is a different thing. start_resource and stop_resource are tier 3 tools, the same tier as removing infrastructure, so an organisation set to tier 2 refuses them. You do not need them here: an override is a tier 2 write, and creating one starts (force-on) or stops (force-off) the resource straight away. When it expires, ZopNight sends the opposite action (a force-on override ends in a stop, a force-off one in a start), whatever the schedule says at that moment. So pick an expiry inside the window where the schedule wants that opposite state.

An override has rules of its own. The resource must be on a schedule, a resource that is in a group is overridden through its group, and each target can have one active override at a time.

Reading who changed the state

Your VM is stopped at 10:00 and should not be. The state history tells you who or what did it, because every row carries a trigger:

schedule:<name>...      the schedule fired. Fix: an override, or a
                        schedule change.

manual:<email>          a person clicked Stop. Fix: talk to them.

override:force_off      an override forced it off. Fix: cancel or
                        wait for the expiry.

Asking “why is my VM down” without reading the trigger wastes the first ten minutes of an incident. Ask for the state history.

When an override is right, and when it is a smell

RIGHT       a release window, a demo, an on-call night. Time-boxed,
            with a reason somebody else can read.

A SMELL     the third override this month on the same resource.
            That is a schedule that does not match how the thing is
            actually used. Change the schedule, not the exception.

Every override you set through an assistant still carries an expiry, because the expiry is enforced by the platform, not by your good intentions.

2. Demo

YOU    "My sandbox VM is stopped. What happened?"

ASSISTANT
  the VM is stopped
  the state history shows a stop at 19:02, trigger schedule:nightly-sandbox
  no override is active on it

YOU    "Hold it up until 20:00 today, reason: demo."

ASSISTANT
  creates a force-on override expiring at 20:00 today (tier 2)
  the override starts the VM straight away

YOU    "Tomorrow, go back to the normal schedule."
ASSISTANT
  nothing to do: at 20:00 the override expires, ZopNight sends
  the opposite action, and the VM is stopped, as the schedule
  wants (its nightly stop is 19:00)

The last line is the design. An override that needs undoing by hand is an override that will be forgotten.

3. Hands-on (6 min)

1. Connect your assistant to ZopNight with a token that can write at
   tier 2, and check the organisation's write tier allows tier 2.
2. Ask for the full picture of your sandbox resource: state, cost so
   far, and whether the schedule fired.
3. Ask why the resource is in its current state, and read whether the
   answer names the trigger from the state history.
4. Make one write: set an override to hold it up for two hours, with
   a reason, or change the schedule.
5. Ask what overrides are active in the org, and confirm yours has
   an expiry.
6. Open Audit Logs in the console and find your write, with source mcp.

Do it through MCP. The same task you just did in the console, asked in one sentence.

BEFORE  The resource and schedule from L1, and an assistant connected to ZopNight.
ASK     "Is my sandbox VM up, did the schedule fire last night, and what has it cost this month?"
CHECK   the answer names the schedule firing from the state history, not a guess. If it does not, ask again for the history, because that is what the next incident turns on.

Tools behind it: list_resources (read, Explore), get_state_history (read, Operate), get_schedule_success (read, Cost), get_cost_by_resources (read, Cost), list_overrides (read, Operate), create_override (write, tier 2, reversible), update_schedule (write, tier 2, reversible). Connection details are in the MCP integration docs.

4. Knowledge check

Q1

Your VM stops answering at 19:05. The state history shows a stop at 19:02 with a schedule: trigger. The right first move, if it genuinely needs to be up:

A. Ask the assistant to call stop_resource and then start_resource
B. Delete the schedule so it never fires again
C. Set an override with an expiry and a reason
D. Disconnect and reconnect the cloud account

Q2

Your organisation’s write tier is 2. You ask the assistant to start your VM with start_resource. What happens?

A. It starts, because starting a VM is a reversible change
B. It is refused, because start_resource is a tier 3 tool
C. It starts, but only if the VM is already on a schedule
D. It is queued and runs at the next firing of the schedule

Q3

You set an override through an assistant and forget about it. What happens?

A. It expires at the time you set; the platform enforces the expiry
B. It stays in place until somebody notices it and removes it by hand
C. It is cleared at the next firing of the schedule it was set against
D. It becomes a permanent change to the schedule it was set against

5. Apply

Run the loop once a week on something real, not to save money but to keep the muscle: is it up, did it fire, what did it cost, and is any override still standing that should not be.

KEEP
  the one question that answered all three
  the write you made, and its audit log entry with source mcp

Related lessons

• L3: Deploy a service on ZopCloud
• T1.M1.5.L2: Force-on, force-off, expiry, reason
• T1.M1.6.L1: The state-history timeline

Glossary terms touched

Override · Schedule · MCP audit log · Blast radius