set up myaise by chatting with claude

What you get #

Three guarantees hold across every tool on the MCP server, not just the ones this guide walks through:

• Configure everything by chat. Workspace settings, environments, your app's MCP connection, embed keys, webhooks, and the assistant's knowledge are all tools Claude can call — the same context functions the dashboard's own forms call, with the same validation and the same owner/member and plan-tier rules.
• Secrets never enter the chat. A tool that needs a secret (a static API token) or that mints one shown once (a webhook signing secret, an HS256 embed secret) returns a one-time secure link to a small myaise.com page instead. It works once, for the signed-in user who asked for it, for 15 minutes, and Claude never sees the value.
• Destructive changes ask first. Deleting an environment, revoking a key, disconnecting OAuth — anything irreversible or hard to undo returns a plain-language summary and a confirm token on the first call. Nothing changes until a second call repeats that token.

Connect #

Any MCP client that supports OAuth can connect. No API key to mint first.

Claude Code #

claude mcp add --transport http myaise https://myaise.com/mcp

Then run /mcp inside Claude Code and choose myaise to authenticate. It opens your browser to sign in.

Claude.ai and Claude Desktop #

Open Settings → Connectors, choose Add custom connector, and enter https://myaise.com/mcp.

The sign-in and consent screen #

Sign in with GitHub or Google if you aren't already. The consent page then asks two things:

• Workspace. Pick which workspace the client may act in — a personal account or one of your teams (only workspaces on a plan with API access show up as available).
• Permissions. A checklist of scopes, each with a plain description. A client that asks for no specific scopes gets a sensible default set pre-checked (read/write on content and sessions) — tick workspace:manage yourself if you want Claude to change settings, create environments, manage embed keys, or manage webhooks; it is not pre-checked by default.

Approve, and the client receives a one-hour access token plus a refresh token it renews itself. The connection shows up under Dashboard → API keys → Connected apps, where you (or the workspace owner) can revoke it at any time.

Verify #

Ask Claude to show the workspace it connected to:

That calls workspace.get (scope workspace:read, no arguments) and returns the workspace id, name, slug, kind (personal or team), your role, a plan/tier summary, and seat usage. If it comes back empty or errors, the connection didn't land on the workspace you expected — reconnect and pick the right one on the consent screen.

Environments #

A workspace has one implicit production environment plus up to four named extras (five total), the same way Stripe separates test and live. They live inside one workspace — not separate workspaces, not separate billing.

What's scoped per environment

• the connection to your app's MCP server;
• embed keys;
• webhooks.

What's shared across every environment

• assistant settings, the knowledge base, MCP hints, demos and projects;
• credits and billing;
• end users and their credit allowances (end-user OAuth grants are keyed by the endpoint host, so a development grant and a production grant for the same person never collide).

The tools

Create a development environment to work through the rest of this guide:

{"name": "development"}

Point the assistant at your app's MCP server #

This is the connection the assistant uses to read and act on your signed-in customers' live data — what /docs/mcp calls "Connect MyAISE." Set it once per environment.

• Development needs a public tunnel to your local app (ngrok or similar) — MyAISE's cloud calls your MCP server over the internet, so http://localhost:3000 on its own is never reachable. Keep the tunnel running while you test; if it restarts with a new URL, update the connection.
• Production uses your app's real, stable MCP URL.

Credential sources

• oauth (recommended). MyAISE performs standard OAuth 2.1 against your app's own authorization server and stores the tokens server-side, refreshing them itself.
• static_token. The connection tool never accepts the token itself in chat — it saves everything else and returns a one-time secure link where you paste the token in your browser. A status tool reports when it's been entered.

app_ref is just an optional display label for the app this connection points at (e.g. "myapp-dev") — it shows up in the connections list and in confirm summaries, nothing more.

Set it, per environment

{
  "environment": "development",
  "endpoint_url": "https://YOUR-TUNNEL.ngrok-free.app/mcp",
  "credential_source": "oauth",
  "app_ref": "myapp-dev"
}

For OAuth, follow with customer_app.connection.oauth.start (environment: development) — it returns a one-time link; open it signed in to MyAISE as yourself, continue to your app, sign in and approve. Then poll customer_app.connection.get (environment: development) until oauth_status is connected.

For a static token, pass credential_source: static_token instead of oauth; the response carries the secure link.

Repeat for production with environment: production (or omit environment entirely — it defaults to production) and your app's real URL.

See every environment at once

customer_app.connections.list returns one row per environment: environment name, endpoint host, credential source, app_ref, and OAuth status. customer_app.probes.preview / .run / .get (also take an optional environment, defaulting to production) run a safe synthetic check of the connection against your app's own test account before you trust it in a demo.

Embed keys, per environment #

An embed key (myaise_pub_...) is what goes in your product's own page to mount the assistant widget. Keys belong to one environment, and the widget's environment follows the key that started it — so a development key never talks to your production connection.

Domains and signing

• Domains are the only origins allowed to use the key. Development typically wants localhost (wildcards like *.example.com work too); production wants your real domain(s).
• Signing mode: none needs nothing extra; ed25519 (recommended) takes your Ed25519 public key, so there's no shared secret for MyAISE to hold; hs256 generates a signing secret MyAISE reveals once through a secure link. Signing mode can't change in place — create a new key and revoke the old one to switch.

