Skip to main content

​
Vend a token

Thin wrapper around Better Auth’s getAccessToken(). This is the legacy entry point used by the stdio runtime; the HTTP MCP transport calls resolveToken() directly (see below). Success response (200):
Error responses:

​
resolveToken() — three-source resolution

Inside the HTTP MCP transport (apps/server/src/routes/mcp-remote.ts), every plugin handler’s ctx.auth.getToken("<provider>") runs through resolveToken(userId, provider) which checks three sources in order:
  1. tool_connections row for the user with tool_id = <provider>. If present, decrypt and return the stored secret. This is how dashboard-managed API keys (granola personal/enterprise) and any future per-user tokens work.
  2. Better Auth getAccessToken({ providerId, userId }). Returns the OAuth access token (auto-refreshing if expired). Covers the social providers (github/google/slack/linear) and Generic OAuth providers (quickbooks/gcp/docusign/carta).
  3. process.env["${UPPER(provider).replace(/-/g, "_")}_API_KEY"]. Falls back to a server-wide env var. This is how the built-in tools (attio, browserbase, firecrawl, perplexity) get their keys without per-user storage.
If all three miss, resolveToken() throws No credentials for "<provider>". Connect it in the Toolshed dashboard. — surfaced to the agent verbatim by call_tool.

​
Plugin perspective

Plugin handlers don’t need to know which source supplies the token. They just call:
For OAuth tokens the plugin receives a Bearer access token; for API keys it receives the raw key string. The plugin’s job is to put it in the correct header for the upstream API.