Loading ToolBench
AI-native platform for automatically generating and hosting Model Context Protocol (MCP) servers. Provides generation pipeline, marketplace, hosting orchestration, and MCP server gateway.
This MCP server presents a specialized meta-tool use case, it orchestrates the generation and hosting of OTHER MCP servers. The tool definitions are well-structured with consistent naming conventions (verb_noun), comprehensive descriptions (most 150-400 chars), and properly typed input schemas. All 9 tools have non-empty descriptions and parameter type declarations. However, there are notable gaps in output schema documentation, missing parameter descriptions in some tools, and a lack of explicit error recovery guidance. The server implements reasonable composition patterns (each tool has a single clear responsibility) and manages a complex stateful workflow (generation conversations, deployments). Security considerations are addressed via credentialRefs preference and quota enforcement. The definitions are production-grade for an internal platform but fall short of A-tier due to incomplete output documentation and limited error categorization.
Forwards a call to a tool on one of your own hosted servers and returns that tool's result. The target server must be running; this does not start it for you. No generation quota or AI cost is involved.
Sends a follow-up message into an existing generation conversation - most commonly an answer to a clarifying question returned by generate_mcp_server or a previous continue_generation call. Applies the same quota and pipeline logic as a new message typed into the chat UI.
Starts generating a new MCP server from a natural-language description, using the same GenerationPipeline the chat UI drives (intent analysis, research, tool planning, clarification, and a Docker-sandboxed generate-test-refine loop). COST NOTE: this consumes one unit of the caller's monthly generation quota and incurs real AI inference cost (research + planning + up to 5 refinement iterations). Confirm with your user before calling this tool. Quota limits are enforced server-side regardless. If the pipeline needs more information it returns a clarifying question instead of code - reply to it with continue_generation.
Fetches the generated code artifacts (main file, supporting files, package.json, documentation, and the tool list) for a completed generation. Returns a "not ready" message if the conversation has no generated server yet.
Output schemas not documented for any tool. The rubric requires documented return types and structured responses; callers cannot know what fields to expect (e.g., does get_generation_status return 'paused'|'pending'|'complete', and what fields? does get_generated_server return file contents inline or URLs?). This forces LLMs to infer structure and risks parsing errors.
list_conversations has no input schema description. The tool takes no required parameters, but the description does not explain what fields are returned (conversation IDs? creation dates? current status? tool list?). The enum/object structure for the response is invisible to the LLM.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | A | 82 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 30 | - | v1 |
Reports the current state of a generation conversation: whether it is paused awaiting a clarifying answer, whether a generated server is available yet, and the most recent messages.
Deploys a server you previously generated (identified by its conversationId) onto the platform's cluster, so its tools become reachable through this same connection with search_tools / call_tool - no separate endpoint or client needed. The conversation must already contain a completed generated server (run generate_mcp_server first). COST NOTE: this provisions real infrastructure and consumes one slot against your tier's concurrent hosted-server limit (the free tier hosts a single server). Confirm with your user before calling it. ASYNC NOTE: it returns as soon as the deployment is accepted, with a status like "pending" or "deploying"; a cold start (fetch source, install, compile, come up) typically takes about a minute. Poll get_hosted_server with the returned serverId until it reports ready before calling its tools. SECRETS: prefer credentialRefs over envVars for anything sensitive - it references a secret already stored in your vault instead of putting the secret's raw value in deployment.
Lists the authenticated user's generation conversations, most recent first.
Searches the public MCP Everything marketplace of previously generated, published MCP servers. Read-only and free of charge - no quota or AI cost involved.
Searches the tools of your own hosted servers, so a single connection can reach all of them. It reads each server's stored tool definitions, which means it still works when a server is stopped. Read-only and free of charge, with no quota or AI cost. Use it to find a tool, then run one of the results with call_tool. Note that the free tier hosts a single server.
search_marketplace and search_tools descriptions lack guidance on when to use pagination. Both accept optional 'query' and 'limit' parameters. Descriptions do not document what happens when results exceed the limit, whether offset/cursor is supported, or how to retrieve the next batch. This breaks the pattern:paginated-result expectation.
Error handling guidance is minimal. Tools document quota/cost notes (e.g., 'consumes one unit of monthly generation quota') but do not guide recovery. What should an LLM do if quota is exhausted? If a generation hits an error mid-pipeline? If a deployment fails? Descriptions lack actionable recovery steps per pattern:recovery-guide.
call_tool description does not document what happens if a parameter is required by the target tool but omitted from the 'arguments' object. Should the tool return an error? Should the agent retry with the required param? The response schema is opaque, is it the raw tool output, or wrapped in {success, data, error}?
Parameter dependency documentation is incomplete. 'continue_generation' requires conversationId to be an active, paused generation (not one that is complete or failed). 'get_generated_server' silently returns 'not ready' if invoked on an incomplete conversation. These preconditions should be explicit in parameter descriptions per pattern:param-relationships.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint) are declared in the schema. The Risk field (WRITE vs READ_ONLY) is present in the source but not exposed in the tool definition. LLMs cannot determine idempotency or destructiveness from the name alone (e.g., 'continue_generation' and 'call_tool' have WRITE risk but descriptions do not flag them as non-idempotent).
Stateful workflow complexity is not self-documenting. generate_mcp_server may return a conversationId with status 'paused', requiring a follow-up continue_generation call. If an agent omits the conversationId or calls get_generated_server before the pipeline completes, silent failures result ('not ready' message). The tool descriptions do not guide the intended call sequence or state machine.