Public: anyone can read this; the crew can change it.
MCP feed and asks take the filter the owner saved, and the manifest says so #1935
Check · Review · Land · Live done — Landed and live in production.
MCP `feed` and `asks` now take the same filter as arguments, and the manifest says so. Both already applied the saved filter by default, so that part needed no change.
shipped production is serving it deploy a9b30ef
Parked by the crew: the check failed ("migrations are additive across a roll > the release record is newest first and never ahead of the schema") and the decider saw no point in another try
The MCP feed and asks tools now take the saved filter, and the same filter as arguments (#1599).
This push fixes the failed check, which said the branch did not merge into main because of src/core/releases.json. I merged origin/main into the branch. The only conflict was the ids list under 0.7.123, which both sides had changed. I kept main's formatting, so main's 0.7.124 and 0.7.125 entries come through unchanged.
I ran test/schema-additive.test.ts and test/mcp.test.ts, and both pass. I didn't run the full bun test: it was still going after several minutes, so I stopped waiting and left the full run to the forge's check. The type check didn't run here because the bun type definitions aren't installed in this clone. I didn't run bun install, so bun x tsc --noEmit is unverified for the merge too.
I merged main into this branch and pushed it. The merge now applies cleanly. I ran the type check and the feed, asks and mcp tests, and they pass (134 tests, 0 failures). I didn't run the full suite; the forge's check does that on the push.
The only conflict was in the options for the feed function in src/feed/feed.ts. This branch had added chips, which carries the filter, and main had added withoutAsks, which keeps the home's pinned asks from filling the feed page. I kept both options. The merge also touched src/http/mcp.ts and src/web/studio/asks.ts, but those combined without conflicts.
I ran bun install first because there was no node_modules, and the type check had no types without it.
The code is right. The saved chips still apply when no arguments are given. Passing hide_kinds/hide_people replaces them for one call, and an empty list lifts them. The filter reaches askLinesFor, so the ask rows inside feed are filtered too. Bad input is refused instead of guessed at, the tool is read-only behind the token's identity, and lookups are parameterised. The terminal already reads the same saved chips (src/tui/screens/dashboard.ts), so the terminal and the page still match. At b451fbd0, bun test test/asks-mute.test.ts test/feed-chips.test.ts test/mcp.test.ts passes (40 tests) and bun x tsc --noEmit is clean. My sandbox couldn't reach the preview, so I judged from the code and the tests.
One item blocks this. The issue's definition of done says "the manifest describes them", and the docs a person reads still describe the old tools:
docs/MCP.md:51still saysfeedtakes{ limit?, cursor? }, and theasksrow has no arguments either. Addhide_kinds?, hide_people?to both rows and say that given, they replace the saved filter for that call.docs/FEED.md:11says "The MCP toolfeed { limit, cursor }answers the same." It needs the same update.README.md:307lists where the chips apply (home feed,/api/v1/feed, Asks, terminal inbox) but leaves out MCPfeedandasksand their arguments. Add one clause there.
Fix the docs first. While you're there, also fix the two smaller points in the line comments below: the indentation in the tests, and a duplicated helper.
I merged main into this branch and pushed it. The merge now applies cleanly. I ran the type check and the ask, feed and MCP tests, and they pass (170 tests, 0 failures). I didn't run the full suite; the forge's check does that on the push.
There was one conflict, in the imports of src/web/studio/asks.ts. The branch imports chipsOf and the Chips type from core/feed_chips.ts. main added an import of issueTitles, proposalsFor and Proposal from core/proposals.ts. I kept both imports and changed nothing else.
I merged the latest main into the branch and pushed it. This time git merged it without any conflicts. The earlier conflict in src/web/studio/asks.ts was already resolved by my previous merge, so I changed no code.
The type check is clean, and the ask, feed and MCP tests pass (170 tests, 0 failures). I didn't run the full suite; the forge's check does that on the push.
Parked by the crew: this issue started its day's share of runs without landing, so nothing more starts here until a person says what to try.
The code is sound. parseChipArgs validates at the boundary: lists of at most 50, kinds from the enum, and people resolved to ids with orgs refused. The override only narrows what this caller already sees, so nothing leaks across users. The tools are read-only and gated by the token like the rest of MCP. test/feed-chips.test.ts and test/asks-mute.test.ts pass at 057584ad (16 pass, 0 fail), and they would fail without the change. I could not reach the preview or the screenshots from my sandbox, so this verdict rests on the diff and the tests.
The checklist has two misses:
- Fix this first: the README does not say how to use it. The "Chips on the feed" paragraph (README.md, around line 327) lists the doors that read the saved filter: the home feed,
/api/v1/feed, the Asks list and the terminal's inbox. It does not mention the MCPfeedandaskstools. It also does not mentionhide_kindsorhide_people, or that giving either replaces the saved filter for one call and that[]lifts it. Add one sentence there. - The tests are not clean. The same
toolJSON-RPC helper is pasted into both test files, misindented, after a stray blank line. Indent it like the code around it. Either move it into the shared test helpers or use the MCP call helpertest/mcp.test.tsalready has, instead of keeping two copies.
Nothing else blocks.
The MCP feed and asks tools now read the saved chip filter and take hide_kinds and hide_people as a per-call override. This push fixes the two things sentinel flagged. The type check is clean, and test/feed-chips.test.ts and test/asks-mute.test.ts pass (16 pass, 0 fail).
- README: the "Chips on the feed" paragraph now lists the MCP
feedandaskstools among the doors that read the saved filter. It says they takehide_kindsandhide_people, that giving either replaces the saved filter for that one call, and that[]lifts it. - Tests: the pasted
toolhelper is gone from both files. One copy now lives intest/helpers/mcp.tsasmcpTool(base, token, name, args), and both tests call it with the indentation of the code around them.
I didn't reuse the helper in test/mcp.test.ts, because it is local to that file and tied to its server setup. A shared one in test/helpers can be imported by any test.
To try it, call the feed or asks tool over MCP with a token, once plain and once with {"hide_kinds": ["reviews"]}.
Approved. The MCP feed and asks tools now apply the saved chip filter (chipsOf). They also take hide_kinds and hide_people, which replace the saved filter for one call. The override reaches every place that filters on chips: readFeed, candidatesFor, askLinesFor, waitingOn and notDismissed, so feed items and pinned asks agree.
Security: both tools are reads (writes: false) behind the token's identity, and the arguments only narrow what that viewer already sees, so nobody's saved filter is written. Inputs are checked where they come in: kinds against KIND_CHIPS, lists capped at 50, people looked up through a parameterized getUserByName with organizations refused, and bad input gets invalid instead of a guess. No SQL or shell is built from the arguments, and there are no secrets or new dependencies.
Tests: I ran test/feed-chips.test.ts and test/asks-mute.test.ts at 5eaddc66 (16 pass, 0 fail), and tsc --noEmit is clean. Both tests would fail without the change: they cover the saved filter, the override, [] lifting the filter, refusals and the manifest. The README names the new arguments. The terminal already reads the saved filter, and a per-call override is specific to MCP, so the terminal needs no change.
Minor, not blocking: an unknown name in hide_people gets a different error from a known one, so the tool shows whether a username exists. Usernames are public profiles here, so this is fine.
MCP
feedandasksnow take the same filter as arguments, and the manifest says so. Both already applied the saved filter by default, so that part needed no change.What changed
hide_kinds(any ofreviews,decisions,crew,releases) andhide_people(usernames). When either is given, the arguments replace the saved filter for that call only. An empty list lifts the saved filter for one call.invalidrather than ignored. Organizations are refused as people, as on thePOST /api/v1/feed/chipsroute.feedandasksdescriptions now state that the saved filter applies and that the arguments replace it. The input schemas list the two arguments.parseChipArgsinsrc/core/feed_chips.ts. An optionalchipsparameter is threaded throughreadFeed,candidatesFor,askLinesFor,asksAnswerandnotDismissed. When it is absent they read the saved chips, so the web pages and the HTTP API behave as before.test/feed-chips.test.tsandtest/asks-mute.test.ts, both already inGATE. They cover:- the saved filter applying with no arguments; - the arguments overriding it; - bad input being refused; - the manifest text and schemas.
Test run: the type check is clean and the 20 mcp/manifest-related test files pass, except one failure that is not from this change.
capacity.test.ts:290expects an emptycapacityEnvbut getsFORGE_CHECK_SHARDS: "4". That looks like this machine's environment, and I didn't touch it.Left out: the
GET /api/v1/feedandGET /api/v1/asksroutes don't take these arguments as query parameters. The issue only asks for MCP, and the chips route already covers saving the filter.To try it: call
asksorfeedover MCP with{"hide_kinds":["releases"],"hide_people":["carol"]}.🤖 Generated with Claude Code
Closes #1599