Loading ToolBench
A trading agent system with MCP servers for technical analysis, news sentiment analysis, execution, and position management
This MCP server has significant definition quality issues across all three tools. Tool names lack clear action verbs (analyze_news is acceptable, but intraday_decision is vague about what decision it makes). Descriptions are present but lack clarity on when to use each tool vs alternatives, prerequisites, and return structure. Only one tool has a visible input schema with basic type information; two tools have schemas inferred from brief parameter listings but lack full JSON Schema documentation. No output schemas are documented. Error handling guidance is absent. The server conflates tools and prompts (news_agent is labeled as a 'tool' but is actually a prompt template), violating the single-responsibility principle.
Analyse le sentiment des news financières avec FinBERT. Accepte une liste d'objets news ou une chaîne JSON sérialisée. Récupère le texte via 'link' (si public), sinon fallback sur le 'title'. Déduplique par lien (ou titre si pas de lien). Batch l'inférence pour de meilleures perfs.
Performs intraday technical analysis and generates trading decisions based on technical indicators, support/resistance levels, and risk parameters
Prompt template for the News Analysis agent that calls analyze_news tool
news_agent is labeled as a 'tool' but is actually a prompt template. This conflates two distinct concepts and violates the single-responsibility principle. Prompts and tools serve different functions in MCP.
Tool naming lacks clarity about what action is performed. 'intraday_decision' does not clearly indicate what the tool does, does it decide to trade, analyze risk, or generate signals? Action verbs like 'analyze_', 'generate_', or 'calculate_' would be clearer.
No output schemas are documented for any tool. LLMs cannot plan downstream calls or extract return values without knowing the structure of responses. This violates the documented-output-schema requirement.
Input schemas are incomplete. Only 'analyze_news' shows explicit type information ('symbol': 'string'). The other two tools' schemas are partially visible but lack JSON Schema formality. Not all parameters have descriptions explaining their purpose.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 32 | <=2025-11-25 | v2 |
| 2026-03-09 | D | 52 | - | v1 |
Description for 'analyze_news' is a run-on sentence in French, lacks clarity on when to use it vs other news tools, and does not explain what output fields the LLM should expect. Baseline for good descriptions is 50-200 characters; this is ~250 characters but poorly structured.
Parameter 'interval' in 'intraday_decision' lacks an enum constraint. The description says '(e.g. 15m, 5m, 1h)' but does not formally restrict allowed values. LLMs may hallucinate invalid intervals like '2.5m' or 'daily'.
Parameter 'risk_level' in 'intraday_decision' lacks an enum constraint. Description says '(low, medium, high)' but these should be formally declared as an enum to prevent LLM hallucination.
No error handling guidance is present. Tools do not describe what errors are possible, which are retryable, or what the LLM should do if a call fails. For example, if 'analyze_news' fails to fetch a link, should the agent retry, fallback to title, or skip the item?
Tool composition issue: 'news_agent' is a prompt template that calls 'analyze_news', not an independent tool. The server mixes prompts and tools, which breaks the abstraction model. Prompts should be managed separately from tools.
No pagination or result-limiting mechanism documented for 'analyze_news', which processes lists of news items. Without limits, this could return hundreds of items and exhaust LLM context.