Loading ToolBench
Chrome extension that captures and routes authentication credentials (cookies, bearer tokens, session data) from web applications to a native host, which writes them to files in configurable formats for use by MCP servers and other tools.
MCP Auth Bridge is a Chrome extension with 15 tools, but most lack proper MCP-style schemas and descriptions. Tools are inferred from JavaScript function implementations rather than explicitly registered with JSON Schema. Descriptions exist but are often vague or implementation-focused rather than LLM-optimized. Input schemas are partially visible in code comments but not formally declared. No output schemas documented. Error handling is minimal. The server conflates browser extension APIs with MCP tool patterns, creating a mismatch between what LLMs expect and what the tools deliver.
Collects cookies from configured domains for a site, validates required cookies, filters to specific cookies if configured, and sends them to the native host in either cookie_editor or cookie_jar format.
Captures Front application session data including httpOnly cookies (front.id, front.id.sig, front.csrf), derives cell, company, and workspace_subdomain from page context via same-origin API calls, and saves the session with a user-provided label to support multi-account scenarios.
Checks if a request URL matches token patterns and extracts bearer tokens from Authorization headers (JWT tokens starting with eyJ).
Extracts access_token and refresh_token from response bodies (typically OAuth token endpoints).
Matches a hostname against configured sites in SITES config, handling domain variations (with/without www, with/without leading dot, subdomain matching).
Copies captured credentials as JSON to the clipboard for diagnostic purposes, supporting all capture methods (cookies, bearer tokens, Front sessions).
No formal JSON Schema registration. Tools are inferred from JavaScript function signatures, not explicitly registered with MCP-compliant input/output schemas. LLMs cannot reliably determine parameter types, constraints, or expected outputs.
Missing output schemas. No documented return types or field structures. LLMs cannot plan downstream tool calls or extract required data (e.g., does captureCookies return cookie_count, domain, nativeResponse as separate fields or nested?).
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 33 | 2026-07-28+ | v2 |
Handles the Save button click for a site: collects credentials (cookies, bearer tokens, or Front session), validates them, prompts for Front session label if needed, and sends to the native host for writing.
Writes a bearer token and arbitrary extra fields to a flat JSON file for MCP servers that need credentials on startup. Each site's extra_fields map flows through verbatim as top-level keys.
Writes captured cookies to a JSON file in Cookie-Editor format: full cookie objects with domain, expirationDate, httpOnly, secure, sameSite, etc.
Writes captured cookies to a JSON file in cookie_jar format: {cookies: {name: value}, domain, captured_at}
Writes bearer tokens and extra fields to a .env file with configurable variable mapping, preserving existing values not being updated. Optionally writes a companion JSON credential file for live-reload by MCP servers.
Upserts one labeled Front session into a multi-label JSON file at ~/.mcp-credentials/front-sessions.json. Each save updates exactly one label and leaves others untouched, enabling coexistence of multiple Front workspace sessions.
Loads sites.json from the Chrome extension bundle and caches it in the SITES global variable.
Posts a message to the window containing captured token data (access_token, refresh_token, extra fields) for relay to the background worker.
Dynamically renders site cards in the popup UI based on sites.json configuration, displaying capture method, status, and last capture time for each site.
Vague descriptions. Many tools have descriptions that explain implementation details (e.g., 'Collects cookies from configured domains') rather than LLM-optimized guidance on WHEN to use them and WHAT they return. Descriptions lack actionable context for agent selection.
Inconsistent naming conventions. Tools mix verb_noun (captureCookies, captureFrontSession) with handle_* (handle_cookie_jar, handle_dotenv) and generic names (renderSites, handleSave). LLMs struggle to infer intent from inconsistent patterns.
No error handling guidance. Tools return success/error objects but do not guide LLMs on recovery (e.g., 'No cookies found', should the agent retry, ask the user to log in, or try a different site?). Errors lack actionable next steps.