Connect an AI assistant

Connect a client

Every client connects with the same URL. The first request it makes is refused with a pointer to the sign-in server, which is how a client discovers where to send you — so no key, client id or configuration file beyond the URL is needed.

{{ORIGIN}}/mcp

claude mcp add --transport http fresnel {{ORIGIN}}/mcp

{
  "mcpServers": {
    "fresnel": { "url": "{{ORIGIN}}/mcp" }
  }
}

{
  "servers": {
    "fresnel": { "type": "http", "url": "{{ORIGIN}}/mcp" }
  }
}

In Claude's desktop and web apps, add a custom connector and paste the URL. Any other client that supports remote MCP servers over HTTP works the same way: wherever it asks for a server URL, give it the one above.

Sign in and choose access

1. Your client opens a browser window on the platform's sign-in page. Sign in as you normally would.
2. A consent screen lists what the client is asking for, each scope ticked. Untick anything you do not want it to have. Reading your devices, sessions and models is always included; everything that changes something is a separate scope.
3. Approve, and the client is connected. It receives a token for the MCP endpoint only — that token is refused by the REST API, just as an API token is refused here.

readalways

See the organizations you belong to, your devices, sessions, models and deployments.

capturescope

Create projects, start and stop captures, and label sessions.

devicesscope

Register, claim and configure devices and pools.

trainscope

Train, delete and manage models and pipelines.

deployscope

Deploy models and activate deployments.

inferencescope

Run deployed models over your sessions.

org:adminscope

Manage organization members, invitations and ownership.

A scope is a ceiling, not a bypass: the assistant acts as you, with your role in each organization and the device claims you hold. If a tool needs a scope you did not grant, the assistant is told which one, and you can reconnect to grant it — see troubleshooting.

What the assistant can do

When it connects, the assistant is told how the pipeline fits together — register, claim, capture, label, train, deploy — so it can plan a request before it acts. These are its tools:

whoamiread

Your account, the organizations you can act in with your role in each, and the scopes this connection was granted.

list_devicesread

Devices and pools you can see, each device's status, and whether you hold its claim.

list_sessionsread

Recorded and live sessions in an organization, newest first.

get_sessionread

One session in full: status, configuration, sample count, label and analysis.

list_modelsread

Trained and training models in an organization.

get_modelread

One model in full — polled until training settles.

list_deploymentsread

Model deployments in an organization.

create_projectcapture

Create a project to hold sessions.

register_devicedevices

Register a board plugged into a pool, by its port.

claim_devicedevices

Claim a device for your captures and configuration.

release_devicedevices

Release a device you hold.

recover_devicedevices

Reset a board that is present but no longer answering. Asks for confirmation.

start_capturecapture

Start a capture on devices you have claimed. Returns the session id.

stop_capturecapture

Stop a running capture.

set_session_occupancycapture

Label a session with how many people were present.

activate_deploymentdeploy

Make a deployment the active one for its project. Asks for confirmation.

run_commandby command

Any other pipeline command by name — training, deploying and testing models, labelling, device setup. Needs the scope of the command it sends.

Captures and training run in the background. The assistant starts them, gets an id back, and checks on them with get_session or get_model — so a long capture never depends on one connection staying open.

Example requests

Describe the outcome; the assistant works out the steps. A few that map directly onto the tools above:

• Which boards are online in my pool, and which of them do I hold?
• Claim the four boards in my pool and start a ten-minute capture — one transmitter, three receivers.
• Label each of today's sessions with how many people were in the room.
• Run the same capture in each of my rooms, one after another.
• Train a presence model on this week's labelled sessions and tell me when it finishes.
• Has the presence model finished training? If it has, deploy it.

Clients without a browser sign-in

A client that cannot open a browser — a CI job, a headless agent — can send a personal access token instead. Create one under Integrations in the app, tick the scopes it needs, and copy it; it is shown once. Its scopes apply here exactly as they do on the REST API.

claude mcp add --transport http fresnel {{ORIGIN}}/mcp \
  --header "Authorization: Bearer <your token>"

Other clients take the same Authorization: Bearer header wherever they let you set request headers for a server.

Disconnecting and security

• Disconnect any time. Every client you approved is listed under Integrations → Connected apps in the app. Disconnecting stops its tokens immediately; revoking a personal access token there does the same.
• Your browser session is never used. The endpoint reads only the Authorization header, so a web page you visit while signed in cannot drive it with your cookie.
• The same rules as the app. Every change goes through the same checks as the app and the REST API — your role, the organization, who holds a device's claim. The assistant cannot do anything you could not.

Troubleshooting