Connect an AI client

Your Aerandil cell is an MCP server. Connecting an AI client to it takes the cell’s URL and your own sign-in — there is no client id to request, no secret to store, and nothing to deploy.

The token the client ends up holding is your token: it is scoped to your role on the property and expires with your shift. An AI client can never do something you could not do yourself.

What you need

• Your cell’s URL, e.g. https://cell.yourhotel.com. Your MCP endpoint is that plus /mcp.
• An Aerandil sign-in on that cell — the same one you use for Explorer or the front desk.

Claude

1. Open Settings → Connectors, press Add custom connector.
2. Paste your MCP endpoint — https://cell.yourhotel.com/mcp.
3. Leave Client ID and Client Secret empty. The cell registers the client itself.
4. Press Connect, then sign in on the Aerandil page you are sent to.
5. Recommended while you are getting your bearings: open the connector’s tool settings and require approval before any write tool runs.

ChatGPT

1. Open the plugins page and press + to open New Plugin.
2. Name: Aerandil. Connection: Server URL. MCP Server URL: https://cell.yourhotel.com/mcp. Authentication: OAuth. Leave Client ID and Client Secret empty.
3. Create it, then approve the permissions on the Aerandil sign-in page.

Anything else

Any MCP client that speaks the 2025-06-18 authorization flow works the same way: point it at https://cell.yourhotel.com/mcp and let it discover the rest. It will read /.well-known/oauth-protected-resource/mcp, follow that to /.well-known/oauth-authorization-server, register itself at /oauth/register (RFC 7591), and send you to /oauth/authorize to sign in.

What the client can do

Everything you can, and nothing more:

• Every registered action is a tool. Not a generic “write to the database” tool — check_in, post_charge, assign_room, forfeit_deposit, each with the action’s own typed input schema.
• Every object type is a resource, addressable as aerandil://object/<type>/<id>.
• The same validators, the same refusals. A tool call runs through the identical action engine a human’s click runs through: the same validation, the same permission checks, the same idempotency, and the same structured refusal when the answer is no. There is no separate agent path to drift from the one people use — so an agent cannot post a charge to a closed folio, or refund against an open chargeback, for the same reason a receptionist cannot.
• The same audit. Every action an AI client takes is an event in the log, attributed to you, with the client recorded alongside.

Scopes

The client may ask for a narrower grant than your role allows, and the cell honours it — the granted scope is always the intersection of what the client asked for, what it registered for, and what your role carries. It is never widened. If a client asks for something your role does not have, that scope is simply absent from the token; the tools needing it will refuse.

Revoking

Remove the connector in your AI client. The access token expires on its own at the end of its lifetime, and there is nothing durable to clean up — the client holds no secret and no refresh token.

For operators

Interactive authorization is on once the cell has an identity provider configured and knows its own public URL (AERANDIL_PUBLIC_BASE_URL — see the configuration reference). The cell’s /oauth/callback must also be registered as a redirect URI in the WorkOS environment the cell points at. Until both are set, /oauth/authorize answers 501 and the cell publishes no authorization-server metadata, so no client will try.