discover-locations

Discover Locations

Find and select the right runner location for an SLX script.

When to use

• When multiple runner locations are available and you need to choose
• When the user asks about runner locations or execution environments
• When troubleshooting a script that can't reach infrastructure
• When _resolve_location raises an error listing multiple options

Auto-resolution — you often don't need this skill

The MCP server automatically resolves the location when you omit it from run_script, run_script_and_wait, commit_slx, or deploy_registry_codebundle. The resolution strategy is:

1. If only one workspace (private) location exists → use it
2. If multiple workspace locations exist → inspect existing SLX runbook configs to pick the most-used one; if ambiguous, raise an error listing the options (you should ask the user)
3. If no workspace locations exist → fall back to the public runner

You only need this skill when auto-resolution fails (multiple ambiguous options) or when the user wants to understand or override the choice.

What locations are

Runner locations are where scripts physically execute. They are lightweight RunWhen agents installed in the user's infrastructure (Kubernetes clusters, cloud VPCs, etc.) that receive and run scripts.

Each location has:

• A name (e.g. location-01-us-west1, watcher-controlplane)
• A type: workspace (private — has access to workspace infrastructure) or public (shared runner)
• A health status: online, stale, or unknown
• Access to specific infrastructure — a workspace runner can reach the workspace's resources; the public runner has generic internet access only

Location types

Type	Meaning	When to use
workspace	Private runner with access to workspace infrastructure (k8s clusters, databases, etc.)	Scripts that need to reach internal resources — always prefer this
public	Shared public runner with generic internet access	Scripts that only need public APIs, or when no workspace runner is available