# Optimize

> Fourteen MCP tools cover recommendations and schedules. Six read: listing findings, filtering by provider, and summarising the savings available. One sits at tier 1, and seven at tier 2 (reversible) for creating and updating schedules, attaching resources to them, and setting temporary overrides.

Source: https://zop.dev/integrations/mcp-server/tools/optimize
Updated: 2026-08-20

---

## Common questions

### Can an assistant set up schedules without being able to stop anything?

Yes, and that is the reason for the split. The seven scheduling tools are tier 2 because a schedule is a reversible rule and nothing has happened yet. Acting on live infrastructure through stop_resource is tier 3 and stays off.

### How do I keep staging up tonight without editing the schedule?

create_override. It forces a resource on or off until it expires, taking precedence over the schedule while leaving the schedule itself intact.

### A recommendation shows no saving figure. Does that mean zero?

No, it means unpriceable. The figure comes from the rule that produced the finding, the same one the interface shows, and a rule that cannot price a change reports nothing rather than guessing.

## Reading findings

`get_recommendations` and `get_recommendation_summary` are the entry points;
`get_recommendation_by_provider` and `list_recommendation_resources` narrow by cloud or by the
resources a finding touches. `get_override_candidates` lists resources currently forced on or
off against their schedule.

All of these work at the default read-only setting, so an assistant can report what ZopNight
found and what it would save without any write tier enabled.

## Acting on them

`update_recommendation_status` is tier 1. It marks a finding accepted, dismissed or snoozed.
That changes a ZopNight record only.

The seven tier 2 tools change scheduling behaviour: `create_schedule`, `update_schedule`,
`delete_schedule`, `attach_resource_to_schedule`, `detach_resource_from_schedule`,
`create_override`, `delete_override`.

## Why scheduling is tier 2 and stopping a resource is tier 3

They look similar and they are not. Creating a schedule changes *when* something will happen. It
is a rule, fully reversible by deleting it, and nothing has happened yet. Calling
`stop_resource` acts immediately on live infrastructure.

That distinction is why an org can enable tier 2 and let an assistant propose and wire up
schedules, while still refusing it the ability to stop anything on the spot.

## Overrides are the safety valve

`create_override` temporarily forces a resource on or off, taking precedence over its schedule
until it expires. It is the tool an assistant should reach for when someone says "keep staging
up tonight": reversible, time-boxed, and it leaves the underlying schedule intact.

## Savings figures are the rule's own

When an assistant quotes a saving from `get_recommendations`, that number comes from the rule
that produced the finding, the same figure the UI shows. Rules that cannot price a change
report no figure at all rather than a guess, so an absent number means "unpriceable", never
"zero".