insight-blueprint
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| extensions | {
"io.modelcontextprotocol/ui": {}
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| create_analysis_designA | 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 |
| update_analysis_designA | 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. |
| get_analysis_designA | Retrieve an analysis design by ID. Returns the full design as a dict, or an error dict if not found. |
| list_analysis_designsA | 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 |
| add_catalog_entryC | Register a new data source in the catalog. |
| update_catalog_entryC | Update an existing data source in the catalog. |
| get_table_schemaA | Get the column schema for a data source. |
| search_catalogC | Search the data catalog using full-text search. |
| get_domain_knowledgeC | Get domain knowledge entries for a data source. |
| transition_design_statusA | Transition a design to the given target status. Valid transitions depend on the current status:
Returns: dict with design_id, status on success; {error} on failure |
| save_review_commentA | Save a review comment and transition the design status. The design must be in reviewable status (in_review or revision_requested). Valid post-review statuses: revision_requested, analyzing, supported, rejected, inconclusive. Returns: dict with comment_id, design_id, status_after, message |
| save_review_batchA | Save a batch of review comments and transition the design status. The design must be in reviewable status (in_review or revision_requested). Each comment can optionally include target_section and target_content for inline anchoring. Valid status_after values: revision_requested, analyzing, supported, rejected, inconclusive. Returns: dict with batch_id and status_after on success; {error} on failure |
| get_review_commentsA | Get review comments for a design. Returns all review batches sorted by created_at descending (newest first). Returns empty list if no reviews exist or file is corrupted. |
| extract_domain_knowledgeA | Extract domain knowledge from review comments as preview. Returns extracted entries for user review before persistence. Call save_extracted_knowledge() to persist confirmed entries. Returns: dict with design_id, entries, count, message |
| save_extracted_knowledgeA | Persist user-confirmed knowledge entries to extracted_knowledge.yaml. Call extract_domain_knowledge() first to get preview entries, then pass confirmed (optionally adjusted) entries here. Args: design_id: The design ID the entries were extracted from entries: List of dicts with keys: key, content, category, affects_columns Returns: dict with design_id, saved_entries, count, message |
| get_project_contextA | Get aggregated project context including all domain knowledge. Returns sources, knowledge entries, rules, and counts from both catalog and review-extracted knowledge. |
| suggest_cautionsA | Suggest cautions for the given table/source names. Searches all domain knowledge entries (catalog and extracted) by matching affects_columns against provided table names. Args: table_names: Comma-separated string of table/source names Returns: dict with table_names, cautions, count |
| suggest_knowledge_for_designA | Suggest knowledge entries relevant to a design section. Filters by category via SECTION_KNOWLEDGE_MAP, then applies per-category matching strategies (theme_id, source_ids, FTS5, lineage). Args: section: Design section name (e.g., hypothesis_statement, metrics) theme_id: Theme ID to match findings/context by source_ids: Comma-separated source IDs for caution/definition matching hypothesis_text: Text to search via FTS5 for methodology matching parent_id: Design ID to walk ancestor chain for finding collection Returns: dict with section, suggestions, total |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 18 tools
Most tools have clear single purposes (get vs list, create vs update), but there is overlap between transition_design_status and save_review_comment/save_review_batch, which also transition status. The suggestion tools (suggest_cautions vs suggest_knowledge_for_design) are distinct in inputs but may be confused in intent.
All tool names follow a predictable verb_noun pattern with snake_case (get_*), (create_*), (update_*), (save_*), etc. The convention is uniform and makes it easy to infer functionality.
18 tools is on the higher end but appropriate given the server covers analysis design lifecycle, catalog management, review workflows, and knowledge extraction. Each tool serves a distinct functional area, so the count feels justified rather than bloated.
Core workflows for design creation, review, and knowledge extraction are well covered. However, there are no delete operations (e.g., delete_analysis_design, delete_catalog_entry) and no direct way to add domain knowledge manually. These gaps may require workarounds in agent workflows.