[bug] Extension data routes to thoughts table instead of extension tables

[matthallett1]

Description

When users set up extensions (e.g., Household Knowledge), captured data sometimes routes to the thoughts table instead of the designated extension tables (e.g., household_items, vendors).

Impact

• Extension data is mixed in with general thoughts
• Extension-specific queries return no results (data is in the wrong table)
• Users who installed extensions and added data find it's not where expected

Reproduction

1. Set up the Household Knowledge extension per the guide
2. Add household items via the MCP connector
3. Check the household_items table — may be empty
4. Check the thoughts table — household data may appear here instead

Discord Context

From #help-old (Mar 15):

thorben0605: "First realisation was that all the household stuff ended in the thoughts table and not the designated tables. And when I tried to fix that, all went south."

From #help-old (Mar 14):

goodatbingo: "I'm might have Claude Coded my way through it so it's working, but I wanted to make sure it's architected correctly."

Possible Causes

• The AI client may be calling capture_thought (from the core MCP) instead of add_household_item (from the extension MCP) when both servers are connected
• Tool routing confusion when multiple MCP servers are active — related to the discussion in MCP Scoping & Cross-Entity Orchestration #36
• Extension MCP server may not be properly connected or may be falling back to core

Related Issues

• MCP Scoping & Cross-Entity Orchestration #36 — MCP Scoping & Cross-Entity Orchestration
• UserID is a foreign key constraint in the SQL in extensions/household-knowledge, but isn't accessible when insert runs #56 — user_id FK constraint in extensions

[matthallett1]

Discord references:

• thorben0605 reporting data in wrong table: https://discord.com/channels/1481783256641699840/1481790073392599041/1482758278088757351
• thorben0605 Edge Function crash: https://discord.com/channels/1481783256641699840/1481790073392599041/1482709416938831882
• goodatbingo working through setup: https://discord.com/channels/1481783256641699840/1481790073392599041/1482172825119600710

[justfinethanku]

This is interesting — I'll help investigate.

Looking at the reproduction reports, the likely cause is the AI client calling capture_thought (core MCP) instead of the extension-specific tools when multiple MCP servers are connected. That's a client-side routing decision, not necessarily a server bug — but it means our tool naming/descriptions may not be distinctive enough for the AI to pick the right one.

This is related to #36 (MCP scoping & cross-entity orchestration) which we're prioritizing. The core problem is the same: when multiple MCP servers are active, the AI client doesn't always route to the correct one.

Will dig into the Edge Function code and tool descriptions to see if there's a quick win on making extension tools more clearly distinguishable from core tools.

[justfinethanku]

Resolved by #90 — extracts the schema-aware routing pattern as a standalone, reusable recipe. Demonstrates how LLM-extracted metadata drives multi-table writes with proper routing decisions:\n\n- Every input routes to thoughts (always)\n- People table (find/fuzzy-match/create)\n- Interactions (one per resolved person)\n- Action items (only when the speaker uses first-person intent)\n\nIncludes the three-pass person resolution algorithm, fuzzy matching function, and full processThought() router. This pattern prevents extension data from incorrectly routing to the thoughts table by using metadata-driven routing logic instead of relying on AI tool selection.