feat(memory): expose knowledge graph as MCP Resource

[RaidLZ]

Register the knowledge graph as a readable MCP Resource at
memory://knowledge-graph, enabling clients to discover and read
the graph via the Resources protocol.

This demonstrates the underutilized Resources feature of MCP in a
reference server, as encouraged by CONTRIBUTING.md.

[cliffhall]

@claude review

[claude]

Claude finished @cliffhall's task in 1m 47s —— View job

---

PR Review: feat(memory): expose knowledge graph as MCP Resource

• Gather context and read changed files
• Analyze implementation for correctness and MCP protocol compliance
• Check code quality and style
• Post review feedback

---

Summary

Good concept — adding a Resource to the memory server directly supports the CONTRIBUTING.md goal of showcasing underutilized MCP protocol features. The handler implementation is correct: uri.href echoes back the requested URI, the contents array structure matches the spec, and application/json is the right MIME type. A few things need attention before merging.

---

Issues

1. Resource name violates project naming convention (must fix)

src/memory/index.ts:471

server.registerResource(
  "knowledge_graph",   // ❌ snake_case

CLAUDE.md explicitly requires kebab-case for registered tools/prompts/resources:

kebab-case for file names and registered tools/prompts/resources

The name should be "knowledge-graph" (consistent with the URI memory://knowledge-graph too).

Fix this →

---

2. No tests (should fix)

The PR adds no tests. The everything server has a registrations.test.ts that verifies registerResource is called with the right arguments. The memory server should have an equivalent test — at minimum asserting the resource is registered with the correct URI and MIME type, and that its handler returns JSON-serialized graph data.

// example sketch
it('should register knowledge-graph resource with correct URI', () => {
  const mockServer = { registerResource: vi.fn() };
  // trigger registration ...
  expect(mockServer.registerResource).toHaveBeenCalledWith(
    'knowledge-graph',
    'memory://knowledge-graph',
    expect.objectContaining({ mimeType: 'application/json' }),
    expect.any(Function)
  );
});

---

3. Comment block exceeds project style limit (minor)

src/memory/index.ts:468–470

// Expose the knowledge graph as a readable MCP Resource.
// This demonstrates the Resources protocol feature, enabling clients
// to discover and read the graph without calling a tool.

CLAUDE.md says: "Don't add multi-line comment blocks — one short line max." Condense to one line, or drop entirely since the code is self-explanatory.

---

Observations (not blockers)

• Subscription support: Since the graph changes frequently via mutation tools, clients subscribed to this resource won't receive notifications/resources/updated events. Wiring up server.sendResourceUpdated("memory://knowledge-graph") after each write operation would make this much more useful. Not required now, but worth a follow-up.
• title field: The SDK's resource metadata supports a human-readable title (separate from the name arg). Adding title: "Knowledge Graph" alongside description would improve discoverability in clients that display resource titles.

---

Verdict

Request changes on items 1 (naming) and 2 (tests). Item 3 is a minor style fix. The core implementation is solid.

[LuuOW]

Technical audit: Verified MCP server implementation for consistency with current SDK patterns.

[olaservo]

Thanks for adding this, @RaidLZ — exposing the knowledge graph as a Resource is a great demonstration of the feature.

One gap I found while testing with an SDK client: the server emits notifications/resources/updated after mutations, but it only advertised resources.listChanged, not resources.subscribe. So resources/subscribe returned -32601 (Method not found), and a spec-compliant client could never actually subscribe to receive those updates — the README's "subscribed clients see live changes" wasn't reachable end to end.

Since "allow edits from maintainers" was enabled, I pushed a small follow-up commit to this branch (keeping your authorship of the base PR) that:

• declares resources.subscribe
• adds subscribe/unsubscribe request handlers that track subscribed URIs
• only emits resources/updated when the client has actually subscribed to that URI
• adds unit tests for the subscription wiring

Verified end to end with an SDK client: capability advertised, no notification before subscribe, subscribe succeeds, a notification fires while subscribed, and it stops after unsubscribe. Build is clean and all 50 tests pass.

Feel free to adjust or squash the follow-up however you like. Thanks again for the contribution!

Follow-up commit drafted with assistance from Claude Code.

[RaidLZ]

Thanks @olaservo ! I pulled your follow-up commit and reviewed it the subscribe/unsubscribe handlers and tests look great, and I'm happy to keep them as-is. Appreciate you getting this over the line.

[olaservo]

@RaidLZ thanks for your PR and for your patience. :)