/platform-headless-360-integrate

name: platform-headless-360-integrate
description: "Read org state and change Setup through the Headless 360 (H360) MCP tools discover, describe, dispatch_readonly, and dispatch. Use when H360 tools are present and the answer is org state no skill or sf command reads: Setup settings, feature or license access, org-specific caps, health checks, release updates. Also H360 setup and errors (401, 403, 404, ROUTE_NOT_FOUND, INVALID_ARGUMENT). DO NOT TRIGGER for records, SOQL, schema, limits in sf org list limits, deploys, or which-plugin questions."
metadata:
  domains: ["Platform"]
  mcpTools:
    # Salesforce-hosted server. The plugin can bundle it as salesforce-headless-360,
    # or the user registers it under a name of their choice. The two give different
    # tool prefixes, so Step 1 resolves the prefix at runtime instead of naming
    # tools in allowed-tools.
    headless-360:
      tools: ["describe", "discover", "dispatch", "dispatch_readonly"]
      semver: ">=1.0.0"
  cliTools:
    - tool: ["python3"]
      semver: ">=3.9"
    - tool: ["sf"]
      semver: ">=2.0.0"
  relatedSkills:
    - "platform-capability-search"
    - "platform-data-manage"
    - "platform-soql-query"
    - "platform-lsp-integrate"

Using the Headless 360 MCP Server

The **Headless 360 (H360) MCP server** is a Salesforce-hosted MCP server. It exposes an org's REST and Connect APIs, plus Setup-page operations that have no public API, through four tools: search a corpus of operations and recipes, read one's contract, and call it. This skill is the **contract** for those tools: when to reach for them, how to call them, how to keep writes safe, and how to read their errors. It also covers setup when the server isn't connected.

H360 may expose task-specific recipes in its catalog. Use `discover` to find a candidate and `describe` to inspect its current steps and inputs before calling it; don't rely on remembered or copied recipe details.

> This is not the plugin's capability discovery (`/salesforce-development:discover`, > "what could help me do X?"). That is `platform-capability-search`.

When to Use This Skill

• The user asks about org state that Setup shows and no skill or `sf` command

reads: a setting or preference, whether a feature or license is available, an org-specific cap, security or health posture, or pending release updates. For example: "Is event log generation on?", "Do we have Field Audit Trail?", or "Which release updates are due?"

• A skill or `sf` command answers only part of a question, and the rest is org

state like the above.

• The user asks how to set up or use the H360 MCP server, or what its tools do.
• An H360 call failed and you need the cause and the fix (see Errors).
• You're writing or reviewing a skill that calls H360 and need the call pattern.

Where H360 Fits

The plugin routes work to skills first, then the `sf` CLI, then direct API calls. H360 is the direct-API tier:

1. An installed skill matches the task: use it. For example, record changes go to `platform-data-manage`, SOQL to `platform-soql-query`, and deploys to `platform-metadata-deploy`. 2. A purpose-built `sf` command does the job: use the CLI. For example, `sf org list limits` reports storage and daily API requests. 3. Otherwise, use H360 and follow this skill.

**Never fill an org-specific value from documentation.** An org's caps and settings can differ from the documented defaults: one org's field history cap was 200, not the documented 20. When a skill or command answers only part of a question, get the rest from H360 with `discover`. If H360 can't read it either, say the value is unverified and where in Setup the user can check it.

If H360 isn't connected or is disabled and the user doesn't want to set it up, `sf api request rest` can send the same REST call using the CLI's org login. It can't reach `/headless/invoke/...` paths; they return `404` there. The write rules in Step 5 still apply.

Step 1 — Find the Tools

The four tool names end in `discover`, `describe`, `dispatch_readonly`, and `dispatch`. Their prefix depends on how the server was added.

• **Bundled with the plugin:** find the registered `salesforce-headless-360`

server and use its four tools. Tool prefixes vary by host. This server signs in as the project's target org (`sf config get target-org`), so there's no `/mcp` sign-in. On Claude Code, enable **Headless 360 MCP server** in the plugin settings. On Codex, use the saved local opt-in below; CLI and desktop can then start normally. The setting defaults off on both hosts. When enabled, start in a Salesforce DX project with a target org, and activate H360 in that org (Setup, step 1). The project's `.sf/mcp-health/headless-360.json` records the last connection result.

• **Registered by hand:** the tools are `mcp__<name>__<tool>`, where `<name>`

is the registration name, such as `headless-360`. Use the host's tool search (ToolSearch on Claude Code) for `discover describe dispatch dispatch_readonly` and reuse the prefix of the server that has all four.

• **No H360 tools:** check whether the bundled server is disabled. If enabled,

confirm the session restarted after the setting changed, the project has a target org, and the server is activated in that org. Otherwise follow Setup below.

• **More than one H360 server:** each server may use a different org. Run the

version and Organization reads in Step 2 against each registration, show the server names and orgs, then ask which one to use. Use only that server for the rest of the task. Never write until the selected org is confirmed.

In this skill, `discover` means `<prefix>discover`, and so on. Use the field names from each tool's input schema. Query parameters go in `queryParams`, never in the `url`.

Step 2 — Confirm the API Version and the Org

Every call runs as the signed-in user, in the org that issued the session's token. You never pass an org ID. Before the first write