Loading ToolBench
Official Scalekit Node SDK for managing tools, connected accounts, and SSO authentication. Provides client libraries for listing and executing tools.
This is a Scalekit Node SDK, a client library, NOT an MCP server. The code provided shows TypeScript SDK exports for calling Scalekit APIs (listTools, listScopedTools, listAvailableTools, searchTools, executeTool), but there is NO evidence of MCP server registration, tool definitions via MCP protocol, or MCP transport implementation. The tools are inferred from SDK method signatures and descriptions, not from explicit MCP tool registration. Per hard scoring rules, when tool definitions are inferred rather than directly visible, cap per-tool scores at 50. The descriptions provided are detailed and clear (100-200 chars range, well-aligned with baseline), and parameter schemas are visible with type definitions. However, without explicit MCP server code, output schemas are not documented, error handling guidance is absent from the tool definitions, and the lack of MCP transport means this cannot function as an MCP server. Score reflects: good naming (verb-noun patterns for list_, search_, execute_), detailed parameter descriptions, but inferred tool definitions and missing protocol implementation.
Executes a tool using credentials from a connected account. You can either reference the connected account directly via connectedAccountId, or identify it using a combination of identifier, connector, organizationId, and userId.
Lists tools that are available for a specific connected account identifier. Similar to listScopedTools but returns the tools that can be made available for a given identifier, rather than the tools that are already scoped to it.
Lists tools that are scoped to a specific connected account identifier. Returns tools that are already scoped to the given identifier.
Lists tools available in your workspace with optional filtering and pagination. Supports filtering by provider, identifier, toolName, summary, query, connector, organizationId, userId, and connectedAccountId. Use query to do a text search across tool metadata. Use connector with identifier to resolve a specific connected account and include its custom MCP tools. Use connectedAccountId as a direct alternative to identifier + connector combination.
Searches tools ranked by relevance to a natural-language query — the job to be done, not an exact tool name. Each result's score is a relevance score where higher is better; it is only comparable within the results of a single response, not across separate calls. Pass identifier to also get per-connection readiness (usable now, needs a new connection, or needs re-auth) on each result's connections.
This is an SDK client library, not an MCP server. No MCP protocol implementation is present in the source code provided. Tool definitions are inferred from SDK method signatures, not registered via MCP's CallTool or ListTools mechanisms.
Output schemas are not documented. Tool descriptions explain inputs but do not specify what fields will be returned, what structure the response takes, or pagination behavior. LLMs cannot plan downstream tool calls without knowing the response schema.
Error handling guidance is absent. Tool descriptions do not explain what errors can occur, how to interpret them, or what the LLM should do when a call fails (retry, ask user, choose alternative tool). This prevents agents from recovering gracefully.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 38 | 2026-07-28+ | v2 |
No tool annotations (readOnlyHint, destructiveHint, idempotentHint) are present. While listTools, listScopedTools, listAvailableTools, and searchTools are marked READ_ONLY in metadata, executeTool is marked WRITE but no destructiveHint annotation exists in the MCP definition (because there is no MCP definition).
Parameter 'query' in listTools lacks constraint documentation. Description says '3-100 characters' and 'searches global tools only', but no min/max length constraints are formalized in the schema, and the restriction to 'global tools only' is under-explained (what are non-global tools?).
Parameter dependencies are under-documented. executeTool accepts both (identifier + connector + organizationId + userId) AND connectedAccountId as mutually exclusive paths, but this dependency and the resolution logic are not clearly stated in parameter descriptions. LLMs may pass both or neither.
listTools pagination is described as accepting 'pageToken' and 'pageSize', but total count and how to detect end-of-results is not specified. Without a total_count or has_more flag, agents cannot reason about pagination bounds.