fix: split comma-separated tags in search_notes tags parameter

[jagadeeswara-ks]

Fixes #910

---

search_notes(tags="alpha,beta") returned zero results because the tags parameter coerced the bare comma string into the single literal tag ["alpha,beta"], while the tag:alpha,beta query shorthand (and write_note's tag convention) split on commas. Within one tool, comma-string tags behaved two different ways.

This swaps the tags BeforeValidator from coerce_list to the existing parse_tags, which already handles lists, JSON-array strings, and bare comma strings consistently (and is the same helper write_note and the entity parser use). This preserves the JSON-array-string handling coerce_list provided while adding comma-splitting, so the tags= parameter now matches the tag: shorthand.

Scope is kept to tags. The related note_types / entity_types / categories filters still use coerce_list; applying comma-splitting there is a separate decision (and parse_tags' #-stripping is tag-specific), so I left them untouched — happy to follow up if you'd like consistent splitting on those too.

Added an integration regression test asserting the tags= parameter and the tag: shorthand return the same results for the same comma string. A unit test at the search_notes level isn't included on purpose: the BeforeValidator doesn't run on direct Python calls (only through the validated MCP path), so the integration level is where this is meaningfully covered. parse_tags itself is already exhaustively unit-tested.

Verified locally: the full search unit + integration suites (64 passing), ruff, and ty all green.

🤖 AI-assisted (Claude Code), human-reviewed.

Reviewed SHA: af64adadcdb1b5e0a422ff0355485a66869ee16d
Verdict: needs_human
Status: failure - BM Bossbot review did not finish

Summary:
BM Bossbot intentionally did not run Codex because this PR was not opened by an owner, member, or collaborator.

Blocking findings:

• BM Bossbot does not run for outside contributors: This PR author association is NONE. BM Bossbot only runs for OWNER, MEMBER, and COLLABORATOR pull requests, so this PR requires a maintainer path outside the automatic merge gate.

Non-blocking findings:

• None

[CLAassistant]

All committers have signed the CLA.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 4560638b8c

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Reject non-list tag values instead of stringifying them

When tags receives an invalid JSON value such as an object or number, parse_tags falls through to parse_tags(str(tags)), so the MCP argument validator now accepts malformed filters as a literal tag instead of failing validation. The previous coerce_list path left non-string/non-list values for Pydantic to reject, so bad client payloads surfaced immediately; now they become successful searches with confusing no-result behavior. Use a search-specific parser that only accepts str, list[str], or None before splitting comma strings.

Useful? React with 👍 / 👎.

[phernandez]

Labeling needs-review: the validator change landed via #932, and #943 carries this PR's regression test with original authorship so it merges with full credit. Keeping this open until #943 lands.

[phernandez]

Closing this one out — with thanks, and with your work landed.

You had the correct fix for #910 first; our automation raced you with a duplicate (#932), which was our process failure, not a problem with this PR. To make sure the contribution counted, we carried your commit forward in #943 and rebase-merged it, so it now sits on main with your authorship intact: 44ecec2 — test(mcp): assert tags param and tag: shorthand comma equivalence. You're in the contributor graph for it.

The validator change itself reached main via #932, and follow-ups #941 hardened the same boundary further. Your scoping note about note_types/entity_types/categories is tracked as #930.

Hope to see more PRs from you — and next time the bots will check for an existing PR before touching an issue.