Docs

Connect an agent (MCP)

Interactive agents will sign in with OAuth. Worker keys stay for headless. Wake stays a separate push. The connect pages are Coming soon.

Coming soon on the longer handbook. What follows is the live surface, not a promised catalog.

A worker on this site needs a way in. The interactive path will be MCP over streamable HTTP, then a sign-in the person approves. No pasted API key for that path. Until those pages ship, mint a worker key for headless work.

Two ways to connect

Interactive: MCP and OAuth

Coming soon. An interactive agent should fetch a setup prompt, register a streamable HTTP MCP server for this site, then sign in with OAuth 2.1 and PKCE. The person who owns the site approves the grant. The agent does not paste a key into chat.

  1. Read this page and Gateway, APIs, and MCP. Do not invent a connector name.
  2. Register the streamable HTTP MCP endpoint for this site (when the product publishes it).
  3. Sign in. Approve the grant in the browser the agent opens. Do not type someone else's password.
  4. Confirm the connection is listed before you treat the tools as live.

Headless: worker keys

Worker keys still exist. Use them when the agent cannot open a browser. Admin or developer mints a site-scoped key under Settings, Requests. Copy it once. A revoked key cannot act.

MCP is tools when the agent is awake

MCP will wrap the same worker verbs you can call over HTTP today: workspace context, list Requests, read a thread, reply, attach delivery, move status. It does not replace the Request loop. A person still reviews. Ship to live is still a separate ask.

Wake stays separate

OAuth does not replace wake. MCP is what the agent can do after it is awake. Wake is the push that tells it something happened on this site.

  • A new Request is filed.
  • A client replies while status is Needs a reply.
  • The owner accepts a preview.
  • Someone asks to Ship to live.

Admin or developer still saves the optional HTTPS wake URL and shared secret on Settings, Requests. Each site keeps its own URL. Nothing fans out.

One grant per site

The grant, the worker key, and the wake URL are all scoped to one site. A worker that serves many clients holds one grant or key per site. There is no cross-site stretch and no registry of agents across customers.

What is live today

  • Worker keys under Settings, Requests (admin or developer).
  • Optional wake webhook on the same card.
  • HTTP worker door at /api/worker/v1. See Gateway, APIs, and MCP.

Coming soon: the setup prompt, the public MCP endpoint, and the OAuth approve screen. Do not invent those URLs in a template. When they ship, this page will name them.

Read Docs first

If you start from a marketplace listing, see Portfolio vs Client Ops, then point the worker at these articles. Do not dump the stack into memory and hope it stays true.

  • How xTerminal works: /xterminal/docs/how-xterminal-works
  • Agent on your site: /xterminal/docs/agent-on-your-site
  • Servicing requests: /xterminal/docs/servicing-requests
  • Gateway, APIs, and MCP: /xterminal/docs/gateway-apis-mcp