Alter Onboarding MCP Server

Return the Alter SDK wiring (install + client init + request) to write into the developer's codebase, for a language and setup goal.

Return a runnable Alter SDK call pattern for a language: `proxy-call` (zero-egress proxy_request + HITL), `resolve-grant-by-user` (call as an end user via their delegated grant), `delegate-managed-secret` (the operator-side delegation step), or `resolve-ambiguous-grant` (an identity-mode call matched several of one user's grants: choose deliberately, never the first, and persist it; ask the developer at design time whether users can hold several accounts per provider). Use AFTER `sdk_integration` has wired the client.

Fetch any page of the Alter documentation by slug (e.g. "quickstart"). The whole published docs site is bundled here, skill pages included, so every page a doc, a skill or a flow step links to can be read in-band. Accepts any spelling the docs use: a bare slug, a leading slash, a #section anchor, a full docs.alterauth.com URL, or an older path that now redirects. Omit the slug to list every page.

Search every bundled page of the Alter documentation (docs and skill pages) by keywords: returns the best-matching pages with the section and a snippet that matched. Use it when a flow step or doc did not point you at the page you need, instead of guessing slugs or listing every page; then read one with fetch_doc and its slug.

Return the next step for a flow. Pass the goal (flow id) and the id of the last completed step (omit `after` for the first step). Run each step's detect command FIRST and skip the run command when detection passes. The design step also returns that flow's complete starter ALTER_INTEGRATION.md.

Fetch one provider API operation's full contract — method, path, parameters, request/response schemas — live from Alter's provider-spec catalog, plus the spec's source and freshness. Get operation ids from list_operations first.

List the API operations a provider exposes, live from Alter's provider-spec catalog (e.g. "what can I call on google?"). Returns operation ids + methods/paths, plus the spec's source and freshness. Omit `kind` to auto-detect the provider family; when the id exists in both oauth and managed you'll be asked to pass `kind`. Machine-readable rows ride in `structuredContent` (see this tool's outputSchema) — read those rather than parsing the prose.

List the lifecycle phases this server serves (setup, modify) and what each is for.

The authoritative grammar of Alter's runtime-policy language, live from the deployed backend: every authorable rule type with its JSON body schema, caps, authorable levels, worked examples, and fail-closed semantics. Call with no arguments for the overview; pass `rule_type` (e.g. "content_match") for one type's full grammar. Use it before authoring rules with `alter policy rules create` — never guess a body shape. Vocabulary: the dashboard's "Runtime policies" surface, the docs' "policy", and `alter policy` are one feature, and the dashboard's "Human in the loop (HITL)" type is the `require_approval` rule type (its grant-editor block is the grant-level baseline of the same gate). Workflow prose: the `set-policy` modify flow (`get_started` with phase=modify), fetch_doc("guides/set-policies"), fetch_doc("guides/add-human-in-the-loop-approvals"), and fetch_doc("reference/cli/commands/policy").

List every provider with an ingested API spec in Alter's provider-spec catalog, with each spec's source and freshness. Optionally filter by `kind`. Start here, then call list_operations for a provider's operations.

List the guidance Skills available on this server, with the phase each serves. Read a skill via its resource (skill://alter/<name>).

Begin or change an Alter integration. Without args: lists the phases. With `phase`: returns that phase's flows + a heuristic hint — classify the use case YOURSELF and call again with `goal` for the plan. If the use case spans multiple flows, run them sequentially.

Map a @alter-ai/cli exit code or error message to a remediation.

Return a copy-pasteable recipe to VERIFY an integration works: `first-call` (code↔design, an audit row, correct attribution) or `per-user-isolation` (a multi-user/broker server runs two users under different credentials and rejects cross-user access). Guidance only — you run the commands.