[thorwhalen]

Closes #67.

context (already on createMcpServer and toAITools, until now only passed to dispatch) now also filters the list: registry.list({ context }) evaluates string when clauses, so an unavailable command is not offered. New: buildToolsList(registry, { context }). context may be a function (ContextSource), read on every tools/list, build and dispatch, so it follows a context that changes. No context → unchanged. The getState name-collision check ignores the context on purpose. when_clause_failed at dispatch stays as the backstop. Note: the MCP server cannot know when a context changes; the doc comment says to send notifications/tools/list_changed.

Tests: tools (4), a real server over the SDK's in-memory transport (2), toAITools (3). Mutation-checked (reverting the sources fails 6). Suites: mcp 44, ai-vercel 14, tsc clean. Minor changeset (new option behaviour: listings shrink for callers who already passed context). Skills/README updated; the 'not implemented yet' note dropped.

Adversarial review (fresh Opus): fix-then-merge. Confirmed and fixed: (1) passing context to registry.list ran function whens that are then excluded anyway and could throw, failing the whole tools/list — availability is now checked after the function-when exclusion (regression tests, both packages); (2) the ai-vercel dispatch test could not detect a broken getter — now has a positive case; (3) no MCP test dispatched with a function context — added; (4) docs: changeset and README now say the list is fixed when built and the server never sends list_changed for a context change. (5) A throwing context getter is a protocol error on tools/call: documented. Checked fine: missing keys are false (commands that used to fail at dispatch are the ones now hidden), collision check ignores context, hidden commands stay callable by name (dispatch re-checks when). Not changed: toAITools and toToolNameMap each read a function context separately.

🤖 Generated with Claude Code