tools/call → memory.list with a tags argument fails with a Postgres error. memory.listwithout tags works; memory.write and memory.searchwith tags work. Only memory.list's tag filter is broken.
Repro
HTTP POST /api/mcp, cli-v1 bearer, project-scoped.
One tag → malformed array literal: "kind.scratchpad"
No tags → works (returns items). Same tags via memory.search → works (but search appears to boost by tags, not require them, so it's not a substitute for list-by-tags).
Impact
Any client listing notes filtered by tags fails. Worked around downstream by fetching unfiltered and filtering client-side (require-all-tags), but that caps at the server's 200-item limit — a server fix is preferable.
Likely cause
The tags filter in the list query builds a malformed text[] literal / casts a record to text[]. Compare with the working memory.search tag handling. Probable fix: bind tags as a proper array param and use containment (tags @> $1::text[]) or = ANY(...).
Doc nit (not a bug)
Tag writes reject anything outside [A-Za-z0-9._-] (e.g. :) with a zod regex error only at write time. Documenting the allowed tag charset in the tool schema would save trial-and-error.
Filed by Claude on behalf of @jknapp during the hosting-assistant integration.
## Summary
`tools/call` → `memory.list` with a `tags` argument fails with a Postgres error. `memory.list` **without** tags works; `memory.write` and `memory.search` **with** tags work. Only `memory.list`'s tag filter is broken.
## Repro
HTTP `POST /api/mcp`, `cli-v1` bearer, project-scoped.
**One tag** → `malformed array literal: "kind.scratchpad"`
```json
{"jsonrpc":"2.0","id":1,"method":"tools/call","params":{"name":"memory.list","arguments":{"scope":"project","project":"hosting-assistant-ops","tags":["kind.scratchpad"],"limit":5}}}
```
**Two tags** → `cannot cast type record to text[]`
```json
{"jsonrpc":"2.0","id":1,"method":"tools/call","params":{"name":"memory.list","arguments":{"scope":"project","project":"hosting-assistant-ops","tags":["kind.scratchpad","smoke.deploy"],"limit":5}}}
```
**No tags** → works (returns items).
**Same tags via `memory.search`** → works (but `search` appears to *boost* by tags, not *require* them, so it's not a substitute for list-by-tags).
## Impact
Any client listing notes filtered by tags fails. Worked around downstream by fetching unfiltered and filtering client-side (require-all-tags), but that caps at the server's 200-item limit — a server fix is preferable.
## Likely cause
The `tags` filter in the list query builds a malformed `text[]` literal / casts a record to `text[]`. Compare with the working `memory.search` tag handling. Probable fix: bind tags as a proper array param and use containment (`tags @> $1::text[]`) or `= ANY(...)`.
## Doc nit (not a bug)
Tag writes reject anything outside `[A-Za-z0-9._-]` (e.g. `:`) with a zod regex error only at write time. Documenting the allowed tag charset in the tool schema would save trial-and-error.
_Filed by Claude on behalf of @jknapp during the hosting-assistant integration._
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Summary
tools/call→memory.listwith atagsargument fails with a Postgres error.memory.listwithout tags works;memory.writeandmemory.searchwith tags work. Onlymemory.list's tag filter is broken.Repro
HTTP
POST /api/mcp,cli-v1bearer, project-scoped.One tag →
malformed array literal: "kind.scratchpad"Two tags →
cannot cast type record to text[]No tags → works (returns items).
Same tags via
memory.search→ works (butsearchappears to boost by tags, not require them, so it's not a substitute for list-by-tags).Impact
Any client listing notes filtered by tags fails. Worked around downstream by fetching unfiltered and filtering client-side (require-all-tags), but that caps at the server's 200-item limit — a server fix is preferable.
Likely cause
The
tagsfilter in the list query builds a malformedtext[]literal / casts a record totext[]. Compare with the workingmemory.searchtag handling. Probable fix: bind tags as a proper array param and use containment (tags @> $1::text[]) or= ANY(...).Doc nit (not a bug)
Tag writes reject anything outside
[A-Za-z0-9._-](e.g.:) with a zod regex error only at write time. Documenting the allowed tag charset in the tool schema would save trial-and-error.Filed by Claude on behalf of @jknapp during the hosting-assistant integration.