Scout docs
Connect an agent, make your first call, and find the reference you need.
Authentication
Choose OAuth for interactive work or a token for unattended jobs.
For an interactive MCP client, start with OAuth. The browser extension uses the AI provider key in its settings.
When to use MCP tokens
Use browser-based OAuth for normal interactive setup. Switch to access-token authentication only when your client cannot complete the sign-in flow or when you need non-interactive automation.
- Prefer OAuth discovery for local development and everyday IDE use.
- Use a Scout MCP token only for CI, scheduled jobs, or MCP clients without browser-based OAuth.
- Keep the token scoped to the narrowest environment you can tolerate, ideally development or staging.
- Revoke the token when the integration or job no longer needs it.
CI and headless automation
For CI or headless automation, attach a Scout MCP token as the Authorization header. This keeps the transport the same while bypassing browser-based login.
- Generate a Scout MCP token from the Scout account UI or token management flow.
- Store it in your CI secret store instead of committing it to the repo.
- Inject it into the MCP client config as a Bearer header at runtime.
- Rotate or revoke it after the automation job, especially for temporary workflows.
Programmatic MCP clients
Programmatic MCP callers can also use a Scout MCP token when they cannot complete OAuth. The auth shape is the same once the request reaches Scout: a userId plus derived workerId, with tokenId included for token-based access.
- Use OAuth-derived MCP tokens when you can.
- Fall back to a Scout MCP token only when browser sign-in is impossible.
- Keep the token in environment variables or your secret manager.
- Verify the connection with listTools() before starting a long-running job.