Drive it through MCP

Outcome

By the end of this lesson, you will be able to run the whole loop through an assistant, judge when an override is the right answer, and recognise the two failure modes that look identical from the outside.

1. Concept

One assistant, two products, one question. The loop you have been doing by hand is now a conversation:

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

ships:      the service, its last deploy, its URL
costs:      the compute behind it, this month
schedule:   fired at 19:02, started again at 08:01

That is the first-value moment this module exists to produce. Not a tour of features: one question that crosses a boundary a console cannot.

The two failures that look the same

Your service is down at 10:00 and should not be. Two very different causes present identically:

THE SCHEDULE STOPPED IT     the resource is stopped, the history
                            shows a scheduled stop, and the fix is
                            an override or a schedule change.

THE DEPLOY IS BROKEN        the resource is running, the replica is
                            crashlooping, and the fix is a rollback.

Asking “why is my service down” without distinguishing these wastes the first ten minutes of an incident. Ask for both: the schedule history and the deploy state.

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 capstone service is not answering. What happened?"

ASSISTANT
  the compute is stopped
  the schedule fired a stop at 19:02 last night
  the last deploy was green, three days ago

YOU    "Start it and hold it up until 18:00 today, reason: demo."

ASSISTANT
  starts the resource
  sets an override expiring at 18:00 today

YOU    "Tomorrow, go back to the normal schedule."
ASSISTANT
  nothing to do: the override expires on its own

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. Ask your assistant for the full picture of your capstone service:
   deploy state, cost so far, and whether the schedule fired.
2. Stop the resource deliberately, through the assistant.
3. Ask why the service is not answering, and read whether the answer
   distinguishes a scheduled stop from a broken deploy.
4. Set an override to hold it up for two hours, with a reason.
5. Ask what overrides are active in the org, and confirm yours has
   an expiry.
6. Roll the service back one version, then forward again.

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

BEFORE  The service and schedule from L3, and an assistant connected to both products.
ASK     "Is my capstone service up, did the schedule fire last night, and what has it cost this month?"
CHECK   the answer names the schedule firing and the deploy separately. If it conflates them, ask again for both, because that distinction is what the next incident turns on.

Tools behind it: get_service_overview (read, Ship), get_state_history (read, Operate), get_schedule_success (read, Cost), get_cost_by_resources (read, Cost), create_override (write, tier 2, reversible), rollback_service (write, tier 2, reversible). The full catalogue is at zop.dev/learn/mcp-tools.

4. Knowledge check

Q1

Your service stops answering at 19:05. The state history shows a scheduled stop at 19:02. The right first move:

A. Roll back the last deploy
B. Delete the schedule
C. Set an override, if it genuinely needs to be up, with an expiry and a reason
D. Redeploy the service

Q2

Which pair of facts distinguishes a scheduled stop from a broken deploy?

A. The URL and the region
B. The resource state plus the state history, against the deploy state plus the replica log
C. The cost this month and the cost last month
D. The project name and the environment name

Q3

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

A. It expires at the time you set, because the expiry is enforced by the platform
B. It stays until somebody removes it
C. It is removed at the next schedule firing
D. It converts into a schedule change

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 override you set, and the fact it expired without you

Related lessons

• L5: Evidence, and what certification checks
• 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