ThinkWatch

ThinkWatch

English | 中文

The enterprise-grade secure gateway for AI. Secure, audit, and govern every AI API call and MCP tool invocation across your organization — from a single control plane.

Just as an SSH secure gateway is the single gateway through which all server access must flow, ThinkWatch is the single gateway through which all AI access must flow. Every model request. Every tool call. Every token. Authenticated, authorized, rate-limited, logged, and accounted for.

…

Why ThinkWatch?

As AI agents proliferate across engineering teams, organizations face a growing governance challenge:

• API keys scattered everywhere — hardcoded in .env files, shared in Slack, rotated never
• Zero visibility — who used which model, how many tokens, at what cost?
• No access control — every developer has direct access to every model and every MCP tool
• Compliance gaps — no audit trail for AI-assisted code generation or data access
• Cost surprises — monthly AI bills that nobody can explain or attribute

ThinkWatch solves all of this with a single deployment.

Key Features

AI API Gateway

• Multi-format API proxy — natively serves OpenAI Chat Completions (/v1/chat/completions), Anthropic Messages (/v1/messages), and OpenAI Responses (/v1/responses) APIs on a single port; works as a drop-in replacement for Cursor, Continue, Cline, Claude Code, and the OpenAI/Anthropic SDKs
• Multi-provider routing — OpenAI, Anthropic, Google Gemini, Azure OpenAI, AWS Bedrock, or any OpenAI-compatible endpoint
• Automatic format conversion — Anthropic Messages API, Google Gemini, Azure OpenAI, AWS Bedrock Converse API, and more, all behind a unified interface
• Provider auto-loading — active providers are loaded from the database at startup and registered in the model router; default model prefixes (gpt-/o1-/o3-/o4- for OpenAI, claude- for Anthropic, gemini- for Google) route automatically; Azure and Bedrock require explicit model registration
• Streaming SSE pass-through — zero-overhead forwarding with real-time token counting
• Virtual API keys — issue scoped tw- keys; the same tw- token works on both the AI gateway and the MCP gateway via a per-key surfaces allowlist
• API key lifecycle management — automatic rotation with grace periods, per-key inactivity timeout, expiry warnings, and background policy enforcement
• Composable rate limits & budgets — multi-window sliding limits (1m / 5m / 1h / 5h / 1d / 1w) and natural-period token budgets (daily / weekly / monthly), keyed per user, per API key, per provider, or per MCP server. See Rate limits & budgets below
• Per-model token weighting — gpt-4o tokens can count more than gpt-3.5 tokens against the same quota via configurable input_multiplier / output_multiplier
• Circuit breaker — three-state (Closed/Open/HalfOpen) circuit breaker with configurable failure threshold and recovery period
• Retry with exponential backoff — configurable retries with jitter for network errors and upstream rate limits
• Real-time cost tracking — per-model pricing with team attribution

MCP Gateway

ThinkWatch's MCP gateway is built on a single design choice that most MCP proxies skip: the upstream server sees the real end user, not a shared service account. Every other capability follows from that. See MCP Gateway: how we compare below.

