Loading ToolBench
Comprehensive MCP server aggregating 40+ tool libraries covering infrastructure, cloud, data, AI, and utility domains. Includes Redis, SQL, Docker, S3, Keycloak, SSH, PDF, Playwright, and many other integrations.
This HTTP-based Spring AI MCP server exposes 9 tools across API proxying, package publishing, and tool discovery. Tool definitions are present with schemas and descriptions, but several have significant gaps: parameter descriptions are inconsistent, output schemas are undocumented, and error handling lacks recovery guidance. Tool naming is generally clear but some descriptions are thin. The server properly uses HTTP transport and tool annotations, but lacks prompts, resources, and structured output documentation. Definition quality is fair to mediocre, most tools are functional but incomplete by production standards.
Performs an HTTP GET request to an internal API. The path is relative to the configured base URL.
Checks if the configured internal API is reachable
Performs an HTTP POST request to an internal API with a JSON body
Check availability of Maven packages across local M2 cache, Gitea registry, and Maven Central. Provide pomPath to scan a pom.xml, or artifactId+version for a single check, or neither to scan all local packages of the groupId.
Publish a Maven artifact from local M2 cache to Gitea Package Registry. Uploads POM + JAR. Use overwrite=true to replace an existing version (DELETE + PUT).
MCP server test ping. Returns a fixed message.
Output schemas are completely undocumented. No tool declares what fields it returns, forcing LLMs to guess the response structure and improvise field mappings. This violates the core pattern:tool requirement that tools must document their outputs.
api_get and api_post lack error handling guidance. They return raw HTTP errors with no recovery suggestions. Per pattern:recovery-guide, errors must tell the LLM what to do next ('Try api_health first', 'Check the path parameter', etc.).
api_post accepts 'jsonBody' as a free-form string with minimal description. This invites malformed JSON and LLM hallucination. No schema validation guidance, no format constraints, no examples of valid structures.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | B | 71 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 33 | - | v1 |
Trigger publication to public registry by creating a v* tag on Gitea, which activates the release.yml CI workflow. For Maven this publishes to Maven Central.
Get the full JSON schema of a specific tool including all parameters, types, required fields, and description. Use tool_search first to find the tool name.
Search available MCP tools by query or category. Returns matching tool names and descriptions. Use this to discover tools before calling them. Categories: infra, docker, ocp, code, sql, web, devops, gitea, jira, ai, ollama, embeddings, keycloak, graph, s3, redis, ssh, csv, json, markdown, pdf, http, playwright, anki, openalex, claude, meta, auth, ops, net, context7, api, discovery.
gitea_check_registry and gitea_publish_package accept optional parameters with weak or missing descriptions. 'pomPath' has no guidance on what 'relative' means; 'groupId' default is buried in parameter description rather than Schema default. Mutually exclusive logic (pomPath vs artifactId+version vs neither) is documented in text but not enforced via schema constraints.
package_publish_public's 'dryRun' parameter defaults to false (execute immediately). Per pattern:default-values, destructive operations should NEVER default to 'execute', this invites accidental publishing. Should default to true or require explicit confirmation.
tool_search and tool_info descriptions mention 54 tool categories and exact tool examples, but no output schema documents which fields they return or what structure to expect. LLMs cannot reliably parse discovery results without knowing the schema.
Several descriptions lack WHEN guidance. E.g., mcp_ping says 'MCP server test ping' but does not explain when an LLM should call it (only for debugging/health checks, not in production flows). Per pattern:tool-description, every tool must clearly state when to use it.