Loading ToolBench
A Model Context Protocol (MCP) server that provides access to Kernel platform tools for managing apps, authentication, automation, and browser-based operations
The Kernel MCP server exposes 30 tools (per tool-names.ts) but only 3 are documented in the provided source: manage_apps, open_auth_login, and begin_auth_login. Tool schemas are present but descriptions are verbose and contain implementation guidance that should be in docs, not LLM-facing descriptions. Naming follows verb_noun convention (good), but parameter schemas lack proper type constraints (most are string with optional flags rather than constrained enums where appropriate). No evidence of output schemas documented in source. Critical issue: 27 of 30 tools are listed in KERNEL_MCP_TOOL_NAMES but have no definitions visible, these cannot be evaluated. The three documented tools have some quality but fall short of production baseline.
Start or resume the secure managed-auth flow after the App user clicks Continue.
Manage Kernel apps when an agent needs to discover deployed app actions, invoke an app, or inspect deployment/invocation state. Use "list_apps" before invoking an unknown app. "invoke" starts an action asynchronously and returns an invocation_id immediately. Use "list_invocation_browsers" with that ID to discover browser sessions created by the invocation, and use "get_invocation" after a short delay to inspect its state. Do not poll indefinitely; if the invocation is still running, report its ID. Use get/list actions to inspect results and "delete_deployment" to remove a deployment.
Open Kernel's secure interactive login panel so the user can enter credentials and MFA without exposing them to the conversation. Use this when a user directly asks to log in/sign in, or after a protected browser task discovers authentication is needed and the user consents. A direct request to log in is already consent; do not ask again. First list manage_auth_connections for the exact domain across all pages. Reuse an authenticated connection, ask the user to choose only when multiple relevant accounts exist, or call this tool with mode="reauth" and connection_id for an existing connection that needs authentication. If none exists, call with mode="new_login", domain, and a concise stable profile_name derived from the service (for example "hacker-news") unless the user supplied one; do not ask solely for a profile name. Replay recording and default operational browser telemetry are enabled unless explicitly disabled with record_session=false or browser_telemetry={enabled:false}. This launcher never creates or starts a flow—the App does that only after the user clicks Continue. Immediately follow the returned next_action, repeat its read-only wait while pending, then resume the original task using the authenticated profile_name. Never ask for passwords, credentials, OTPs, or MFA values in chat.
27 tools listed in KERNEL_MCP_TOOL_NAMES but no definitions visible in source code. Cannot evaluate schema quality, descriptions, or parameter validation for: browser_curl, computer_action, exec_command, execute_playwright_code, get_connection_context, get_more_tools, manage_api_keys, manage_auth_connections, manage_browser_pools, manage_browsers, manage_config_registry, manage_credential_providers, manage_credentials, manage_extensions, manage_profiles, manage_projects, manage_proxies, manage_replays, manage_vault_cards, manage_vault_credentials, manage_vault_items, manage_vault_provider_configs, manage_vault_wallets, manage_vaults, search_docs, submit_feedback, webmcp.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 64 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 0 | - | v1 |
manage_apps description is 500+ characters, contains implementation guidance ('Do not poll indefinitely', 'Use get/list actions') better placed in documentation, and lacks clear WHEN to use this tool vs alternatives. Violates baseline of 194 chars avg and 1024 max for LLM clarity.
open_auth_login description is 600+ characters, mixes UI/UX narrative ('call this tool with mode="reauth" and connection_id') with business logic, and contains example parameter values. Descriptions should be LLM-optimized prompts, not implementation narratives.
manage_apps 'action' parameter is an enum with 7 values but parameter descriptions use parenthetical notation ('(list_apps, invoke, list_deployments)') to document which actions use which sub-parameters. This coupling is implicit and forces LLMs to parse text; should be modeled explicitly with separate tools or sub-operation enums.
Parameters 'payload' (manage_apps.invoke) and 'browser_telemetry' (open_auth_login/begin_auth_login) are typed as string or object but lack format/structure documentation. 'payload' is noted as 'JSON string' but LLMs struggle with serialization; should accept typed object. 'browser_telemetry' lacks schema of nested properties.
No output schemas documented for any of the three tools. Baselines require 100% of A+ tools have documented return types. Agents cannot plan downstream calls or extract IDs without knowing what fields are returned.
manage_apps lacks error guidance. What happens if invoke returns immediately with invocation_id but the invocation fails asynchronously? How should the LLM detect this? No recovery guidance provided.
open_auth_login and begin_auth_login descriptions assume deep product knowledge ('managed-auth flow', 'profile_name'). New agents will not understand the workflow. Descriptions should stand alone.