Alter Onboarding

Reviewed 1d ago.

• tools: 14 tools scanned
• metadata: scanned

No findings.

Tools (14)

• list_phases

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

• list_skills

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

• get_started

  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.

• next_step

  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.

• sdk_integration

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

• sdk_pattern

  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.

• troubleshoot

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

• verify_integration

  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.

• fetch_doc

  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_docs

  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.

• list_providers

  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_operations

  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.

• get_operation_schema

  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.

• policy_language

  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 "Require human approval" type is the `require_approval` rule type (its grant-editor block is the grant-level baseline of the same gate). The same grammar is what policy files carry: `alter policy validate|test|plan|apply` review rules in Git and CI, and a rule with a `code_owner` is changed through its file, never with `rules update`. Workflow prose: the `set-policy` modify flow (`get_started` with phase=modify), fetch_doc("guides/set-policies"),