Feature: Add native Claude Plugin / MCP integration for zero-setup Graphify workflows

[vimoxshah]

Problem

Graphify already works extremely well as a Claude Code skill, but the current workflow is still optimized around terminal-first usage.

A native Claude Plugin / MCP integration would make Graphify much easier for:

• non-terminal users
• product / architecture teams
• documentation workflows
• persistent second-brain use cases
• long-running project knowledge graphs

Right now users need to:

1. install Python + CLI
2. run graphify install
3. manually point it at folders
4. re-run when project context changes

This creates friction for broader adoption.

---

Proposed solution

Add native Claude Plugin / MCP server support so Graphify can be used directly from Claude chat sessions with tools like:

• build_graph(path)
• query_graph(question)
• update_graph(path)
• export_graph(format="html|json|md")
• explain_architecture(component)

This would make Graphify feel like a first-class memory + architecture reasoning layer inside Claude.

---

Suggested architecture

Graphify already has strong platform abstractions for Claude Code, Codex, Trae, OpenCode, and others.

A clean extension could be:

1) New platform adapter

Add:
graphify install --platform claude-plugin

This keeps it aligned with the current platform model.

2) MCP server mode

Expose Graphify core functions as MCP tools:

• graph build
• incremental update
• graph query
• architecture diff
• report generation

3) Persistent graph sessions

Allow Claude to reuse existing graph.json automatically between sessions.

4) Smart folder sync

Optional watch mode:

• auto update changed files
• incremental graph rebuild
• report deltas

---

Why this is useful

This would significantly improve:

• zero setup onboarding
• adoption outside engineering
• persistent repo memory
• architecture reviews
• documentation QA
• cross-session project understanding

Especially useful for teams using Claude as a daily engineering copilot.

---

Nice-to-have

Future enhancements:

• GitHub repo connector
• Notion / Obsidian folder sync
• PR diff graph updates
• architecture drift alerts
• graph snapshots over time

Happy to help validate design ideas or test an early implementation.

[dalonso-rbi]

Additionally: The permissions babysitting is effing annoying

[JoyCal000Gold]

+1 on this. Specific use case: token-cost reduction in agent workflows.

Currently, navigating the graph from Claude Code requires loading GRAPH_REPORT.md or raw wiki files (500–2000 tokens per lookup). An MCP server exposing deterministic tools like search_nodes(query), get_community(id), find_path(a, b) would reduce that to a single sub-200-token tool call.

python -m graphify mcp --help returns unknown command — confirming no server exists yet. This is the single highest-leverage retrieval improvement for knowledge-heavy repos.

[jorge-moreira]

@JoyCal000Gold the command not found might be a misconfiguration on your side. Have a look into the README and follow the instructions.
If you still have issues after that, please add here the trace logs so I can try to help you with the setup.

[serithemage]

Hey @vimoxshah — coming over from #532 (closing that as duplicate).

I built a working implementation of pieces (1) and (3) from your proposal on a v5-rebased branch (30 unit tests + E2E smoke pass):

• Auto-injection on every prompt: UserPromptSubmit hook (python3 -m graphify.auto_context) that extracts keywords from the user's prompt, queries graph.json, and injects a <graphify-context> subgraph block. Always exits 0 so a missing or broken graph never blocks the prompt.
• Active MCP: graphify MCP server auto-registered in .mcp.json, so query_graph / get_neighbors / shortest_path are exposed to Claude Code without manual setup.

Both bolted onto graphify claude install as a third tier alongside the existing CLAUDE.md section + PreToolUse hint.

Given the 9+ platform footprint of _PLATFORM_CONFIG and the bash-vs-PowerShell stress already in #522 / #533, I also drafted a standalone Claude Code plugin (graphify-claude-plugin) that bundles the same three tiers via .claude-plugin/plugin.json and depends on graphifyy[mcp] from PyPI rather than living in __main__.py. Same E2E behavior, but graphify/__main__.py stops growing per integration.

Two ready-to-go paths but want @safishamsi's call before opening a PR:

1. PR against v5 — extends _install_claude_hook and claude_install (continues the existing per-platform pattern)
2. Separate plugin repo — ships via the plugin marketplace, keeps the graph layer focused on the graph itself

#326 (Kiro userPromptSubmit hook) and #425 (hierarchical context layer) suggest there's appetite in both directions. Happy to send either — just don't want to burn review cycles on a direction that doesn't match the roadmap.