SteleDocs
GuidesConnect your agent to Stele

Connect your agent to Stele

Stele runs an MCP server, so an AI agent such as Claude Code can work with Stele as you: get the live link to a page it just pushed, onboard a new repository, keep a site's viewer list, and manage its share link. You add the server once, sign in with your Axelerant Google account, and approve the app. After that the agent calls Stele's tools when a task needs them, without you having to paste URLs back and forth.

What you need

  • An @axelerant.com Google account. Every call the agent makes acts as you, so it can do what you can do in the portal and nothing more.
  • An MCP client that supports remote servers over HTTP with OAuth sign-in. Claude Code does; the steps below use it.
  • To onboard a repository, the Stele GitHub App has to be installed on it already, the same as when you add a site in the portal. See Getting Started.

The server address

https://stele.axelerant.tech/mcp

That is the whole configuration. There is no API key to copy: the client finds Stele's sign-in page from this address the first time it connects.

Connect Claude Code

Add the server:

claude mcp add --transport http --scope user stele https://stele.axelerant.tech/mcp

--scope user makes Stele available in every repository you open. Leave it off to add Stele to the current project only (Claude Code's default local scope). Keep the name stele, because the tools then show up as mcp__stele__resolve_links and so on, which is what the Stele skill looks for.

Then sign in. Start Claude Code, type /mcp, choose stele, and pick Authenticate. Claude Code opens your browser. You can also sign in from the shell:

claude mcp login stele

On a machine with no browser, such as a server you reach over SSH, add --no-browser. Claude Code prints the sign-in address instead; open it on your laptop, and when the browser lands on a localhost page that does not load, copy that page's full address back into Claude Code when it asks.

To check the result, run claude mcp list, or type /mcp again: stele should show as connected, with eight tools.

What the first sign-in looks like

  1. Google sign-in. If you are not already signed in to the Stele portal in that browser, you go through the usual Axelerant Google sign-in first.
  2. The consent page. Stele then asks: Allow an app from claude.ai to use Stele as you? The app is named by the host of its client ID, which Stele can check, not by the name it gives itself, which it cannot. For Claude Code that host is claude.ai, because Claude Code identifies itself with a client ID published at https://claude.ai/oauth/claude-code-client-metadata. The page also shows the email the app will act as, and where it sends you back to; for Claude Code that is a http://localhost:<port> address on your own machine.
  3. Allow. The browser hands you back to Claude Code, which is now connected.

Only click Allow if you started connecting an app just now. If this page appears when you did not, click Deny.

You should not have to sign in again for a while. Claude Code renews its access on its own, and the connection lasts as long as it is used at least once every 30 days.

claude.ai and Claude Desktop

claude.ai can connect to Stele as a custom connector. Stele's sign-in supports the registration method claude.ai uses, but nobody has tried this end to end yet, so treat it as untested and tell the Stele maintainers if it fails.

  1. In claude.ai, open Customize → Connectors.
  2. Click +, then Add custom connector.
  3. Enter https://stele.axelerant.tech/mcp as the URL. Leave the OAuth fields under Advanced settings empty.
  4. Click Add, then connect it. You sign in and approve on the same consent page as above.

On Team and Enterprise plans only an owner can add a custom connector, under Organization settings → Connectors; after that, each person connects to it themselves. A connector added in claude.ai is also available in Claude Desktop and the mobile apps.

Other MCP clients

Any client should work if it supports Streamable HTTP and OAuth client registration by a Client ID Metadata Document. Stele does not support dynamic client registration, so a client that only knows that method cannot connect.

Clients that run in a web page, such as MCP Inspector in direct mode, can call the server too: /mcp answers CORS preflights from any origin and lets the page read the sign-in challenge. It reads no cookies, so a page still needs a token from the sign-in flow.

The tools

Stele's server tells the agent when to use each tool, so you rarely name one. These are the tools, with the kind of request that leads an agent to call each.

Turns repository paths into the URLs where the site serves them, with each page's title. It is read-only.

The agent uses it after writing or changing a document, to tell you where it is live:

  • "Add the pricing analysis to commerce/, push it, and give me the link."
  • "Send me links to every page under support/technical-audit/."

A path the site's latest sync does not contain comes back as not found, never as a guess at a nearby page. That usually means the change has not been pushed, or the sync after the push has not finished; a sync takes under a minute. A path under a .stele.yml that is not valid comes back as MANIFEST_INVALID instead, naming the file and what is wrong with it, because nothing under that file's directory is published until it is fixed (see Validation). Links need Axelerant sign-in, unless the agent asks for the share token on a site whose access is "anyone with the link", which it should do only when you want a link for someone outside Axelerant. If the agent asks for the token on a site that is not open to the link, it gets an error instead of links, so it cannot hand you a link it believes is external when it needs sign-in; the error tells it to open the site to the link with set_access and ask again, which it should do only if you asked to share the site. A page under a folder whose .stele.yml sets an access: that admits no link holder comes back as FOLDER_NOT_LINK with its plain URL, since the token would not open it.

get_sync_status

Reports which commit a site serves now and how its newest sync is going. It is read-only.

The agent uses it after a push, to tell whether your change is live yet, or when a path it just pushed comes back as not found:

  • "Is my last push live on Stele yet?"
  • "Why hasn't the new proposal shown up on the site?"

It returns the commit the site is serving, with its message and when it synced, the newest sync job (waiting, running, finished or failed, with the pushed commit when a push queued it, or otherwise the commit it built once it finished), and one word for where things stand: never synced, queued, syncing, synced or failed. A failed sync is not retried and leaves the previous version of the site up; the error says why, and the next push queues a new sync.

onboard_repo

Registers a GitHub repository as a Stele site and queues its first sync. It is the MCP version of Add a repository in the portal.

The site starts internal (Axelerant sign-in only) and shows content once the first sync finishes. It fails if the Stele GitHub App cannot see the repository (someone who owns the GitHub organization has to install it), or if the slug is already taken. It can also put people on the new site's viewer list in the same call; read Viewer lists today before relying on that.

list_viewers, invite_viewers, remove_viewer

Read and change a site's viewer list: the email addresses invited to it.

list_viewers is read-only. invite_viewers only adds, and inviting someone already on the list does nothing. remove_viewer is marked destructive, so your client may ask you to confirm it.

Inviting sends nothing by itself. Ask for the people to be notified, and the agent passes notify, which emails each newly added address an invitation from you with a sign-in link to the site (the same kind of link the sign-in page issues, valid 2 hours), at most 10 people per call. Someone already on the list is not emailed again, and an Axelerant address is never emailed a link, because colleagues sign in with Google; the agent reports those separately. The same option works on onboard_repo with invites. The agent also tells you whose email could not be sent, so you can send them the site's address yourself; see Sharing & Access. On an installation without an email provider (production has one) the call is refused rather than sending nothing, and the agent will say so.

set_access, get_share_token, rotate_share_token

Manage a site's access and its share link, the URL with a token that lets someone outside Axelerant read the site without signing in.

  • "Make the Acme proposal site shareable and give me the link."
  • "The Acme deal is closed. Revoke their link and make the site internal again."
  • "Send me the share link for presales-2026-acme."

set_access sets a site's access to one of the four values in the sharing guide: restricted (only invited people), internal (everyone at Axelerant), invited (Axelerant and invited people) or link (anyone with the link), like the Access setting in the portal. Any value but link switches the share link off but keeps the token, so setting link again brings the same link back. rotate_share_token replaces the token, so the old link stops working for everyone who has it; it also sets the site's access to link. Because that opens a site that was not link before, rotating such a site needs permission to change who can open it as well as permission to rotate; on a site that is already link, rotating needs only the rotate permission. To revoke a link for good and keep the site closed, the agent rotates the token and then makes the site internal.

While a site's repository is archived on GitHub, its share link admits nobody, so get_share_token and resolve_links with includeToken fail with REPO_ARCHIVED and the other two report shareLinkActive: false.

get_share_token is the only one of the three that returns the link. The other two report what changed and never the token, so the link reaches the agent only when you ask for it. All three are marked destructive, so your client may ask you to confirm each call. The link is a secret: anyone who has it can read the whole site until it is rotated.

Viewer lists today

A site whose access is restricted, invited or link lets in the people on its viewer list once they are signed in. An internal site does not. Colleagues with access to the site's repository on GitHub are on the list already, with source github; remove_viewer refuses them with VIEWER_FROM_GITHUB, because their access is changed on GitHub (details). People outside Axelerant sign in with an emailed link, so on such a site an invite is all they need:

  • Axelerant colleagues need no invite to an internal, invited or link site: they open it with Google sign-in. A restricted site admits only the colleagues on its list, invited or from GitHub. Asking for a colleague to be notified sends them nothing; they sign in with Google.
  • People outside Axelerant open the site's address and sign in with an emailed link, or use the link in the invitation if you had them notified. The share link is for a link site only, for people you cannot name, as described in Sharing & Access; removing someone from the viewer list does not change the share token.

Invited viewers in the sharing guide explains how an invited person signs in.

What the agent may do

The agent has your Stele role, no more. Everyone at Axelerant starts as staff, which can:

  • onboard a repository, and resync any site;
  • on a site you created: invite and remove viewers, change who can open it and rotate its share link, change its branch, and archive or delete it (in the portal);
  • on any site: get links, get the share link when the site is open to the link, and read the viewer list.

A privileged role can do the site-level things on every site, and admin can do everything. A Stele admin grants those roles; see Roles.

When the agent asks for something your role does not allow, for example inviting someone to a site another person created, the tool refuses and names the missing permission, such as invite viewers to any site. Nothing is changed. Ask the site's creator, or an admin, instead.

Revoking access

Open Connected apps from the portal header, or go to https://stele.axelerant.tech/connected-apps. Each app you have allowed is listed once, by its client ID host, with when it connected and when it last used Stele.

Revoke ends every connection you have for that app, on every machine. The app's next call to Stele fails, and to use it again you connect again, including the consent page.

An app also drops off the list on its own after 30 days without use, or when Stele revokes it because one of its codes or tokens was used twice, which suggests it leaked.

Removing the server from Claude Code (claude mcp remove stele) only deletes Claude Code's copy of its access. Revoke it in the portal as well if you want Stele to stop accepting it.

Troubleshooting

  • stele shows "needs authentication". You have not signed in yet, or your access was revoked or expired. Run /mcp, choose stele, and authenticate again.
  • The browser shows "Authorization failed". The page says why. The usual cause is an old sign-in tab; start again from /mcp.
  • An agent says a page is not found right after a push. The sync has not finished. Wait a minute and ask again; the site's page in the portal shows the latest sync.
  • onboard_repo says the App cannot see the repository. Install the Stele GitHub App on the repository, or add the repository to an existing installation, then try again.
  • A tool says you do not have a permission. Your Stele role does not allow that action, and the message names the permission it needs. The agent gets the same answer the portal would give you; see What the agent may do.