Loading ToolBench
Go SDK for the Scalekit authentication and identity platform. Provides client libraries for interacting with Scalekit's gRPC-based APIs for domain, organization, connection, client, and auth management.
This is a Go SDK package, not an MCP server. The evaluation treats the 19 exported tool methods as if they were MCP tool definitions. Critical gaps: (1) No MCP transport layer detected, this appears to be a direct gRPC/Connect client library, not an MCP server. (2) Tool descriptions are present but generic (25 - 65 chars, mostly below the 50-200 char LLM-optimized range). (3) Input schemas are visible but minimal: most parameters lack type constraints, enums, min/max bounds, or detailed formatting guidance. (4) No error handling patterns visible, no recovery guidance, categorization, or actionable error messages. (5) No security patterns enforced (no permission gates, audit trails, or sensitive data warnings visible). (6) Output schemas undocumented, no return type documentation in the code. (7) Composite operations (e.g., CreateDomain + ListDomains) lack clear chaining guidance. The SDK is well-structured (clean interfaces, good code organization) but does not follow agentic tool patterns required for safe LLM integration.
Creates and adds a new secret to an OAuth client.
Creates a new OAuth client in the Scalekit system.
Creates a new connection (authentication provider) for an organization.
Creates a domain for an organization with optional domain type specification (ALLOWED_EMAIL_DOMAIN or ORGANIZATION_DOMAIN).
Deletes an OAuth client by ID.
Deletes a connection for an organization.
Deletes a domain by ID and organization ID.
Not an MCP server, this is a direct Go SDK library. No MCP transport layer (HTTP, SSE, or STDIO) detected. Code shows gRPC/Connect client wrappers, not MCP tool definitions. Cannot be integrated with MCP clients without wrapping in an MCP server harness.
Descriptions are too generic and below LLM-optimized range (50 - 200 chars). Examples: 'Creates a domain for an organization with optional domain type specification' (65 chars, good), but 'Updates login user details for the authenticated user' (52 chars, vague). Vague descriptions like 'Updates an existing OAuth client' fail to explain WHAT fields can be updated, WHEN to use it vs other update tools, or dependencies on field mask.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 42 | 2026-07-28+ | v2 |
Disables a connection for an organization.
Enables a connection for an organization.
Retrieves a specific OAuth client by ID.
Retrieves a specific connection by ID and organization ID.
Retrieves a specific domain by ID and organization ID.
Lists all OAuth clients with optional filtering.
Lists all connections for an organization.
Lists all connections available for a specific domain.
Lists domains for an organization with optional filtering by domain type and pagination.
Removes a secret from an OAuth client.
Updates an existing OAuth client with optional field mask.
Updates login user details for the authenticated user.
Input parameter schemas lack type constraints, enums, and ranges. Examples: (1) DomainType field is a string with no enum constraint, LLMs will hallucinate invalid values like 'DOMAIN_TYPE_CUSTOM'. (2) PageSize and PageNumber lack min/max bounds, LLMs could pass 1000000 and cause API abuse. (3) 'options' objects are declared as generic 'object' with minimal property details, forcing LLMs to guess valid sub-fields.
No output schemas documented. Tools return protobuf message types (CreateDomainResponse, GetDomainResponse, ListDomainResponse) but there is no specification of what fields these contain, their types, or what data is relevant to the LLM. LLMs cannot plan downstream calls or extract needed IDs if the response structure is opaque.
No error handling guidance visible. Code paths show no recovery patterns, error categorization, or actionable messages. Examples: (1) What happens if organizationId is invalid? (2) If a domain already exists, is that retryable or user-fixable? (3) Are there rate limits, and should the agent back off? Without this guidance, LLMs stall on failures.
Destructive tools (DeleteDomain, DeleteClient, RemoveClientSecret, DeleteConnection) lack confirmation/dry-run patterns. No evidence of user confirmation steps or safety gates. An agent could accidentally delete all organization domains without warning.
No permission gates or scope declarations visible. Tools like DeleteDomain and DeleteClient operate on critical resources but show no permission checks, role validation, or scope documentation (e.g., 'requires org:admin'). An unprivileged agent token could execute sensitive operations.
Tool chaining broken or undocumented. Example: CreateDomain likely returns a domain_id, but ListDomains input schema shows no way to filter by that ID (only by organizationId + optional DomainType). If an agent creates a domain and immediately wants to verify it, there's no direct retrieval by ID shown in the tool definitions. GetDomain exists but requires both id AND organizationId, the response from CreateDomain must include organizationId for chaining, but this is not documented.
UpdateLoginUserDetails description and schema are especially vague. 'Updates login user details for the authenticated user' does not specify: What fields are updatable? What is the request object structure? Are there validation rules? Without clear guidance, an LLM cannot reliably use this tool.
No idempotency guarantees documented. CreateDomain, CreateClient, and CreateConnection are write operations, are they idempotent? If an agent retries due to a timeout, will it create a duplicate? Without idempotency guarantees, agents must assume the worst and avoid retries, increasing brittleness.