Loading ToolBench
MCP server for Blinkbox automation platform providing tools for web search, HTTP requests, data extraction, code execution, and workspace operations
This MCP server exposes 14 tools with moderate definition quality. Tool naming is reasonable (verb-based: web_search, http_request, workspace_memory, graphql_request), but several critical gaps undermine usability: 3 tools lack visible input schemas (grpc_call, gitlab, azure_devops show only partial schemas); 2 tools have descriptions under 20 characters (grpc_call: 'Call a gRPC service method'); parameter descriptions are inconsistent (some params like http_request.body lack type hints); no output schemas are documented anywhere; error handling is absent from descriptions; and composition issues exist (http_request and tool_http_request appear to duplicate functionality, as do web_search and tool_tavily/tool_google_search). Most tools (9/14) do have descriptions and basic schemas, placing this at the low end of 'Fair', too many gaps for 'Good', but not completely broken. Baseline: average tool description length is 194 chars; these average ~100-150 chars, which is acceptable but could be more detailed on WHEN to use each tool.
Perform operations on Azure DevOps
Perform operations on GitLab (list issues, create issues, update issues, comment on issues, create merge requests, merge merge requests, trigger pipelines, get project details)
Execute a GraphQL query against a GraphQL endpoint
Call a gRPC service method
Make an HTTP request to any URL or API endpoint. Supports GET, POST, PUT, PATCH, DELETE with custom headers and JSON body. Use this to call external APIs, fetch web pages, or send data to services.
Use this tool to reason step-by-step before deciding what action to take. Write your internal analysis — classify the situation, weigh options, and plan your next steps. This thought is private and has no external side effects.
grpc_call has no documented parameters or schema, only {"host", "method"} with no type hints, descriptions, or constraints.
Duplicate tools with overlapping functionality: web_search, tool_tavily, and tool_google_search all perform web search but with different schemas and no documented differences. LLMs will waste reasoning cycles choosing between them. Similarly, http_request and tool_http_request are nearly identical.
gitlab and azure_devops tools accept an 'operation' parameter as a free-form string, but the description lists them separated by commas (e.g. 'listIssues, createIssue, updateIssue'). These should be strict enums to prevent hallucinated operation names.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 48 | 2026-07-28+ | v2 |
Search Google via Custom Search API
Make any HTTP/HTTPS request to an external API or URL
Fetch latest news articles by topic using NewsAPI
Scrape text content from a web page URL
Search the web using Tavily AI search API for real-time information
Translate text to another language using LibreTranslate
Search the internet for current, real-time information. Returns titles, URLs, content snippets, and an AI-generated summary answer. Use this when you need up-to-date facts, news, or information not in your training data.
Read and write key-value data to workspace-scoped persistent memory (Redis). Use 'read' to retrieve previously stored values, 'write' to store new data, 'delete' to remove a key, or 'list' to see all stored keys. Data persists across agent executions within the same workspace.
Many tools lack output schema documentation (tool_tavily, tool_google_search, tool_news, tool_translate, tool_scraper, graphql_request, grpc_call, gitlab, azure_devops). LLMs cannot plan downstream tool calls or extract data without knowing return structure. Baseline: 100% of A+ tools have documented return types.
Descriptions for tool_tavily, tool_google_search, tool_news, tool_scraper, and tool_translate are generic and lack guidance on WHEN to use each tool. tool_tavily: 'Search the web using Tavily AI search API', why would an agent pick this over web_search? Descriptions should clarify unique benefits or trade-offs.
workspace_memory 'key' parameter is not required for 'list' operation, but the schema marks it required=["operation"]. This is correct but error-prone, should document that 'key' is ignored for 'list' or make the param conditionally required in the description.
No tool has error handling documentation. If a web_search fails due to network timeout, malformed query, or API rate limit, the description does not tell the LLM what to do next (retry, adjust params, or fail gracefully). Baseline: error responses should guide recovery.
http_request and tool_http_request both accept headers and body parameters without documenting expected formats. What type should 'body' be? Is it a JSON object that will be stringified, or a pre-serialized string? What headers are dangerous or reserved? Descriptions must clarify.