MCP workflows

For saved Cloud Guardian data, choose the organization explicitly and request infrastructure changes separately. Immediate Vercel billing uses your local CLI login and does not require Cloud Guardian sign-in. The plugin's setup and cloud-costs skills guide these workflows; you can also ask Codex to call the individual tools.

Review existing cloud costs

After signing in and choosing an organization, use a prompt such as:

Review existing costs for organization YOUR_ORG_ID. Show the largest
cost drivers, stale observations, and incomplete pricing. Explain
the evidence before suggesting changes.

Use the project filter where supported to focus on a provider project or account. Keep billing evidence, scanner estimates, free-tier credits, and incomplete estimates distinct. Missing prices do not establish that a resource is free.

The native cg_overview_app entrypoint opens immediately and reads complete data in the background. Full responses are cached for 30 seconds per sign-in session and organization. The app can show a snapshot up to five minutes old while updating, with its load time displayed; project search and pagination keep large inventories responsive. For an explicit refresh of saved data, call cg_open_overview with org_id and refresh: true, or choose Refresh. A refresh waits for a new saved-data read and does not trigger a provider scan.

Explore Vercel costs immediately

MCP runtime 0.1.2 uses your current local Vercel CLI login to read billing. Install or update the Vercel CLI, then run:

vercel login
vercel whoami

vercel login signs you in through Vercel. No project linking, deployment, Cloud Guardian session, connector, or scan is needed for the cost explorer. Your Vercel team role must permit billing access.

Call cg_explore_vercel_costs with a team slug or ID. Omit dates to use the current billing period:

{ "team": "YOUR_TEAM_SLUG_OR_ID" }

Or supply both dates for a custom period:

{
  "team": "YOUR_TEAM_SLUG_OR_ID",
  "from_date": "2026-09-01",
  "to_date": "2026-09-30"
}

The dates must be ordered and span at most 365 days. Vercel CLI date filters include the selected calendar dates in America/Los_Angeles; the returned period timestamps define the actual window. See the Vercel usage reference.

The result separates billed and effective costs in USD, includes project and service breakdowns, and reports the period, observation time, and warnings. Current-period charges are provisional. These period costs stay separate from Cloud Guardian's resource monthly run-rate and saved scan history. In the native overview, provide a team and choose Explore Vercel costs; opening the view makes no automatic Vercel request.

If the host cannot find the CLI, set VERCEL_CLI_BINARY to its absolute executable path in the MCP host's environment and restart the connection. Keep Vercel's CLI OAuth credentials under the CLI's control; do not copy them into a backend connector or chat.

Persistent Vercel onboarding

For saved Vercel inventory and billing, request a persistent Cloud Guardian connection. Immediate CLI exploration above works independently. Opening or refreshing the overview and querying CLI costs do not create connectors or trigger provider scans. Persistent onboarding uses the following explicit account and credential scope:

1. Sign in to Cloud Guardian and choose the explicit destination org_id.
2. Use the Vercel team ID beginning team_. Persistent onboarding requires this ID rather than a slug.
3. For a new connector, create a dedicated Vercel API token for the team. Prefer CLOUD_GUARDIAN_VERCEL_TOKEN in the MCP host's environment; cg_onboard_vercel also accepts an optional api_token. Reusing a matching connector does not require a new token. Keep secrets out of chat and do not reuse the CLI's OAuth session.
4. Call cg_onboard_vercel with org_id, team_id, and optional name. It reuses an existing matching connector. A new connector preflights access, encrypts the dedicated token, links the team account, and tests it.
5. Check the returned connector ID, reuse status, and test result. The scheduled first scan records billing charges and links projects; successful credential testing does not mean those observations have arrived.
6. Once observations are saved, call cg_query_provider_billing with that org_id, provider: "vercel", and returned connector_id. Vercel's billing API reference describes its period-based charge data.

For a specifically requested fresh scan, target this team account through cg_trigger_scan's current provider filter:

{
  "org_id": "YOUR_ORG_ID",
  "gcp_project_id": "vercel:team_YOUR_TEAM_ID"
}

Keep this filter: omitting it requests a broader organization scan. Vercel connection and cost review do not enable workload remediation.

Connect a provider

Local plugin setup signs you in and reads Cloud Guardian data. Connecting a provider authorizes new access and can provision credentials or cloud roles. Completing guided onboarding can also start an initial scan.

Ask for a specific provider, project or account, and organization:

Help me connect GCP project my-project to organization YOUR_ORG_ID.
Show the access and setup steps before creating cloud credentials.
Leave automatic remediation disabled.

Confirm the destination organization before authorizing provider setup. The web Connectors wizard and guided MCP onboarding currently use a default organization. For a specific organization, prefer a provider onboarding tool that accepts an explicit org_id. Review the tool parameters:

• cg_onboarding_start returns a guided link for AWS, GCP, or DigitalOcean; cg_onboarding_status checks its completion. This tool currently has no org_id parameter and uses the server's default organization, so verify that default before starting. For another organization, use an organization-scoped provider onboarding tool.
• cg_onboard_gcp_project requires gcp_project_id and org_id, and uses local gcloud to create a service account, grant roles, generate its key, and link the project.
• cg_onboard_aws requires account_id and org_id. Its optional provision: "true" creates scanner credentials using local AWS credentials; review that action before requesting it.
• Other provider onboarding tools have their own credential and scope requirements. Use the reference for the selected provider rather than copying another provider's parameters.

After connecting, check cg_list_org_projects and cg_get_project_status in the chosen organization. The initial or scheduled scan supplies saved observations. If you want a fresh scan, explicitly request cg_trigger_scan with org_id and, where applicable, gcp_project_id.

Enabling remediation scopes or auto_remediation_scopes changes what the service can do after scans. Leave those settings unchanged during connection unless you have specifically requested them. Existing automated policies remain active on projects where they were already enabled.

Review and execute a remediation

Choose cloud-guardian:cloud-costs in the Codex skills picker, or invoke $cloud-guardian:cloud-costs. Request a specific organization and resource:

For organization YOUR_ORG_ID, investigate this violation. Explain
the proposed change, expected savings, and operational impact.
Ask me to approve the specific action before execution.

1. Read cg_get_infrastructure_status and cg_list_remediation_actions with the explicit org_id.
2. If a new plan is needed, request cg_plan_remediation with that organization and any project or resource filter. Planning scans for violations and creates pending actions.
3. Review the returned action ID, change, estimated savings, and execution mode.
4. Validate the selected action with a dry run:

{
  "org_id": "YOUR_ORG_ID",
  "action_id": "ACTION_ID_TO_REVIEW",
  "dry_run": "true"
}

1. After authorizing that action, call cg_execute_remediation with the same org_id and action_id, omitting dry_run to execute.
2. Review the action result and subsequent observations. Use cg_get_savings_summary to distinguish reported savings from projections.

The current tool schema represents dry_run as the string "true". The action parameter is action_id. The optional force_direct: "true" bypasses GitHub PR execution mode and should only be used when direct cloud API execution has been specifically requested.

For a batch, review every selected action first. cg_batch_execute_remediation requires action_ids as a comma-separated list and accepts dry_run: "true"; supply the exact reviewed IDs and explicit organization rather than executing an unspecified set of pending actions.

Check freshness and operational health

Read cg_get_operational_health and cg_list_scan_logs for scan status and recent failures. A successful login does not establish that every provider connection is working or every resource has complete pricing. Check the saved observation time and provider evidence before relying on a total.

See the tools reference for available parameters and authentication guide for account or connection problems.