Loading ToolBench
Template for creating Model Context Protocol (MCP) servers
This is a template server with 16 tools spanning analytics, documentation, file processing, REST APIs, and SQLite. While tool names follow verb_noun conventions and most have descriptions, there are significant quality gaps: many parameter descriptions are generic or missing contextual detail, input schemas lack proper validation constraints (enums, min/max bounds), output schemas are not documented, and error handling is minimal. The analytics tools (contribution_analysis, custom_analysis) have complex workflows but lack guidance on dependencies and recovery paths. File and API tools are simple but under-specified. The documentation tools (search_documentation, fetch_documentation_page) have verbose descriptions with procedural instructions embedded, a sign the tool design itself may be forcing overly complex agent workflows. Overall, this reads as a functional template rather than production-grade tooling.
Performs statistical analysis and performance attribution on your data. Analyzes which dimensions contribute most to changes in key metrics between time periods.
Performs custom statistical analysis on your data with flexible query support.
Fetch the complete content of a specific {{service_name}} documentation page. 🚨 MANDATORY USAGE: This tool MUST be called for EVERY SINGLE relevant page identified through search_documentation. Search results only provide incomplete snippets - you need the complete page content to provide accurate, comprehensive answers. ❌ COMMON MISTAKE: Only fetching the first page from search results ✅ CORRECT APPROACH: Fetch ALL pages that appear in search results and contain relevant information WHEN TO USE: - After search_documentation identifies relevant pages - For EVERY SINGLE file path that appears relevant to the user's question - When you need complete context, definitions, examples, or detailed explanations - Before providing any detailed analysis or answers about {{service_name}} concepts EXAMPLE: If search returns both: - /docs/{{service_name}}/concepts/overview.md - /docs/{{service_name}}/api/endpoints.md You MUST fetch BOTH pages, not just one. Each may contain different essential information. The tool retrieves pages from the 'your_docs_repo' documentation repository. File paths should be relative to the repository root and typically start with '/docs/{{service_name}}/' Common page types include: - Concept guides (e.g., overview.md, architecture.md) - API documentation (endpoints.md, authentication.md) - Technical references and specifications - Process and workflow documentation REQUIRED WORKFLOW - NO SHORTCUTS: 1. First search: search_documentation("your search terms") 2. Identify ALL unique file paths from search results (not just the first one) 3. Fetch EVERY SINGLE page: fetch_documentation_page("/path/to/each/relevant/file.md") 4. Only then provide comprehensive answers based on complete documentation from ALL pages Do not skip fetching any pages - search snippets alone are insufficient for accurate analysis.
Output schemas completely undocumented for ALL tools. Agents cannot predict response structure, field names, or data types. This forces trial-and-error planning and makes downstream tool chaining fragile.
Input validation constraints missing (no enums, min/max bounds, format patterns). E.g., contribution_analysis.metric accepts free-form string (should enumerate domain metrics), get_weather_data.units has no enum, sqlite_execute_query has no SQL validation.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 49 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 35 | - | v1 |
Returns available dimensions and supported metrics for analytics. Use this to see what options are available before running analyses.
Get detailed information about a country using the REST Countries API
Get random quotes or facts from free APIs
Get current weather data from a free weather API
Read and analyze CSV file
Read and parse JSON file
Search the {{service_name}} documentation for relevant content using advanced text search. This tool performs a comprehensive full-text search across all {{service_name}} documentation files including: - Domain concepts, definitions, and business logic - Data model schemas, table structures, and field descriptions - API documentation and technical specifications - Process documentation, metrics calculations, and business rules - Best practices and implementation guides SEARCH SYNTAX & BEST PRACTICES: 1. **Simple Keywords**: Use specific terms related to your analysis - Examples: "data model", "authentication" 2. **Boolean Operators** (must be UPPERCASE): - AND: "schema AND validation" (finds documents with both terms) - OR: "API OR endpoint" (finds documents with either term) - NOT: "config NOT deprecated" (excludes documents with 'deprecated') - Parentheses: "(schema OR model) AND validation" 3. **Wildcards**: - * for multiple characters: "config*" finds config, configuration, configure - ? for single character: "set?" finds sets, setup 4. **Start Broad, Then Narrow**: Begin with general terms, then use more specific searches 🚨 CRITICAL REQUIREMENT - FETCH ALL PAGES: This search tool ONLY returns content snippets for discovery purposes. These snippets are INCOMPLETE and INSUFFICIENT for answering user questions. You MUST fetch the complete content of EVERY SINGLE relevant page using fetch_documentation_page(). ❌ NEVER answer questions based only on search snippets ✅ ALWAYS fetch ALL relevant pages before providing answers MANDATORY WORKFLOW - NO EXCEPTIONS: 1. Use this search tool to discover relevant documentation pages 2. Examine ALL search results and identify EVERY unique file path that contains relevant information 3. Call fetch_documentation_page() for EACH AND EVERY identified file path - do not skip any 4. Only after fetching ALL relevant pages, provide comprehensive answers using the complete documentation If search returns multiple pages (e.g., /concepts/overview.md AND /api/endpoints.md), you MUST fetch BOTH pages, not just one. Each page may contain different aspects of the answer. Search covers markdown files and documentation under '/docs/{{service_name}}/' by default. Results include file paths and content snippets for identifying which pages to fetch.
Create sample SQLite database with demo data
Execute SQL query against SQLite database
Get schema information for SQLite database tables
List all tables in SQLite database
Get sample data from SQLite table
Write data to CSV file
Documentation tools (search_documentation, fetch_documentation_page) have excessively long descriptions (900 - 1000 chars) with repeated procedural instructions (MANDATORY, NO EXCEPTIONS). This indicates poor tool design: if multi-page fetching is mandatory, the tool should handle orchestration internally, not force agents into complex workflows.
No error recovery guidance. Tools lack descriptions of failure modes (API timeout, not found, permission denied) and what agents should try next. E.g., get_country_info does not explain what happens if country is not found, sqlite_execute_query does not guide on SQL errors.
Parameter descriptions often generic or missing context. E.g., read_csv_file.delimiter 'CSV delimiter character' does not explain default or recommend common values; custom_analysis.parameters is a JSON string with undocumented structure.
Dangerous tool design: sqlite_execute_query accepts arbitrary SQL with no validation or confirmation step. Agents could accidentally DROP TABLE or corrupt data. Missing idempotent/destructive annotations and confirmation workflow.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite mix of read and write tools. MCP 2026-07-28 supports these; agents cannot distinguish safe vs destructive operations.
Tool composition issues: get_random_content uses a single tool for 4 content types (quote, fact, joke, advice). Should split into separate tools (get_quote, get_fact, get_joke, get_advice) so agents can request specific content without guessing the right content_type value.
Inconsistent parameter naming and type handling. E.g., sqlite tools accept database_path as optional with undocumented default; read_csv_file.encoding lacks default; no 'user-friendly identifier' patterns (e.g., country param in get_country_info should accept both name and code, but format is ambiguous).