{
  "environment": "development",
  "domains": ["localhost"],
  "signing_mode": "ed25519",
  "public_key": "<base64 of your 32-byte Ed25519 public key>"
}

The install snippet

One tag, on any page of your product:

<script src="https://myaise.com/embed/v1/assistant-widget.js"
        data-myaise-key="myaise_pub_xxx"></script>

Point the development key's snippet at your dev/staging page and the production key's snippet at your production page — never the same key on both, since there's no fallback across environments.

JWT mode and the kid

For a tighter setup, mint a short-lived signed JWT server-side instead of exposing the bare key, and pass it as data-jwt (or jwtRefresh if you call window.MyAISE directly). Required claims: iss, aud=myaise.embed, typ=embed_access, sub, kid in the JWT header (the embed key's id from embed_keys.create), origin, team_id, jti, exp at most 5 minutes out. Identify the signed-in end user with the optional end_user_ref claim — never sub — and optionally context and the per-user credit claims (credit_allowance, credit_period, credit_period_key).

End-user "Connect to your app" #

Separate from the operator connection in Section 05: this is a button in the widget that lets each of your signed-in users connect their own account at your app, so the assistant answers from and acts on their own data, not a shared service account.

What your app's OAuth server needs

• Dynamic client registration (RFC 7591) at a registration endpoint your authorization-server metadata advertises. MyAISE self-registers one client per end-user connection the first time someone connects, and reuses it after.
• Protected resource metadata (RFC 9728, /.well-known/oauth-protected-resource) and authorization server metadata (RFC 8414, /.well-known/oauth-authorization-server) advertising PKCE S256.
• No Cross-Origin-Opener-Policy: same-origin on your sign-in / authorize pages. The flow runs in a popup, and the callback posts a one-time claim back to the widget's window via window.opener — a strict COOP on your side (or on the page embedding the widget) breaks that handoff. same-origin-allow-popups or unsafe-none both work.

Full protocol details — the popup/claim handshake, token lifetimes, audience pinning — are in the MCP integration guide's authorization section.

Testing it in development

Point your development environment's operator connection (Section 05) at your tunneled app, and run your app's authorization server through the same tunnel so MyAISE's cloud can reach both it and the registration endpoint. Open the widget on a page using your development embed key with a signed JWT (end_user_ref set — "Connect" needs a known end user), click Connect, and sign in at your app through the popup.

Webhooks, per environment #

Webhooks are scoped to an environment too, so a development listener never receives production traffic.

{
  "environment": "development",
  "url": "https://YOUR-TUNNEL.ngrok-free.app/webhooks/myaise",
  "events": ["session.created", "session.ended"]
}

The response's secret link opens a one-time page that reveals the signing secret — it never appears in chat. Use webhooks.secret_link.status to confirm it was revealed, and webhooks.test to send a synthetic event once your handler is listening.

Assistant knowledge #

MCP hints and Assist settings are shared across every environment — there's one assistant, one knowledge base, regardless of which environment a given conversation is tagged with.

• assist.mcp_hints.get / assist.mcp_hints.set — a free-text guide (up to 4000 characters) injected into every assistant answer, describing your MCP server's tool naming, common workflows, and quirks the model should know about.
• assist.settings.get / assist.settings.update — the assistant's name, instructions, theme, website-integration session limits and credit budgets, per-end-user embed credit defaults, and the support-mining switch. Partial update: pass only what you're changing.

Go-live checklist #

Everything below is in the production environment (omit environment, or pass "production" explicitly):

1. A production connection pointing at your app's real URL — customer_app.connection.get or customer_app.connections.list, oauth_status connected (or a static token set).
2. A production embed key scoped to your real domain(s) — embed_keys.list, check environment is production and the domains are right.
3. Production webhooks, active and pointed at your real handler — webhooks.list, check environment is production and active is true.
4. A test conversation against the production widget — load the page carrying your production embed key and actually chat with it.
5. Usage filtered to production — usage.summary with environment set to production, to confirm turns are landing where you expect.

Troubleshooting #

If something fails in a way that looks like our own infrastructure (an edge-network error unrelated to anything above), that's on us — it isn't something to work around on your end. Retry, and if it keeps happening, email hello@myaise.com.

Example prompts #

Paste these into Claude Code (or any connected client) once you're signed in:

• “Show me my MyAISE workspace.”
• “Create a development environment.”
• “Point the development environment at my app's MCP server at https://YOUR-TUNNEL.ngrok-free.app/mcp using OAuth, then start the OAuth connection and tell me when it's connected.”
• “Create an Ed25519 embed key for development scoped to localhost, and give me the install snippet.”
• “Create a production embed key scoped to app.example.com and show me its id.”
• “Set up a development webhook for session.created and session.ended pointed at my tunnel, and get me the signing secret.”
• “Update our MCP hints to explain that our tool names are object.operation, like campaign.create.”
• “Walk through the go-live checklist for production and tell me what's missing.”