• Per-user upstream identity — every MCP request carries the calling user's own OAuth token or PAT to GitHub / Notion / Linear / Slack / Atlassian / Feishu / GitLab / Cloudflare / Google / Discord / etc. Tokens are AES-256-GCM encrypted in mcp_user_credentials. Most "MCP gateways" pin one shared admin token to the server config — so the upstream's audit log shows every action as the same service account. ThinkWatch propagates real identity end to end.
• Multi-account per user — bind work and personal GitHub accounts to the same server, label them, mark one as default. The same physical user can have multiple credential rows per server.
• API-key → account override — pin different tw- keys to different upstream accounts on the same server. Your Cursor key uses your personal GitHub; the CI key uses the service-bot. One user, multiple agents, multiple identities — without re-issuing credentials.
• One-paste OAuth onboarding — paste an MCP URL, click 一键发现. The probe walks the full RFC 9728 → RFC 8414 → RFC 7591 chain: triggers WWW-Authenticate from a JSON-RPC initialize, follows the resource_metadata hint, fetches AS metadata at the path-aware well-known location, and runs Dynamic Client Registration if the upstream advertises it. When DCR isn't supported the UI shows three concrete next steps (copy callback URL → register app upstream → paste Client ID back) with no protocol jargon.
• Public-client support — detects token_endpoint_auth_methods_supported: ["none"] and propagates is_public_client end to end. The Client Secret input is hidden for issuers like Feishu that don't use one.
• Static-token vault — for upstreams that only speak PATs / API keys (GitHub PATs, Notion integration tokens). Same per-user surface, same encrypted storage, same /connections UX. Static tokens are verified at paste time so users find out immediately if the token is wrong.
• Per-user tool catalogs — when an upstream filters tool visibility by scope or role (Atlassian, enterprise IDPs), the user-authenticated tools/list is cached in mcp_user_tools and only ever returned to that user. The system-level mcp_tools catalog only stores anonymous-discoverable tools. No cross-user leakage; auth-required servers are no longer "0 tools" until someone manually fixes it.
• Three-tier upstream subject resolution — /connections shows real upstream identities (@octocat, [email protected], Slack Bob). Resolver tries JWT decode (free) → userinfo endpoint (priority-ranked extractor: preferred_username → sub → accountId → login → email) → .well-known discovery. Pre-seeded for GitHub, Notion, Slack, Atlassian, Cloudflare, GitLab, Discord, Google.
• MCP Store with 23+ curated templates — GitHub, Notion, Linear, Slack, Atlassian, Cloudflare, GitLab, Discord, Google, Feishu and more, pre-seeded with the right OAuth scopes, userinfo endpoints, and PAT help URLs. One-click install. Daily catalog refresh from the registry.
• Generic MCP client UX — for users who haven't authorized yet, the gateway still serves the tool catalog but tags every entry with _meta: { requires_user_auth: true, server_id, server_name, authorize_url }. tools/call against an unauthorized server returns JSON-RPC error code -32050 with the authorize URL, so Cursor / Claude Desktop / any compliant MCP client can prompt the user to authorize without the gateway hiding the catalog.
• Tool-level RBAC — per-role tool grants on the server side, per-key allowed_mcp_tools allowlist on the API-key side (bounded by the issuing role's grants). A locked-down service key can hold exactly two tools and nothing else.
• mcp:connect permission — gates the /connections page and authorize/revoke flow. Granted to admin / team_manager / developer by default.
• Cache scoped by (user, account_label) — MCP response cache never serves Alice's authorized response to Bob. Direct-mode (no per-user creds) servers still get global caching.
• Race-free token refresh — OAuth refresh holds a pg_advisory_xact_lock keyed by (server, user, label) so concurrent tool calls don't race two refresh attempts. Terminal refresh failure purges the row so the next call cleanly surfaces NeedsUserCredentials.
• Health probe robustness — 401/403 from an anonymous probe is expected on auth-required MCPs; the server is marked auth_required (amber), not disconnected (red). The /mcp/servers list shows "—" tool count with a hover tooltip for that state.
• Step-by-step registration wizard — auth-mode-aware edit form, per-credential Test Connection button on /connections, admin foot-gun guards (verify static tokens at paste time, no silent fall-through to default account).
• SSRF hardening — discovery and OAuth probe URLs are validated through an injected URL validator; private IP ranges, link-local, and metadata-service hosts are rejected.
• Namespace isolation — github__create_issue, postgres__query — no tool name collisions across upstreams.
• Connection pooling & health monitoring — automatic reconnection, periodic background probes, per-server health surfaced on the dashboard.
• Full audit trail — every tool invocation logged with user, account label, parameters, response, latency, and error in ClickHouse alongside the AI gateway logs.
• Rate limits + budgets apply to MCP — the same engine that meters AI tokens also meters MCP tool calls; per-user, per-API-key, per-server subjects all stack. See Rate limits & budgets.
• One key, two surfaces — the same tw- virtual key works on both /v1/chat/completions and /mcp via a per-key surfaces allowlist (ai_gateway, mcp_gateway, or both).

MCP Gateway: how we compare

Most "MCP gateways" available today are thin reverse proxies: one shared admin token per upstream, no end-user identity, and "auth" means "did this user pass the gateway's bearer token". That model works for hobby setups and breaks the moment a real organization plugs it into GitHub / Atlassian / Linear / Slack — every tool call shows up as the same service account, scopes can't differ per user, and there's no honest answer to "who renamed this Linear ticket?".

ThinkWatch is built for the second case.

If your only requirement is "expose a few public MCP servers to a small team", the simple proxies do fine. The moment you need who did what, on whose behalf, with what scopes, billed to which cost center — ThinkWatch is the design point.

Secu