Tiling Trees MCP Server

A Model Context Protocol (MCP) server implementing the Tiling Trees Method - a systematic approach to exploring solution spaces by recursively partitioning them into mutually exclusive and collectively exhaustive (MECE) subsets.

<a href="https://glama.ai/mcp/servers/@k-chrispens/tiling-trees-mcp"> <img width="380" height="200" src="https://glama.ai/mcp/servers/@k-chrispens/tiling-trees-mcp/badge" alt="Tiling Trees Server MCP server" /> </a>

Based on the method described in The Tiling Tree Method.

What is the Tiling Trees Method?

The tiling trees method helps you systematically explore all possible solutions to a problem by:

1. Starting with the complete solution space - all possible approaches to your challenge
2. Splitting using MECE principles - divide into categories that don't overlap (Mutually Exclusive) but together cover everything (Collectively Exhaustive)
3. Recursively subdividing - continue splitting each subset until you reach concrete ideas/projects
4. Evaluating leaves - assess the viability of each concrete solution

The key insight: like tiles covering a wall completely without overlaps, your categories should partition the solution space with precision.

Why Use This Method?

• Guarantees completeness: You won't overlook viable solutions
• Forces creative thinking: Systematic exploration surfaces ideas you might not normally consider
• Enables objective comparison: All solutions emerge from the same structured process
• Identifies gaps: Missing categories become obvious
• Evolves over time: Revisit trees as technologies and contexts change

Installation

npm install
npm run build

Configuration

Add to your MCP settings file (e.g., claude_desktop_config.json):

{
  "mcpServers": {
    "tiling-trees": {
      "command": "node",
      "args": ["/path/to/tiling-trees-mcp/dist/index.js"]
    }
  }
}

Core Concepts

Tiles

Each tile represents a subset of the solution space with a precise definition to avoid overlaps with siblings.

MECE Splits

When splitting a tile, choose an attribute/dimension that creates Mutually Exclusive and Collectively Exhaustive subsets:

• Mutually Exclusive: No solution belongs to multiple categories
• Collectively Exhaustive: Every solution belongs to exactly one category

Split Attributes

The dimension used to partition (examples):

• Energy source: electric, chemical, mechanical, nuclear
• Scale: nano, micro, meso, macro
• Physical mechanism: conduction, convection, radiation
• Timeframe: immediate, short-term, long-term
• Cost: low, medium, high

Tip: Physics and math-oriented splits often work best because physical laws are concise and comprehensive.

Leaves

Terminal nodes representing concrete ideas or projects ready for evaluation.

Evaluation

Rate leaves on:

• Impact (1-10): Potential effect if successful
• Feasibility (1-10): Likelihood of success with available resources
• Uniqueness (1-10): How novel compared to existing solutions
• Timeframe: Expected development timeline

Available Tools

1. create_tree

Create a new tiling tree to explore a problem

Start by defining your challenge. The tree begins with a root tile representing all possible solutions.

{
  "name": "Transportation Decarbonization",
  "problemStatement": "How can we reduce carbon emissions in transportation by 80% by 2050?"
}

2. split_tile

Split a tile into MECE subsets (the core operation)

Choose a meaningful attribute and create categories that completely partition the parent space.

{
  "tileId": "root-tile-id",
  "splitAttribute": "Transportation mode",
  "splitRationale": "Different modes have distinct technical constraints and emission profiles",
  "subsets": [
    {
      "title": "Road vehicles",
      "description": "Cars, trucks, buses, motorcycles - vehicles operating on roads",
      "isLeaf": false
    },
    {
      "title": "Rail",
      "description": "Trains, trams, subways - vehicles on rails",
      "isLeaf": false
    },
    {
      "title": "Aviation",
      "description": "Airplanes, helicopters - atmospheric flight vehicles",
      "isLeaf": false
    },
    {
      "title": "Maritime",
      "description": "Ships, boats, ferries - water-based transport",
      "isLeaf": false
    }
  ]
}

3. mark_mece

Validate that a split is truly MECE

After creating a split, verify completeness and exclusivity.

{
  "tileId": "parent-tile-id",
  "isMECE": true,
  "coverageNotes": "Covers all major transportation modes. Edge cases like cable cars fall under 'Rail'. Space transport excluded as not relevant to 2050 target."
}

4. add_tiles_to_split

Add missing categories to an existing split

When you realize a category was missed, add it (invalidates MECE status).

{
  "parentId": "parent-tile-id",
  "newTiles": [
    {
      "title": "Pipeline transport",
      "description": "Movement of goods through pipelines (oil, gas, etc.)",
      "isLeaf": false
    }
  ]
}

5. evaluate_tile

Evaluate a leaf tile (concrete solution)

Assess viability with quantitative metrics.

{
  "tileId": "leaf-tile-id",
  "impact": 8,
  "feasibility": 6,
  "uniqueness": 4,
  "timeframe": "5-10 years",
  "notes": "High impact but faces infrastructure challenges",
  "calculationsOrPilots": "Pilot study in 3 cities showed 60% reduction in emissions"
}

