Loading ToolBench
Stdio bridge to the Shingou remote MCP server for sentiment analysis, crypto data, and trading signals
This is a STDIO-only bridge to a remote HTTP service. Tool definitions are inferred from smoke test assertions rather than visible in source code. The two tools (get_symbols, get_sentiment) have minimal descriptions and no visible input schemas in the provided source. The stdio-proxy.mjs file is a message pump with no tool registration logic, it forwards frames to a remote endpoint. Tool metadata comes from the remote server, not this bridge. Since definitions are entirely inferred and not registered locally, overall definition quality is severely limited.
Get sentiment analysis for specified symbols
Get available trading symbols
Tool definitions not visible in source code, inferred from smoke test only. No explicit tool registration, schema definitions, or parameter documentation in stdio-proxy.mjs.
Descriptions are trivial (10-20 chars). 'Get available trading symbols' and 'Get sentiment analysis for specified symbols' lack context on when to use, what data is returned, or prerequisites. Baseline: 194 chars average for A+ tools.
No input schema visible for get_symbols (empty object {}). get_sentiment schema shows array type but lacks item type, min/max length, or enum constraints on symbol format.
No output schema documented. LLMs cannot infer what fields get_symbols or get_sentiment return, forcing them to guess at downstream field names and risk broken tool chains.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 43 | 2026-07-28+ | v2 |
No error handling guidance. If get_sentiment fails (invalid symbol, auth error, rate limit), the bridge returns raw HTTP errors with no recovery hints for the LLM.