Loading ToolBench
Análisis de Incidentes en Medios Sociales usando MCP - A system for analyzing cybersecurity incidents in social media using spaCy NLP, Twitter API v2, and PostgreSQL storage with automated scheduling and HTML report generation.
This MCP server has severe definition quality issues that make it unsuitable for production use. Of the 6 tools, only 2 have any input schema visible (generate_report and get_api_limits partially), and descriptions are extremely sparse. The server appears to be a custom HTTP implementation without proper tool registration schemas. Tool descriptions are minimal (10-50 chars, well below the 194-char baseline), and no parameters beyond generate_report's 'date' have documented schemas or constraints. The analyzer.py snippet shows business logic but the actual tool definitions are not visible in the provided code, only tool names and minimal descriptions are listed. This suggests tool definitions are inferred rather than explicitly registered with proper JSON Schema. The codebase uses FastAPI but tool invocation mechanics are not shown, raising questions about whether tools are properly registered according to MCP patterns.
Limpia datos antiguos manualmente.
Inicia la recolección de tweets.
Genera un informe para la fecha especificada.
Obtiene información sobre los límites de la API de Twitter.
Obtiene estadísticas generales.
Endpoint de verificación de salud.
No input schemas visible for 5 of 6 tools. Only generate_report shows a partial schema with 'date' parameter.
Descriptions are dangerously sparse. All are under 60 characters (rubric baseline is 194 chars; p10=34, p90=392). 'Endpoint de verificación de salud' (32 chars) and 'Obtiene estadísticas generales' (31 chars) provide no actionable context for LLM tool selection.
Tool definitions appear inferred rather than explicitly registered. Source code shows tool names and descriptions but no explicit Pydantic models, JSON Schema registration, or tool_call handler implementations.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 32 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 16 | - | v1 |
No parameter descriptions for any tool except generate_report's 'date' (which is minimal: 'Fecha en formato YYYY-MM-DD (opcional)'). Parameters like collect_tweets, cleanup_data, and others lack even basic descriptions of what they accept. Rubric requires ALL parameters to have descriptions.
Destructive tool 'cleanup_data' lacks confirmation/dry-run pattern. Per error-handling pattern, irreversible operations should support confirmation step to prevent accidental data loss by agents.
No error handling or recovery guidance documented. Tools provide no guidance on retryability, user-fixable vs fatal errors, or recovery steps. Rubric requires errors to tell LLM what to do next.
Output schemas not documented. No indication of what fields these tools return, their types, or structure. Rubric requires documented return types for all tools, 100% of A+ tools have them.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). Tool risk levels are listed (WRITE, READ_ONLY, DESTRUCTIVE) but not expressed as machine-readable annotations in the tool schema.
Descriptions are in Spanish only. While not a schema issue, this complicates adoption for non-Spanish-speaking teams and makes LLM instruction harder if the LLM's training is primarily English.