MCP recall/reflect: a mistyped tags_match silently widens the scope to "any" #5371

Activity

1. github-actions

   added

   integration:openclaw

   on Oct 7, 2026
2. koriyoshi2041 commented on Oct 7, 2026

   

   koriyoshi2041

   on Oct 7, 2026

   Contributor

   More actions

   Confirmed the widening one layer below MCP on exact main (9269b8841): both unknown spellings produce the same SQL predicate as any, while any_strict excludes untagged rows.

   any_strict -> AND tags IS NOT NULL AND tags != '{}' AND tags && $1
   any-strict -> AND (tags IS NULL OR tags = '{}' OR tags && $1)
   strict     -> AND (tags IS NULL OR tags = '{}' OR tags && $1)
   any        -> AND (tags IS NULL OR tags = '{}' OR tags && $1)
   

   The existing focused tag semantics tests are green (7/7), so this is the parser's deliberate fallback rather than a query-builder regression.

   One scope detail for a team-owned fix: the four MCP signatures should be typed as proposed, but GET /v1/default/banks/{bank_id}/documents independently still declares tags_match: str and passes it to the same builder. That endpoint should use TagsMatch too; otherwise MCP becomes strict while a typo on document listing continues to widen. I could not reproduce the same issue on the graph routes: their public query parameters are already typed as TagsMatch on current main.

   Focused checks:

   uv run pytest tests/test_tags_visibility.py -q \
     -k 'test_tags_match_any_includes_untagged or test_tags_match_any_strict_excludes_untagged or test_strict_tags_match'
   # 7 passed
   
3. JayOfTheKeyboard commented on Oct 10, 2026

   

   JayOfTheKeyboard

   on Oct 10, 2026

   ContributorAuthor

   More actions

   Thanks @koriyoshi2041 for confirming this on main and for finding the documents endpoint.

   I've rebased the fix branch onto current main and added two commits:

   • GET /v1/default/banks/{bank_id}/documents now types tags_match as TagsMatch, so any-strict or strict gets a 422 instead of a 200 that includes untagged documents: JayOfTheKeyboard@b32c4a1
   • GET /v1/default/banks/{bank_id}/graph had the same problem. On main it still declares tags_match: str (default all_strict), and get_graph_data has a comment noting that an unknown mode falls through to any. You're right that /entities/graph is typed, but the memory graph route isn't. It now gets a 422 too: JayOfTheKeyboard@5d3e721

   Each has a test that fails on main with the untagged row in the response and passes with the fix. The OpenAPI spec and the clients are regenerated, and the control plane's documents proxy narrows the value for the new TypeScript type.

   I also checked the other places tags_match comes in as a plain string. The mental model MCP tools validate it before use, list_mental_models and list_directives use a Literal, and the Python client wrapper passes it through to routes that now validate it. So I don't think anything else widens.

   Branch: https://github.com/JayOfTheKeyboard/hindsight/tree/fix/mcp-recall-reflect-tags-match
4. koriyoshi2041 commented on Oct 10, 2026

   

   koriyoshi2041

   on Oct 10, 2026

   Contributor

   More actions

   Checked the rebased branch at 5d3e7219. The widened scope is now closed at each public entry point I could identify:

   • MCP recall / reflect: invalid modes fail validation before the engine; schemas expose all five modes.
   • GET /documents and GET /graph: invalid modes return 422; valid any_strict still excludes untagged documents.
   • Generated API/client changes match the two HTTP annotations, and git diff --check is clean.

   Focused results:

   tests/test_mcp_tools.py -k RecallReflectTagsMatch
   12 passed
   
   tests/test_graph_filtering.py tests/test_tags_visibility.py
   -k 'test_graph_rejects_unknown_tags_match or test_list_documents_http_any_strict_excludes_untagged or test_list_documents_http_rejects_unknown_tags_match'
   5 passed
   

   The HTTP suite initially hit my local SOCKS environment while loading the embedding model; rerunning without proxy env completed cleanly. I don't see another plain-string public ingress left that reaches the permissive parser.
5. nicoloboschi

   added

   bugSomething isn't workingSomething isn't working

   core

   and removed

   integration:openclaw

   on Oct 12, 2026
6. nicoloboschi

   added a commit that references this issue on Oct 16, 2026

   fix(tags): reject an unknown tags_match instead of widening it to "an…

   ...

   89594d2
7. nicoloboschi

   closed this as completedin #5653on Oct 16, 2026