Loading ToolBench
MCP server for data science analysis design management
insight-blueprint provides 15 tools with consistent naming (verb_noun pattern) and reasonable parameter schemas. However, descriptions are generic and lack LLM-optimized guidance. Output schemas are undocumented, tools return unspecified dict structures. Error handling is minimal, with no recovery guidance or categorization. Parameter descriptions exist but lack constraints, ranges, and validation rules. Tool composition is sound (analysis design CRUD + catalog + review workflows), but parameter relationships are underdocumented. No security considerations (secret injection, permission gates, audit trails) are visible. Average tool description ~150 chars, which meets the 10-1024 baseline, but lacks the specificity (WHEN to call, prerequisites, dependencies) needed for LLM planning.
Register a new data source in the catalog.
Add a review comment to an analysis design.
Create a new analysis design document. Creates a YAML file in .insight/designs/ with 'in_review' status. theme_id must match [A-Z][A-Z0-9]* pattern (e.g., 'FP', 'TX', 'DEFAULT'). methodology: Analysis method dict with required 'method' key. Example: {"method": "OLS", "package": "statsmodels", "reason": "..."} WARNING: Should rarely be None — methodology is a core design field. Returns: dict with id, title, status, message
Retrieve an analysis design by ID. Returns the full design as a dict, or an error dict if not found.
Get cautions and warnings for specific table names.
Get all review comments for an analysis design.
Get the rules and knowledge context for analysis design.
Output schemas undocumented. All tools return 'dict' with unspecified structure. LLMs cannot plan downstream tool calls or extract fields reliably without knowing what fields are returned (e.g., create_analysis_design returns 'dict with id, title, status, message', no nested structure, type, or field ordering documented).
Descriptions lack LLM-optimized context. Generic descriptions ('Retrieve an analysis design by ID', 'Search the data catalog using full-text search') do not explain WHEN to use the tool, prerequisites, or dependencies. Missing: 'Call this after list_analysis_designs to fetch full details', 'Use to populate design fields for update_analysis_design', or 'Requires a valid design_id, use list_analysis_designs first if unknown'.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 62 | 2026-07-28+ | v2 |
Get the column schema for a data source.
List all analysis designs, optionally filtered by status. Args: status: Optional filter (in_review|revision_requested|analyzing|supported|rejected|inconclusive) Returns: dict with 'designs' list and 'count' integer
List review batches for an analysis design.
Search the data catalog using full-text search.
Submit a batch of review comments for an analysis design.
Transition an analysis design to a new status.
Partially update an existing analysis design. Only provided fields are updated. Returns the updated design as a dict, or an error dict if design_id not found. Status changes must go through transition_design_status.
Update an existing data source in the catalog.
Parameter constraints missing or under-specified. 'theme_id must match [A-Z][A-Z0-9]* pattern' is documented in create_analysis_design description, but not in a formal enum or pattern constraint. status parameters (e.g., in transition_design_status) accept '(in_review|revision_requested|analyzing|supported|rejected|inconclusive)' but lack enum definitions, LLMs cannot validate options without the explicit enum list in the schema.
Parameter descriptions are minimal. 'comment_text' in add_review_comment needs guidance on expected length, format, tone, and any rejection criteria. 'connection' in add_catalog_entry and update_catalog_entry are declared as type 'object' with no sub-field documentation, LLMs cannot construct valid connection dicts (e.g., which keys are required? Are they db_host, username, password? Or url, api_key?).
No error handling guidance. Tool descriptions do not explain error conditions, recovery steps, or categorization (retryable vs. user-fixable vs. fatal). E.g., if get_analysis_design receives an invalid design_id, the description says 'Returns... an error dict if not found' but does not say what the agent should do next (e.g., 'Try list_analysis_designs to find a valid ID').
list_analysis_designs and search_catalog lack pagination parameters. No 'limit', 'offset', 'page', or 'page_size' parameters visible. Risk: if there are 100+ designs or catalog entries, returning all of them wastes tokens and may exceed context limits. Should include limit (default 20, max 100) and offset or cursor.
Tool composition risk: create_analysis_design, update_analysis_design, and transition_design_status coordinate on status field. Descriptions do not explain the state machine or when each transition is valid. E.g., can you transition from 'rejected' back to 'in_review'? Should update_analysis_design prevent direct status changes (forcing use of transition_design_status)? Undocumented constraints cause invalid sequences.
No security patterns visible: no secret injection, permission gates, scope declarations, or audit trails. E.g., add_catalog_entry may accept 'connection' dicts with credentials, are these sanitized, encrypted, or stored securely? No documentation of who can create/modify designs or catalogs. If this server exposes sensitive data (analysis methodologies, internal data sources), access control is critical.
Parameter 'reviewed_knowledge' in add_review_comment and create_analysis_design reference a concept that is never defined. What is a 'knowledge entry'? What schema does it follow? Should this be a string ID (referencing entries in get_rules_context)? An object with structure? LLMs cannot construct valid payloads without this specification.