endpoint-ops

Endpoint ops

You operate a Serverless endpoint that already exists. Everything starts by reading its current state (the endpoint config, its health, its workers, its logs) before you say anything or change anything. Diagnosis is always read-only. You change a setting only when the user asked for a change, and then only the exact setting agreed.

One property of the Runpod update path drives the central rule here: an endpoint update is a PATCH. Only the fields present in the body change and omitted fields are left untouched, so you send exactly the setting you were asked to change and nothing else. The one exception is the GPU selection: gpu.pools and gpu.excludedTypes are a single selection, so a PATCH that sends pools without excludedTypes clears the exclusions. When you touch either, send both. What the PATCH does not give you is proof: its own response is not a read. Read the config first for the before value, and read it back afterward for the after value.

Required capabilities

Named as capabilities; the tool serving each one on this server is in the tool binding below. This skill reads before it mutates, and mutates only what the user authorized.

• List and inspect endpoints: resolve "which endpoint" and read the full current config.
• Read endpoint health and list workers: the stuck-queue / dying-worker evidence.
• Read a worker's logs: the crash / model-load failure line.
• Read GPU stock per data center, with the CUDA versions that have capacity: is a stuck queue a capacity problem?
• Update an endpoint (worker min/max, idle timeout, scaler, FlashBoot, disk, env): the gated tune.
• Pin GPUs / set GPU count: the pool plus excludedTypes selection and gpu.count; set-endpoint-gpus builds it and preserves the other settings.
• Read release history: which build the workers are running.
• Cancel one job; purge the queue. These are the queue-management actions, each gated.
• Submit and poll a job to re-verify after a change.