6. get_coverage_analysis

Analyze solution space coverage

Identify unexplored branches, unvalidated splits, and next steps.

{
  "treeId": "tree-id"
}

Returns:

• Tiles not yet split (exploration gaps)
• Splits not validated for MECE
• Leaves not evaluated
• Coverage percentage
• Suggestions for next steps

7. get_unexplored_tiles

Find gaps in your exploration

Get tiles that haven't been split yet.

8. get_top_leaves

Find the best solutions

Get highest-rated leaves by impact, feasibility, uniqueness, or combined score.

{
  "criteria": "combined",
  "limit": 10,
  "treeId": "tree-id"
}

9. export_tree

Export for visualization

Export in JSON, Markdown, Mermaid diagrams, or DOT (GraphViz) format.

{
  "treeId": "tree-id",
  "format": "mermaid"
}

Additional Tools

• get_trees: List all tiling trees
• get_tile: Get details of a specific tile
• explore_path: Explore tree structure from a tile
• get_leaf_tiles: Get all concrete ideas/projects
• search_tiles: Search by content
• update_tile: Update tile information
• get_statistics: Overall statistics

10. validate_split_quality

Detect common antipatterns in a split

Automatically checks for:

• Vague language: Imprecise terms like "natural", "traditional", "simple"
• Catch-all buckets: Categories like "other" or "misc" that prevent exploration
• Mixed dimensions: Splitting along inconsistent attributes
• Retroactive splitting: Using pre-existing solution taxonomies instead of first principles
• Incomplete coverage: Splits not validated for MECE

{
  "tileId": "parent-tile-id"
}

Returns:

• Quality score (0-100)
• List of issues with severity (error/warning)
• Specific recommendations for improvement

11. get_tree_validation_report

Validate entire tree for quality

Get validation reports for all splits in a tree with an overall quality score.

{
  "treeId": "tree-id"
}

Common Failure Modes

Based on real-world usage, watch out for these antipatterns:

1. Retroactive Splitting (Taxonomy Import)

Problem: Starting with known solution types from literature locks you into existing categories.

Bad: Splitting "battery improvements" by {Li-ion optimizations, NiMH advancements, Lead-acid improvements} Good: Splitting by {chemistry type, electrode material, electrolyte state, architecture}

Why: Retroactive splitting only generates variations within known categories. First-principles splitting discovers fundamentally new possibilities.

2. Catch-All Buckets

Problem: Creating "other materials" or "miscellaneous" categories prevents systematic exploration.

Bad: {Silicon, Graphite, Lithium metal, Other materials} Good: {Crystalline, Amorphous, Composite, Layered}

Why: You can't split "everything else" systematically. If you don't know what belongs in a category, the split dimension needs revision.

Use validate_split_quality to automatically detect catch-all buckets (error severity).

3. Vague Language ("Words That Mean Nothing")

Problem: Terms like "natural", "forced", "traditional" lack physical precision and create unavoidable overlaps.

Bad: {Natural cooling, Forced cooling} Good: {Passive convection, Active forced-air, Liquid cooling, Phase-change}

Why: "Natural" doesn't map to unique physical properties - it could mean many things. Use measurable properties instead.

Use validate_split_quality to automatically flag vague terms (warning severity).

4. Mixed Dimensions (Category Errors)

Problem: Splitting along inconsistent dimensions creates inherent overlaps.

Bad: Vegetables classified as {Red ones, Sweet ones, Crunchy ones} - mixing color, taste, and texture Good: Split by ONE dimension: {Root, Stem, Leaf, Fruit, Flower} OR {Raw-edible, Requires-cooking}

Why: One vegetable can be red AND sweet AND crunchy. Categories must be mutually exclusive.

Use validate_split_quality to detect mixed dimension warnings.

5. Incomplete Coverage

Problem: Missing possibilities in the split leaves gaps unexplored.

Solution: Always validate splits with mark_mece and use get_coverage_analysis to find gaps.

Validation Workflow

After creating splits, validate quality:

// Check a specific split
validate_split_quality({
  tileId: "<parent-tile-id>"
})

// Response:
{
  "score": 70,
  "issues": [
    {
      "type": "vague_language",
      "severity": "warning",
      "message": "Tile 'Advanced materials' uses vague term 'advanced'",
      "suggestion": "Replace 'advanced' with measurable properties..."
    }
  ],
  "recommendations": [
    "Replace vague terms with measurable physical properties"
  ]
}

// Check entire tree
get_tree_validation_report({
  treeId: "<tree-id>"
})

// Response includes overall score and all split reports

Workflow Example

Problem: Improve battery energy density

Step 1: Create the tree

create_tree({
  name: "Battery Energy Density Improvements",
  problemStatement: "How can we increase battery energy density by 3x?"
})

Step 2: First split - by chemistry

