josephschmitt / josephschmitt/knowledge-tools

Adopt MCP 2026-07-28 / SDK v2 to unlock interactive UIs, standardized async jobs, and stateless deploys

Open
#66 0 comments 0 reactions 0 assignees View on GitHub
enhancement
Dominant language
Go
Stars
2
Forks
0
Avg merge
1m
Merged PRs (30d)
1

Description

Tracking issue for opportunities opened by the MCP spec revision **2026-07-28** (final July 28, 2026; TypeScript SDK v2 in beta now). This is **opt-in** — our current v1 server (`@modelcontextprotocol/sdk@^1.0.0`) stays protocol-compatible (new clients fall back to the `initialize` handshake), and we use none of the deprecated primitives (Roots/Sampling/Logging), so nothing forces the move. These are features worth building, not a mandated upgrade.

## Foundation — SDK v2 + stateless (enabler for everything below)

- [ ] Migrate `service/` from the monolithic `@modelcontextprotocol/sdk` to v2's focused packages (`@modelcontextprotocol/server`, `createMcpHandler` as the stateless HTTP entry point). No v1↔v2 back-compat; codemod exists (`npx @modelcontextprotocol/codemod@beta v1-to-v2 .`).
- [ ] Delete the stateful session plumbing in `service/src/index.ts` (the `sessionIdGenerator`, the in-memory `transports` map, the two `404`-so-the-client-reinitializes workarounds). Stateless removes the redeploy-drops-live-sessions failure mode — relevant since the service ships as a CI-built GHCR image that redeploys on every `service/**` change.
- [ ] Review `service/src/auth.ts` (jose JWT/OIDC) against v2 auth hardening (RFC 9207 `iss` validation, OIDC `application_type`). Off-by-default behind a proxy, so not urgent.

## Feature — MCP Apps (interactive UIs) — *host-gated on claude.ai rendering support*

Tools attach a `ui://` resource (self-contained HTML/JS/CSS, host-rendered in a sandboxed iframe, communicating over JSON-RPC/postMessage). Candidate surfaces:

- [ ] **Capture preview / edit-before-commit** *(the priority — see design note)*. **Problem this solves:** today the agent silently distills what the user says into the `append_to_inbox` `text` payload — and that payload is hidden behind the tool call. The user sees only a paraphrased confirmation, never the verbatim string that actually landed in the inbox, so there's no way to know the capture matches what they said. An MCP App shows the drafted capture (text + title), lets the user edit it, then Approve / Discard; on approve it writes via the existing `appendToInbox` core in `service/src/vault.ts`. Applies to **all** captures, not just agent-authored ones.
- [ ] **Review-queue panel** for the judgment-call flow (`list_questions` / `get_question` / `answer_question`): render the contradiction + involved notes + an answer box / accept-reject inline, replacing three text round-trips.
- [ ] **`vault_status` dashboard**: live widget (pending inbox count, per-job running/next-run, last compiled) instead of polled JSON.
- [ ] **`get_note` rendering**: formatted markdown / small note browser.

## Feature — Tasks extension (standardized async jobs)

Our `compile_run` / `synthesize_run` / `resolve_run` already hand-roll "return immediately, poll `vault_status`." The Tasks extension is that pattern as protocol: `tools/call` returns a task handle; client drives `tasks/get` / `tasks/cancel`; host manages the wait/timeout.

- [ ] Back the three job triggers with Tasks. Task state already lives in a file store (`inbox/.compile/status.json`), which is stateless-friendly (task id carries state, any instance answers). Gains: **cancel** (none today) and host-managed timeouts (retires the "return immediately so the client doesn't hang" dance). Only affects the daemon-backed HTTP mode; the stdio / agent-driven path (returns the skill body) is unchanged.

## Feature — Response caching (`ttlMs` / `cacheScope`) — small, low-effort

- [ ] Tag stable read responses (`list_index`, `list_notes`, library `get_note`) with a TTL (e.g. valid until next compile) to cut redundant connector reads. Not for `vault_status` (meant to be polled fresh).

## Design note — capture preview is transparency, not a curation gate

It might look like the preview/edit flow bends the deliberately decision-free capture rule ("dumb capture, smart compile"; when in doubt, capture; don't pre-organize) in `CLAUDE.md` / the `knowledge-vault` skill. It doesn't. The skill *already* has the agent choose the wording of a capture ("work out what 'this' is… capture that, not the transcript"), and that choice is currently invisible — the tool call hides the actual `text`, and the confirmation is only a paraphrase. This feature is **read-back + edit of what's being written**, so the user can confirm it matches what they said and fix the wording. It adds **no** curation decision (no dedup, no destination, no filing) — capture stays dumb; the user just gets to see and correct what landed. So it applies to **all** captures, including direct user-dictated saves (that's exactly where the visibility gap is worst).

**Considered and deferred:** an interim, non-MCP-Apps read-back — have `append_to_inbox` return the verbatim `text` it wrote and have the skill echo that on confirm — would close the visibility gap now, without the v2 migration or host MCP Apps support. Deferred by preference in favor of shipping the full MCP Apps preview/edit rather than an intermediate text-only step.

## Dependencies / sequencing

- MCP Apps + Tasks are **extensions**, negotiated with the host — payoff depends on claude.ai (primary client) supporting them; verify before building UI work.
- SDK v2 stable lands July 28, 2026; v1.x maintained ≥6 months after. Recommend landing the SDK v2 migration once, then building Apps/Tasks/caching on top rather than paying the rewrite cost twice.
- Among the MCP Apps surfaces, **capture preview/edit-before-commit is the first to build** — it addresses the standing "I can't see what the agent captured" gap.

## References

- Spec RC: https://blog.modelcontextprotocol.io/posts/2026-07-28-release-candidate/
- SDK betas: https://blog.modelcontextprotocol.io/posts/sdk-betas-2026-07-28/
- MCP Apps: https://blog.modelcontextprotocol.io/posts/2026-01-26-mcp-apps/

Contributor guide

No contributing guide indexed for this repository

Research direction

Start with service/src/index.ts and service/src/auth.ts, then inspect service/src/vault.ts and the existing job status flow. Verify SDK v2 and MCP Apps/Tasks support before implementation; done requires the v2/stateless migration and the explicitly selected extensions to work without the current session plumbing.

Written by the indexing model from the issue text.

Assessment

Tech stack
node.js, typescript
Domain
api, backend, devops
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Quiet
Clarity
Mostly clear
Newbie friendliness
20/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.