Planlock in front of Sume MCP: approve the plan, then the calls

Yes, you can put an approved-plan proxy such as Planlock between an agent and Sume's hosted MCP, because Planlock is described as a proxy in front of any MCP server and Sume's endpoint is a plain remote MCP server at https://mcp.sume.com/mcp. What the proxy adds is a human approval of the whole sequence, which Sume's own gates do not try to provide.

I read the Planlock README (read 2026-10-10) and Sume's MCP docs. I did not run Planlock against Sume, so the wiring below is a design based on what each side documents, not a tested setup.

What Planlock says it does

The README's flow is: the agent proposes a multi-step plan, a person approves it once outside the agent's reach, and then the proxy lets through only calls the plan allows. Per step it can limit which tools are allowed, constrain arguments (equality, enumerations, minimum and maximum values, length limits, wildcards), cap call counts per tool, and pin versions so a changed upstream blocks the call. It accepts connections over stdio or HTTP and is configured with environment variables such as UPSTREAM_URL.

The README does not say how the proxy forwards a Bearer header to an upstream, so check that before you rely on it with Sume's API-key sessions.

What Sume already enforces behind it

Sume's tools and gates page lists the server-side controls. Write and paid tools need an idempotency_key. dry_run=true previews admission and cost without submitting. max_spend_usd is enforced only when the caller provides it. Under OAuth, a session without mcp:write sees only read-only tools and gets insufficient_scope on the rest, and there is no mcp:paid scope.

Those gates answer "can this call run, and will it be deduplicated". They do not answer "is this the sequence a person agreed to". That second question is what an approved plan covers.

A plan worth approving

A good plan for a video job is short and has a ceiling on each step. Step one allows balance_get and a generate_video call with dry_run true. Step two, after you have read the estimate, allows exactly one generate_video with max_spend_usd no higher than the number you saw and one fresh idempotency_key. Step three allows jobs_wait and jobs_result on the returned id.

If the proxy supports a max-value check on an argument, max_spend_usd is the natural one to constrain, since Sume enforces that field itself. Whether your plan format can express a required argument is something to confirm in the README's examples.

• Allow jobs_wait, whose remote hold is at most 55 seconds per call in Sume's docs.
• Allow a second jobs_wait call. A wait that ends in wait_slice_expired is meant to be repeated with the same ids, and a plan that allows one wait call per step will block the retry.
• Do not allow a second paid create to cover a failed wait. A transport error on a wait is not a job outcome.

Where this is more than you need

If the agent only reads, an OAuth mcp:read connection already hides every write and paid tool, and a proxy adds a moving part for no gain. The proxy earns its place when the agent holds an API key, runs unattended, and a person wants to approve the shape of the run before money moves.

Sume's jobs documentation says repeated waits are the normal way to follow a long render. Build the plan around that, and a proxy that counts calls will not trip on ordinary polling.