Loading ToolBench
Discover cross-domain innovation opportunities through dual similarity analysis using LSA (Structural Similarity) and BERT (Semantic Similarity) with sequential thinking and advanced validation
The server demonstrates domain expertise with sophisticated NLP/ML algorithms but suffers from significant quality gaps that prevent production readiness. Tool definitions exist but lack rigor: most descriptions are present but underspecify expected behaviors, parameter schemas are incomplete (e.g., 'structured_input' in initialize_discovery is typed as Dict[str, Any] with no schema validation), and error handling is minimal. The server maintains state across tools (discovery_sessions dict), violating stateless design principles. Tool names are action-driven (initialize_, collect_, preprocess_, calculate_, identify_, validate_, generate_, export_, get_, list_, clear_) which is good, but the tool chain assumes sequential execution order without explicit dependency documentation. No parameter validation, no enum constraints, no pagination support for potentially large result sets (papers, search results). Output schemas are not documented in the source. STDIO-only transport prevents remote accessibility and caps the protocol score.
Calculate BERT semantic similarity matrix for meaning and context similarity.
Calculate Latent Semantic Analysis (LSA) similarity matrix for structural/method similarity.
Clear and remove a discovery session from memory.
Collect papers using Scopus API.
Collect papers using Tavily web search.
Export complete discovery session data including all matrices, thinking logs, and results.
Generate comprehensive innovation discovery report with visualizations.
initialize_discovery accepts 'structured_input' as Dict[str, Any] with no schema validation. The docstring describes the expected structure (challenge, domains with label/concepts/methods/problems/terminology, constraints, metadata) but there is no Pydantic model, JSON Schema, or runtime validation. LLMs cannot infer the correct nested structure and will likely pass malformed dicts.
No output schemas documented for any tool. The source code lacks response type annotations or example return structures. LLMs cannot plan chained calls (e.g., which fields from collect_papers_tavily feed into preprocess_papers) without documented outputs.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 42 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 0 | - | v1 |
Get current status and progress of a discovery session.
Identify reverse salients: papers with high LSA (structural similarity) but low BERT (semantic difference) indicating innovation potential.
Initialize Mindrian Reverse Salient Discovery session.
List all active discovery sessions with their current status.
Load papers from a CSV file for analysis.
Preprocess collected papers: tokenize, remove stopwords, normalize, and extract features.
Validate innovation opportunities through patent analysis, startup ecosystem, and citation networks.
Stateful design with global discovery_sessions dict violates MCP stateless request model. Each tool assumes a session persists across calls; if the server crashes or restarts, all sessions are lost. Session_id is passed as parameter but state is mutable, making tools non-idempotent and harder to reason about.
No error handling or recovery guidance. If a Tavily/Scopus API call fails, times out, or rate-limits, the tool will likely raise an unhandled exception. No error message tells the LLM what to do next (retry, use different source, skip papers, etc.).
collect_papers_tavily and collect_papers_scopus both return potentially large result sets (up to 500+ papers per query) with no pagination support. A single query can blow the context window. No limit enforcement or next_cursor pattern documented.
Tool dependencies are implicit and undocumented. The tool chain assumes sequential execution: initialize_discovery → collect_papers_* → preprocess_papers → calculate_lsa_similarity + calculate_bert_similarity → identify_reverse_salients → validate_opportunities → generate_report. If an LLM calls tools out of order (e.g., preprocess_papers before collect_papers), it will fail silently or with cryptic KeyError on missing session data.
No parameter validation or enum constraints. For example, 'format' in generate_report is described as 'json, markdown, or html' but is typed as str with no enum. LLMs will frequently pass invalid formats like 'JSON', 'Markdown', 'pdf', etc., causing runtime errors.
No idempotency guarantees. clear_session deletes state without a dry-run or confirmation step. If an LLM accidentally calls it twice or with the wrong session_id, it silently succeeds the second time and the user loses data. Destructive tools should require confirmation.
API credentials (Tavily key, Scopus API key, BERT model path) are not shown as parameters. Code likely expects them from environment variables (python-dotenv in requirements.txt), which is good practice. However, there is no documentation of required env vars or how to configure them.
ThinkingLogger is used to generate sequential thinking logs but there is no clear way for the LLM to access or retrieve these logs within a tool call. The thinking logs are stored in session.thinking_logs but no tool exposes them to the user. This breaks the transparency goal stated in the server instructions.