split_tile({
  tileId: "<root-id>",
  splitAttribute: "Battery chemistry",
  splitRationale: "Fundamental chemistry determines theoretical energy density limits",
  subsets: [
    { title: "Lithium-based", description: "Li-ion, Li-polymer, Li-metal, Li-S, Li-air" },
    { title: "Sodium-based", description: "Na-ion and variants" },
    { title: "Metal-air", description: "Zn-air, Al-air (excluding Li-air)" },
    { title: "Solid-state", description: "Solid electrolyte batteries (any chemistry)" },
    { title: "Alternative chemistries", description: "Mg, Ca, multivalent ion, organic" }
  ]
})

Step 3: Validate MECE

mark_mece({
  tileId: "<root-id>",
  isMECE: true,
  coverageNotes: "Covers main battery chemistry families. Some overlap (e.g., Li-air could be 'metal-air'), resolved by treating Li as primary classifier."
})

Step 4: Continue splitting

Split "Lithium-based" by approach:

• Electrode material improvements
• Electrolyte improvements
• Cell architecture innovations
• Manufacturing process optimizations

Step 5: Reach leaves and evaluate

When you reach concrete ideas:

evaluate_tile({
  tileId: "<silicon-anode-id>",
  impact: 9,
  feasibility: 7,
  uniqueness: 5,
  timeframe: "2-3 years",
  calculationsOrPilots: "Lab tests show 40% capacity increase; volume expansion remains challenge"
})

Step 6: Analyze coverage

get_coverage_analysis({ treeId: "<tree-id>" })

Step 7: Find top solutions

get_top_leaves({
  criteria: "combined",
  limit: 5,
  treeId: "<tree-id>"
})

Best Practices

1. Define Precisely

Write explicit definitions for each tile to ensure no overlaps. Be mathematical/physical when possible.

Good: "Electric vehicles using only battery power (no combustion engine)" Bad: "Clean cars"

2. Choose Good Split Attributes

• Prefer physics/math-based dimensions
• Ensure the attribute creates natural, complete partitions
• Document rationale for future reference

3. Validate MECE Rigorously

• Check for overlaps between sibling tiles
• Verify all possibilities are covered
• Document edge cases

4. Split to Appropriate Depth

• Don't stop too early (you'll miss solutions)
• Don't go too deep too fast (you'll lose the forest for the trees)
• Leaf nodes should be concrete enough to evaluate

5. Evaluate Honestly

• Base ratings on data when possible
• Document assumptions
• Include calculations or pilot results
• Be consistent across evaluations

6. Revisit Periodically

• Technologies evolve
• Contexts change
• Previously unviable branches may become promising

Tips for AI Assistants Using This MCP

When helping users with tiling trees:

1. Start with problem clarification - ensure the problem statement is specific
2. Suggest physics/math splits when applicable - avoid retroactive splitting from known solutions
3. Run validation after splits - use validate_split_quality to catch antipatterns early
4. Flag vague language - watch for terms like "natural", "traditional", "advanced"
5. Prevent catch-all buckets - never allow "other" or "misc" categories
6. Enforce single dimensions - ensure each split uses one consistent attribute
7. Encourage precision - push for measurable properties and explicit definitions
8. Use coverage analysis - regularly check for unexplored areas
9. Balance breadth and depth - explore widely before going deep
10. Prompt evaluation - remind users to rate leaves with calculations/pilots, not just intuition

Proactive Validation: After each split, automatically run validate_split_quality and present any issues with constructive suggestions. This helps users learn the method correctly.

Integration with Web Interface

This MCP server complements the tiling-trees web interface. Use the server for:

• Systematic exploration and validation
• Programmatic tree construction
• Coverage analysis
• Bulk operations

Use the web interface for:

• Visual exploration
• Presentations
• Collaborative sessions
• Quick modifications

Export from MCP → Import to web interface for best of both worlds.

Example Split Attributes by Domain

Engineering/Physical

• Energy source
• Scale (nano/micro/macro)
• Physical mechanism
• Material type
• Phase (solid/liquid/gas/plasma)

Business/Strategy

• Market segment
• Revenue model
• Geographic region
• Customer type
• Distribution channel

Software/Computing

• Architecture pattern
• Data structure
• Computational complexity class
• Deployment model
• Interface type

Research/Science

• Methodology (experimental/theoretical/computational)
• Organism/system type
• Time scale
• Spatial scale
• Measurement technique

Troubleshooting

Q: My split has overlaps - what do I do? A: Refine definitions to make categories mutually exclusive. Sometimes this means choosing a different split attribute.

Q: I can't cover everything with my categories A: Add an "Other" category temporarily, then revisit with a better split attribute that creates natural, complete partitions.

Q: How do I know when to stop splitting? A: Stop when you reach concrete, evaluable ideas/projects. If a tile is still too abstract to assess impact/feasibility, keep splitting.

Q: Can I have multiple trees for the same problem? A: Yes! Different split strategies yield different insights. Compare trees to find the most useful partitioning.

License

MIT

References

• The Tiling Tree Method - Original article
• MECE Principle - Background on mutually exclusive and collectively exhaustive categorization