MCP server

https://boot.techdyn.co.uk/mcp

Quick start

Pick your client. Everything except ChatGPT authenticates with an API key from Account → API Keys; ChatGPT signs in instead.

claude mcp add --transport http boot \
  https://boot.techdyn.co.uk/mcp \
  --header "Authorization: Bearer boot_YOUR_KEY"

{
  "mcpServers": {
    "boot": {
      "type": "http",
      "url": "https://boot.techdyn.co.uk/mcp",
      "headers": {
        "Authorization": "Bearer boot_YOUR_KEY"
      }
    }
  }
}

{
  "servers": {
    "boot": {
      "type": "http",
      "url": "https://boot.techdyn.co.uk/mcp",
      "headers": {
        "Authorization": "Bearer boot_YOUR_KEY"
      }
    }
  }
}

[mcp_servers.boot]
url = "https://boot.techdyn.co.uk/mcp"
http_headers = { Authorization = "Bearer boot_YOUR_KEY" }

# List the tools your key can use
curl -s -X POST https://boot.techdyn.co.uk/mcp \
  -H "Authorization: Bearer boot_YOUR_KEY" \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","id":1,"method":"tools/list"}'

# Or drive it interactively
npx @modelcontextprotocol/inspector

Scopes

A credential sees only the tools its scopes cover, and calling a tool it lacks the scope for is refused outright — hiding a tool from the listing is presentation, refusing the call is the actual control.

Connecting ChatGPT

ChatGPT only ever presents an OAuth bearer token — it cannot send an API key — so Boot acts as an OAuth 2.1 authorization server for it. There is nothing to configure beyond the endpoint URL.

Authorization code with PKCE S256 (required; plain is refused), client identification by Client ID Metadata Document so there is no registration step, access tokens valid one hour, refresh tokens valid thirty days and rotated on every use.

An unauthenticated call to the endpoint answers 401 with a WWW-Authenticate header naming the first of these, which is how a client that has never seen Boot finds its way in.

Disconnecting

Account → Connected applications → Disconnect all applications cuts off every OAuth application at once, including access tokens already issued — they stop working immediately rather than running out their hour. API keys are separate; revoke those under API Keys.

Tools

Generated from the server's own catalogue, so this is exactly what your agent will see.

What an agent cannot do

• Anything that needs the browser. 23 Sentinel tools drive the in-app chat panel — page navigation, the interactive day and block proposal cards, the tab modal, text-to-speech, and the client-side transcript. There is no browser on the other end of an MCP call. show_project and show_task render cards; their data is available as get_project and get_task.
• Read or write Boot's memory. 5 memory tools exist in the app and are deliberately not exposed here. You already have a memory of your own, and two stores with no rule about which one owns a fact end with your guesses read back as Boot's context. The /api/agent/memories REST routes are unchanged if you genuinely need them.
• Touch another account. Every tool runs as the credential's owner.
• Escape a plan limit. Project and task limits apply exactly as in the app.
• Administer Boot. No site settings, users, plans or billing.

Limits

A batch counts once per tools/call it contains, so batching buys no extra allowance. Responses carry X-RateLimit-Limit and X-RateLimit-Remaining; a 429 carries Retry-After.

Troubleshooting

Driving the REST API directly instead? See the API reference.