Alter Onboarding
Guide developers from setup through a verified, policy-aware, audited Alter API call.
От сообщества: Добавлен пользователем или импортирован; проверьте владельца перед подключениемРаботаетБез входаГлобальныйБесплатноТолько чтение
Что умеет
Какие данные видит
Нужен ли аккаунт
Не нужен: сервер работает без входа
Guide developers from setup through a verified, policy-aware, audited Alter API call.
Список инструментов сервера (13)
Технические названия из tools/list. Нужны только разработчикам.
| 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), or `delegate-managed-secret` (the operator-side delegation step). 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 a page from the bundled onboarding SUBSET of the Alter docs by slug (e.g. "quickstart"). Pages outside the subset are identified with the docs-site URL where they live (they are not missing — read them at that URL). 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 the bundled subset. |
| 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 "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"). |