Loading ToolBench
Collection of MCP server implementations demonstrating various use cases including stock market data, RAG-based document search, Dify integration, and web search
This server has 15 tools across 5 use cases (stock market, PDF search, Dify integration, web search). Most tools have basic descriptions and input schemas, but significant gaps exist: (1) Many descriptions are too generic or lack actionable context for LLM selection. (2) Parameters mostly lack type constraints (enums, ranges, patterns). (3) Output schemas are not documented, callers cannot predict return structure. (4) No error handling guidance, tools return bare dicts with error keys but no recovery hints. (5) Tool naming has minor clarity issues (e.g., two get_stock_code tools with nearly identical signatures suggest incomplete design). (6) Some descriptions under 50 chars are too terse. Based on 15 tools averaging ~40-50 per tool, the server lands in the D-to-C range (poor to fair).
Searches for information in Dify External knowledge base. Returns search results with document content, relevance scores, and source information. Use when you need to find specific information in enterprise documents, knowledge bases, or specialized content.
Executes a Dify workflow and returns the results. Automates complex AI tasks and provides immediate results. Useful for text analysis, content generation, or processing user inputs through Dify workflows.
Get investor trading trends (foreign/institutional/individual)
Get top stocks by market capitalization
Get stock code from stock name
Get stock code from stock name.
Duplicate tool definitions: Two get_stock_code tools with nearly identical signatures (both accept stock_name, return string) across case0/mcp_http_server.py and case0/mcp_stdio_stock_server.py. This violates the single-responsibility pattern and forces LLMs to reason about which variant to call.
Output schemas not documented. Tools like get_stock_price return dicts with structure like {'종목코드': ..., '날짜': ...} but no formal schema is declared. LLMs cannot plan downstream calls or extract typed fields reliably. Returns are prose descriptions only.
No error handling guidance. Tools return {'error': '...'} on failure but do not guide recovery. E.g., get_stock_price returns {'error': 'No data available for ticker ...'} with no suggestion to validate the ticker or try a different market. Per pattern:recovery-guide, errors must tell the LLM what to do next.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 55 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 43 | - | v1 |
Get historical stock price data for a period
Get current stock price information for a given ticker
Get top gaining stocks by price change rate
Get top losing stocks by price change rate
Get top stocks by trading volume
Performs hybrid search (keyword + semantic) on PDF documents. Combines exact keyword matching and semantic similarity to deliver optimal results. The most versatile search option for general questions or when unsure which search type is best.
Performs keyword-based search on PDF documents. Returns the most relevant results based on exact word/phrase matches. Ideal for finding specific terms, definitions, or exact phrases in documents.
Performs real-time web search using the Tavily API. Returns latest search results in markdown format including titles, URLs, and content summaries. Use when you need current information, recent events, or data not available in your training.
Performs semantic search on PDF documents. Finds content semantically similar to the query, delivering relevant information even without exact word matches. Best for conceptual questions, understanding themes, or when you need information related to a topic.
Parameter constraints missing. Tools like get_market_cap_ranking(market: str, top_n: int) accept free-form strings for 'market' but documentation says 'Market type (KOSPI, KOSDAQ, KONEX)', no enum constraint is visible. Unbounded top_n invites LLMs to pass absurd values (1000000) that break the API.
Vague descriptions on some tools. dify_workflow description is 'Executes a Dify workflow and returns the results.' (60 chars), lacks context for when to call it vs semantic_search or hybrid_search. Does it support all input types? What transformations does it apply? Unclear when LLM should choose it.
Date format inconsistency. get_stock_history expects 'YYYYMMDD' format, but no regex pattern or strict validation is mentioned. Other tools may expect 'YYYY-MM-DD'. This forces LLMs to guess or fail with cryptic format errors. Per pattern:param-validation-rules, expected formats must be explicit.
Pagination not addressed. Tools like get_market_cap_ranking(top_n: int) accept a limit but no offset/page parameter. If an agent needs the next 20 results, it must re-call with a different top_n, losing context. Per pattern:paginated-result, tools returning lists should support offset/limit + cursor.
Tool naming inconsistency across search tools. keyword_search, semantic_search, hybrid_search are clear, but dify_ek_search uses a brand name (Dify) and abbreviation (ek = external knowledge). If a new search backend (e.g., Pinecone) is added, naming convention breaks. Per pattern:tool-naming, names should be consistent verb_noun format.