Loading ToolBench
A remote MCP gateway that provides access to a catalog of MCP tools via HTTPS. Bridges stdio to remote MCP services through mcp-remote.
This is a remote gateway MCP server exposing 2 tools via HTTP to an upstream Pipeworx service. Both tools have minimal descriptions and lack documented output schemas. The naming is reasonable (verb_noun convention), but parameter descriptions are extremely brief and non-prescriptive. No error handling guidance is visible. The server acts as a transparent proxy, tool logic lives upstream, so the MCP server itself provides minimal implementation detail, but this also means definitions are thin and non-actionable for LLMs.
Ask Pipeworx a question to retrieve information from the knowledge base.
Get weather information for a location specified by latitude and longitude.
Tool descriptions are too brief (10-20 chars) and lack context for LLM selection. 'Ask Pipeworx a question to retrieve information from the knowledge base' (74 chars) and 'Get weather information for a location specified by latitude and longitude' (75 chars) are at the minimum baseline but do not explain WHEN to use each tool, what distinguishes them, or what the agent should expect in return.
Output schemas are not documented. The source code does not reveal what ask_pipeworx or get_weather return, field names, types, whether results are paginated, or what IDs/references are included for chaining. LLMs cannot plan downstream actions or extract results without knowing the response structure.
Parameter descriptions are minimal. 'The question to ask Pipeworx' (30 chars) and 'The latitude/longitude coordinate' (32 chars) do not specify format, range, or constraints. For latitude/longitude, valid ranges (±90, ±180) are not documented. For question, max length, character restrictions, or example topics are not mentioned.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 56 | 2026-07-28+ | v2 |
No error handling guidance. The examples show curl calls, but there is no documentation of failure modes, retry logic, or recovery suggestions. If get_weather receives invalid coordinates or ask_pipeworx times out, the LLM has no guidance on what to do next.
Tool definitions appear to be inferred from examples (examples/drug-safety.sh, examples/weather.sh) rather than directly visible in the server source code. The actual tool registration logic, parameter validation, and response formatting are delegated upstream to mcp-remote and https://gateway.pipeworx.io/mcp. This makes the MCP server itself a thin wrapper with no visibility into tool implementation.