AI / Graphify Interview questions

Graphify is an open-source tool that turns a folder of code, docs, PDFs, images and video or audio transcripts into a persistent, queryable knowledge graph. It is built mainly for AI coding assistants such as Claude Code, Cursor, Codex and Gemini CLI, but you can query the graph from a terminal as well.

You build the graph once and the assistant asks it questions instead of grepping through hundreds of files. Answers come back as paths between concepts, with a file and line on every hop.

The package on PyPI is graphifyy (two y's) and the command it installs is graphify. Graphify Labs also runs a hosted version at app.graphify.com that builds and refreshes the same kind of graph for you.

It is a map of your project stored as nodes and edges. Nodes are things like functions, classes, modules, documents and concepts. Edges are the relationships between them, such as calls, imports, inherits and references.

Each node keeps its source file, and each edge keeps a relation name plus a confidence label. That is why a query result can point you back to the exact code it came from.

A trimmed example of what a query returns:

$ graphify query "what connects auth to the database?"

AuthService -> SessionStore -> DatabasePool      [EXTRACTED]
  src/auth/service.py:42 -> src/db/pool.py:17

The graph is saved to graph.json, so it persists between sessions instead of being rebuilt in the assistant's head every time.

Install the graphifyy package from PyPI, then register the skill with your assistant. The steps for Claude Code:

1. uv tool install graphifyy installs the package and the graphify command.
2. graphify install registers the /graphify skill with Claude Code.
3. For other assistants run graphify install --platform codex (swap in your platform name).
4. Check the setup with graphify --version.
5. Inside the assistant, type /graphify . to build your first graph.

Watch the spelling. The official package is graphifyy with two y's, and a similarly named graphify package on PyPI is not a substitute.

Optional extras exist: graphifyy[mcp] adds the local MCP server and graphifyy[all] adds every optional language parser.

/graphify . is a skill invocation that you type into your assistant's chat, not into a shell. It tells the assistant to build a knowledge graph of the folder, including docs and images, and write the results to graphify-out/.

Code is parsed locally. Documents, papers, images and transcripts are handled by semantic extraction that runs through the model session you already have open. Adding --update re-scans only the files that changed.

Mixing the two up is the most common beginner mistake.

A build writes a small set of files you can open, commit or feed into other tools. The three you will touch most are graph.json, GRAPH_REPORT.md and graph.html.

Set the GRAPHIFY_OUT environment variable to change the output location, which helps when several worktrees need separate graphs.

graph.json is the machine-readable copy of your knowledge graph. The CLI, the MCP server and the export commands all read it, so it is the file that makes the graph reusable.

It follows NetworkX node-link conventions. Nodes carry an id, a label and usually source_file and file_type. Edges connect node ids and carry a relation and a confidence tag. Current readers expect a links array and still accept older files that use edges.

You can point a query at any copy of it:

graphify query "authentication" --graph ./shared/graph.json

Treat the file like source code from an access point of view, since it holds labels and context taken from your repository.

GRAPH_REPORT.md is the human-readable architecture report that Graphify writes beside the graph. It summarizes the communities it found, the central concepts and the notable connections between them.

Read it first when you join an unfamiliar codebase. It gives you the shape of the system in a few minutes, and you can then use graphify query or graphify explain to dig into anything that looks interesting.

Because it is plain Markdown, it diffs well in pull requests and many teams commit it next to graph.json so everyone, and every assistant, starts from the same picture.

The official site lists 17 assistants for the local skill, including Claude Code, Cursor, Codex, Gemini CLI, GitHub Copilot, Aider, Amp and Devin. The count keeps growing as platforms are added.

A bare graphify install sets up Claude Code. For anything else you pass the platform name:

graphify install --platform codex
graphify install --platform droid
graphify install --platform trae

The graph is also served over MCP, so a client without a native skill can still query it. The hosted console goes further and lists around 30 clients, including Kiro, OpenCode, Warp and JetBrains Junie.

Graphify accepts code, documentation, research papers, images and video or audio. They do not all take the same route through the pipeline.

YouTube sources are fetched with yt-dlp, so talks and tutorials can sit in the same graph as your code. Pass --code-only when you want to skip the model-based routes entirely.

Tree-sitter is a parsing library that turns source code into a syntax tree for each supported language. Graphify uses it to read code deterministically and locally, so the same code always produces the same declarations, imports and calls.

There are practical reasons beyond that:

• No LLM and no API key are needed for the structural graph.
• Every node and edge keeps its source file and line.
• Coverage is broad: the open-source CLI supports 40 languages, 33 through tree-sitter grammars and 7 through built-in parsers.
• Parsing is fast enough to rerun on every commit.

The hosted product lists 63 grammars. Some formats use heuristic or dedicated parsers, so support varies by language and by construct.

graphify extract runs the extraction pipeline from a shell, with no assistant chat involved. It parses the folder, builds the graph and writes the results to graphify-out/.

Two common forms:

graphify extract . --code-only
graphify extract ./docs --backend ollama

The first builds a structural graph from code alone, with no model and no key. The second runs semantic extraction on documents through a headless backend you configure, here a local Ollama model.

That makes it the right choice for CI jobs, scripts and any place where you cannot type a slash command into an assistant.

They are the confidence labels stored on every edge in graph.json. They tell you how Graphify came to know a relationship, so a guess never looks like a fact.

An INFERRED edge does not always come from a model. Static name and import resolution can produce one. Always read the evidence and any confidence score before treating it as fact.

graphify query takes a plain-English question and returns the part of the graph around it, so the assistant reads a small, relevant slice instead of the whole repository.

graphify query "how does a request get authenticated" --budget 1500

Name a feature, file or subsystem in the question. A specific question returns a smaller and more useful result than a broad one.

graphify path finds how two concepts connect and prints the chain of edges between them. Use it when you already know both ends, for example a handler and a database client.

graphify path "ApiHandler" "DatabaseClient"
graphify path "ApiHandler" "DatabaseClient" --undirected

By default it respects edge direction, so A calls B is not the same as B calls A. Add --undirected to explore connectivity regardless of direction, which helps when a directed search finds nothing.

A path is evidence from static analysis. It does not prove a request will actually travel that route at runtime.

graphify explain inspects a single node. Give it a function, class or concept and it shows what that node is and how it connects to its neighbors.

It fits naturally after the other two lookup commands. query finds the area, path links two points, and explain zooms in on one stop along the way.

graphify explain "build_from_json"

Use it when a query result mentions an unfamiliar name and you want its relationships without opening files first.

A typical flow: run graphify query, spot an unfamiliar node such as a session store, then explain it before opening any file. If you need to see how that node reaches a specific other node, switch to graphify path.

A god node is a highly connected node, a hub that many other nodes depend on or point to. graphify god-nodes lists them, and the hosted console shows the same idea as a Most connected list.

Graphify leaves out file-level nodes that collect imports mechanically, otherwise every file would look like a hub.

They matter for two reasons. They are the best entry points when you are learning a codebase, and they are the riskiest places to edit, because a change there fans out to many dependents.

graphify god-nodes

A community is a group of densely connected nodes that behaves like a subsystem. Graphify finds them with community detection, using Leiden when the dependency is installed and falling back to NetworkX Louvain otherwise.

Grouping depends only on how nodes connect. Folder names and file dates play no part. Community names are separate: they come from your assistant or a configured backend.

Communities show up as colors on graph.html and as sections in GRAPH_REPORT.md. They also drive graphify prs --conflicts, which flags open pull requests that touch the same community.

--code-only limits graphify extract to the structural pass. It parses source with tree-sitter and the dedicated extractors and skips model-based extraction of docs, papers and images.

graphify extract . --code-only

No LLM and no API key are involved. The Graphify docs report about 19.6k nodes and 44k edges in roughly 26 seconds on the open-source repo itself with this flag.

Reach for it in CI, on repositories where nothing may leave the machine, or when you simply want a fast first graph before deciding whether the richer passes are worth the cost.

.graphifyignore tells Graphify which paths to skip. It uses the same syntax as .gitignore, so there is nothing new to learn.

vendor/
node_modules/
dist/
*.min.js

Excluding bulk and generated folders keeps the graph smaller and faster to build, and it stops machine-written code from crowding out the hubs that matter. It is also a simple way to keep sensitive folders out of the graph entirely.

Be careful not to ignore your test folders if you want test-to-code links later.

Keep the file with the project and commit it, so teammates and CI builds skip the same folders. Otherwise graphs built on different machines can quietly differ.

It exposes the graph to an assistant through the Model Context Protocol, so the assistant calls tools like query_graph instead of reading files one by one. There are two flavors.

uv tool install "graphifyy[mcp]"
claude mcp add graphify -- graphify-mcp graphify-out/graph.json

Tool names differ between the two, so trust the live tool list your client shows.

Graphify returns paths of edges that were read from the code. A vector RAG pipeline returns chunks of text whose embeddings sit closest to the question. Graphify's own docs are explicit that it is not RAG: no embeddings, no similarity search.

The two combine well. Use the graph for structure and a vector index for loosely worded questions over documentation.

A language server answers one lookup at a time inside a running editor session, usually for one language in one project. Graphify keeps the whole picture as a saved graph that works across languages and repositories and can be queried without the editor.

They are complements. Keep the language server for exact in-editor navigation and use Graphify when an assistant needs the shape of the system.

The pipeline splits into two data paths that meet in the middle. Structure comes from the code, and meaning comes from documents and media.

flowchart LR
  A["Code and manifests"] --> B["Local structural extraction"]
  C["Docs and media"] --> D["Semantic extraction"]
  B --> E["Merge and resolve relationships"]
  D --> E
  E --> F["Communities and report"]
  F --> G["graph.json"]
  G --> H["CLI and MCP queries"]

1. Structural extraction. Tree-sitter and dedicated extractors find functions, classes, imports and calls. This runs locally and needs no model.
2. Semantic extraction. Documents, papers, images and transcripts contribute concepts through a model, which is a separate data path.
3. Resolve and merge. References are linked across files and fragments are combined, each edge keeping a provenance label.
4. Cluster. Leiden, or Louvain as a fallback, groups nodes into communities, and names may be added.
5. Write outputs. graph.json, the report and the HTML view land in graphify-out/.

A SHA256-based cache means later runs reprocess only the files that changed.

A parser can see that checkout() calls total(), but it cannot tell which total(). Graphify resolves the name from evidence in the code: the imports in the file, where each candidate is declared, and the receiver's type for obj.method() calls.

from billing import total

def checkout(cart):
    return total(cart)   # the import points at exactly one declaration

The rule is deliberately conservative. Graphify draws an edge only when the name resolves to exactly one declaration. If two could match, it leaves the edge out or marks it AMBIGUOUS.

A missing edge is a visible gap. A confidently wrong edge would quietly mislead an assistant, which is the worse failure.

Receiver types matter most in object-oriented code. Two classes can each define save(), so a call like user.save() only earns an edge when the type of user is known.

Because INFERRED describes how an edge was derived, not who derived it. Static name and import resolution can work out a relationship that is not spelled out literally, for example a method call resolved through a local type, and that edge is tagged inferred.

A semantic backend can also infer links between documents and code. That is a separate path, so the tag alone does not tell you which one produced the edge.

Practical rule: read the evidence and any confidence score, then open the cited source. In the hosted console the same edges show as inferred, and a fourth tag, observed, is reserved for relationships seen at runtime, which a build from source never produces.

Never for code structure. A model appears only in a few clearly labeled places, and most can be switched off.

Semantic extraction may send its input to the provider you select, so choose the backend deliberately. A local code parse never sends files to a model.

It reprocesses only what changed. Fingerprints in manifest.json and the extraction cache let Graphify skip every unchanged file, so refreshes stay cheap even on large repositories. This is the big difference from RAG pipelines that re-embed content.

Pick the lightest option that matches how stale you can tolerate the graph being. A hook is usually enough for a team.

It installs Git hooks that refresh the graph after commits, pulls, merges and rebases, so the graph tracks the repository without anyone remembering to run an update.

graphify hook install
graphify hook status
graphify hook uninstall

Third-party write-ups also describe a merge driver that union-merges graph.json when two developers commit in parallel. Check your installed version before relying on that.

If you commit graphify-out/, hooks mean every teammate's assistant reads a graph that matches the current branch tip, rather than whatever was built last week.

Hooks suit teams because they remove the human step. A graph refreshed on every pull or rebase rarely drifts far from HEAD, which is what makes a shared graph safe to rely on.

If a hook ever gets in the way, graphify hook uninstall removes it cleanly and graphify update . still works by hand.

There are three common routes, and they differ mainly in who builds the graph and where it lives.

• Commit graphify-out/. One person builds it and everyone's assistant reads the same files. Pair it with graphify hook install to keep it fresh.
• Self-host the MCP server. Run the open-source server over HTTP in Docker behind an API key you control.
• Use a hosted workspace. The graph and memory live in the workspace and every connected agent reads them.

Whichever you pick, remember the graph holds labels and context derived from your code. Give it the same access controls as the repository itself.

When several Git worktrees need independent graphs, set GRAPHIFY_OUT to a different directory for each.

Through a skill, an always-on nudge and an optional MCP server. Set up in this order:

1. graphify install --platform claude copies the skill to ~/.claude/skills/graphify/.
2. graphify claude install adds a ## graphify section to CLAUDE.md and writes PreToolUse hooks to .claude/settings.json.
3. claude mcp add graphify -- graphify-mcp graphify-out/graph.json connects the local MCP server.

The hooks watch Bash|Grep and Read|Glob calls through graphify hook-guard. When a fresh graph exists, the guard adds a reminder to query the graph first.

It never blocks a tool call unless you opt in with hook-guard read --strict, which blocks the first raw read in a session.

Graphify does not silently choose one. In the hosted tools, every match is listed under ambiguous and the result tells you which symbol it used, so you can check that it is the one you meant.

Impact queries behave slightly differently. graphify_impact combines the results for same-named symbols, and the resolved and seeds fields show what went into that answer.

When a name has no exact match, you get an error with similar candidates, or a semantic match instead of an exact one. That is a suggestion, not the symbol you asked for.

The fix is simple. Give the full name, or name the file the symbol lives in.

Because it maps what the code says, not what runs. Anything resolved only at runtime can fall outside a source-level graph.

• Dynamic calls: calls by string name, reflection, getattr, dependency injection and plugin registries.
• Framework wiring: routes, decorators and handlers that a framework invokes may show no caller.
• External callers: another team's service, a cron job or a public API client outside the indexed repositories.
• Generated code and missing inputs: files that were never scanned.
• Missing optional extras: SQL, Terraform and several other languages are parsed only when their extra is installed.
• Stale scans: the graph is a snapshot.

Treat every result as evidence. Open the cited source, check freshness, and use grep for exact strings such as config keys.

Ask the graph what depends on the thing you plan to change. Locally that is one command, and the hosted MCP tools split the job into three steps.

graphify affected "build_from_json"

1. graphify_impact lists the callers and callees directly connected to the symbol.
2. impact_and_risk ranks the riskiest files by combining that with linked test coverage.
3. graphify_tests_for lists tests linked through imports and calls.

Remember the limits. graphify_impact is a first pass covering direct connections, not every transitive effect, and none of these tools run tests or prove a change is safe. Read the code they point to before you edit.

Use the tests list as your starting point: run those first, then widen. If a pull request is already open, the review step covers the same ground automatically.

Two pull requests can both pass review and still collide when they change the same part of the code. graphify prs --conflicts groups open pull requests that share a graph community, which flags merge-order risk.

graphify prs --conflicts
graphify prs --triage
graphify prs 482

It needs the GitHub CLI signed in, and triage reads GRAPHIFY_TRIAGE_BACKEND to pick the model. The result is a risk signal, not a promise of a textual conflict.

A practical routine: run --conflicts before merge day, agree an order for the PRs that share a community, then rebase each remaining branch and rerun tests after every merge. Config and generated files can still collide without showing up in the graph.

The saving comes from reading less. The assistant asks the graph first and opens only the files and lines the answer names.

• Run graphify query before the first grep or source read.
• Cap results with --budget, which defaults to 2000 tokens.
• Filter by edge type with --context call.
• Build with --code-only to skip the paid model passes.
• Exclude bulk folders with .graphifyignore.

To measure it on your own repository, run graphify benchmark. On the Graphify repo it estimated roughly 791 times fewer tokens per query than a naive read-everything baseline.

That figure is an estimate against a deliberately naive baseline, not a measurement of a real session, so expect your own number to vary with repository size.

Locally you merge graph files. In the hosted product you pick repositories with Combine graphs.

graphify merge-graphs first.json second.json --out combined.json
graphify global add graphify-out/graph.json --as my-project
graphify global list

Choose a unique project name when registering globally. graphify global remove undoes a registration.

Across the boundary, Graphify adds edges in two deterministic passes. A call whose receiver type resolves to exactly one declaration in another repository gets a calls edge. Two repositories that declare a type with the same namespace and name are linked with same_type_as.

That second edge links the nodes rather than merging them, so drifted copies of a shared contract stay visible.

A typical use is a web client, an API and an event consumer in separate repositories. After combining them, a path query can cross from a client call into the service that handles it.

graphify export <format> turns the saved graph into other shapes without rebuilding it. The docs cover HTML, JSON and more, so run graphify export with no format to see what your version supports.

graphify export html
graphify export callflow-html --output docs/architecture.html

export html regenerates the interactive visualization on its own. callflow-html writes an architecture call-flow page that you can drop into your docs.

Exports read graph.json, so they are cheap to rerun after an update. The graph holds source-derived context, so check who can see an export before you publish it.

Pick HTML for people and JSON for tools. Both come from the same graph.json, so an export never drifts from the graph it was made from.

Both have dedicated structural extractors, but they sit behind optional extras. Without the extra installed, those files are simply not parsed.

The same applies to R, Erlang, Solidity, OCaml, Common Lisp, VB.NET, DreamMaker and Robot Framework. Everything else works with the default install.

pip install "graphifyy[sql]"
pip install "graphifyy[all]"

The first command adds one extra. The second adds all of them. If a database schema or Terraform module is missing from your graph, a missing extra is the first thing to check.

If you installed with uv tool install, add an extra by reinstalling with it named, for example uv tool install "graphifyy[all]", then rebuild so the new parsers see your files.

Use Graphify when the question is about how code connects. Use grep when you are looking for an exact string. The docs say so directly.

Grep finds text, so it cannot follow a call across files or tell you what depends on a symbol. The graph cannot see string contents it never indexed. Most days you will use both.

Work from the cheapest check to the most involved one.

1. Confirm graphify-out/graph.json exists at the repository root.
2. Confirm the skill and hooks are installed. For Claude Code, look for the ## graphify section in CLAUDE.md and the hooks in .claude/settings.json.
3. Name Graphify in the prompt, for example "Use Graphify to answer".
4. Check freshness. The guard only nudges when the graph is fresh, so run graphify update . or install the hook.
5. For MCP, run /mcp in Claude Code to confirm the server is connected, and install graphifyy[mcp] if it fails to start.
6. For the hosted server, call list_repositories. An empty list means sign-in worked but nothing is indexed.
7. If answers still never cite graph evidence, ask for a specific tool by name, such as query_graph or graphify_callers, and check that the reply carries file paths and line numbers.

First work out which kind of graph you have, because staleness has different causes.

• Local: graph.json is a snapshot. Run graphify check-update . and then graphify update .. For the long term use graphify watch . or graphify hook install.
• Hosted: the graph reflects the default branch only. Code on a feature branch or uncommitted work is not in it.

On the hosted side, call graph_stats to see whether the repository is indexed and how old the commit is. Results also carry a freshness field. If the repository shows Out of date, start a reindex from the console.

Before editing, read the local files the graph pointed to. Your checkout can be ahead of the index.

For a local graph, also confirm the hook is still present with graphify hook status. A missing hook is a common reason a graph drifts without anyone noticing.

An empty list only describes the indexed graph. It says the index found no callers, not that none exist.

Several things hide real callers: dynamic dispatch and reflection, framework wiring, external consumers such as another team's service, and an index that is out of date.

There is also a default to know about. graphify_callers returns only resolved call edges unless you ask for strict_calls=false, which includes inferred ones.

Before deleting anything, search for dynamic usage and external consumers, then confirm the graph is fresh. The console's dead-code findings ask for the same check.

A better signal combines several checks: callers from the graph, graphify_references for non-call uses such as reads and mentions, linked tests, and a plain text search for the name in config and scripts.

They build the same kind of graph. The difference is who runs it and what sits around it.

The engine is free and needs no account. The hosted product has a Free plan covering up to 3 indexed repositories, with Pro and Teams above it.

With OAuth in a browser. There is no API key. A person finishes the sign-in once, then the client refreshes tokens on its own.

sequenceDiagram
  participant A as Agent
  participant B as Browser
  participant S as Graphify MCP server
  A->>S: Connect to the MCP endpoint
  S-->>A: 401, sign-in needed
  A->>B: Person opens the sign-in link
  B->>S: OAuth authorization code with PKCE
  S-->>A: Access token and refresh token
  A->>S: Tool calls with the access token
  A->>S: Refresh when the token expires
  S-->>A: New access token and rotated refresh token

Each refresh rotates the refresh token, so a client that reuses an old one must sign in again. There is no device-code or client-credentials flow, which means a headless agent cannot sign itself in.

On a 401 an agent should tell the person which sign-in step to run and stop, not retry in a loop. Limits are 240 requests a minute per client IP and a 256 KB body. For fully headless use, self-host the open-source MCP server behind an API key you control.

In setups with more than one workspace, set_workspace binds a session to one for 24 hours by default. A bot that runs longer should call list_workspaces to check which one is active.

Only a push to the default branch starts a new index. Everything else leaves the graph alone.

flowchart TD
  A["Push or pull request event"] --> B{Default branch push?}
  B -- Yes --> C["Index that commit"]
  B -- No --> D{Pull request?}
  D -- Yes --> E["No new graph, review uses default-branch graph plus diff"]
  D -- No --> F["Nothing happens"]

Only one index of a repository runs at a time, and a later push waits or joins the queued build. A newly connected repository stays Paused and Not indexed until you switch indexing on. Hosted plans can cap push-triggered indexes per UTC day, while a manual reindex does not count.

A change on a feature branch is therefore invisible to hosted queries until it merges. Each result carries a freshness field with the indexed commit and its age, so you can tell when an answer predates your latest merge.

It reviews against the graph, so a finding can point past the diff to the callers and dependencies a change reaches. Reviews are advisory and never block a merge.

1. A review runs when a pull request is opened, reopened or marked ready for review. A draft waits.
2. Later pushes do not start a new review. Comment @graphify review to review the current head. It works for owners, members and collaborators.
3. The review uses the indexed default-branch graph plus the pull request's diff. It does not index the PR branch.
4. Read findings in Reviews, along with optional advisory sections on risky patterns and possibly stale docs.

You can teach it by replying on the pull request:

• @graphify wrong <finding> dismisses a false positive.
• @graphify good <finding> confirms a useful finding.
• @graphify suppress <rule> mutes a rule, optionally for one path.

It compares a changed function with its previous version and either proves they behave the same within a checked range or finds a concrete input that gives a different result. This is called equivalence checking, and it needs no written spec.

Because proofs are bounded, there are five outcomes rather than pass and fail:

The check compares against the merge base, runs on every push, and appears as an advisory check on GitHub that never blocks a merge. It is GitHub-only for now and can be toggled per repository.

One catch applies to equivalence in general: if the old code had a bug, an equivalent new version has it too.

Memory keeps what the team and its agents learn about the code, so the next session does not start from zero. Three MCP tools drive it.

A saved fact starts as a suggestion that waits for review. Once you keep it in the Memory page it becomes a reviewed memory that every connected agent can recall. Agents should ask before calling remember.

Graphify also records reviews, verifications and merged pull requests automatically, in plain language, with one-click undo.

Start from the split between the two data paths. The code parse is local and never sends files to a model. The open-source engine also has no cloud backend and sends no telemetry.

The risk sits in semantic extraction, which may send its input to the provider you select. Control it like this:

• Use --code-only when nothing may leave the machine.
• Use a local backend such as --backend ollama for documents.
• Add secrets and sensitive folders to .graphifyignore.
• Skip model-generated community names with --no-label.

Finally, treat graph.json and the report like source code, since they hold labels and context from your repository. The hosted product builds the graph for the repositories you connect, so choose those deliberately.

Do a quick audit before committing graphify-out/. Labels and report text come from your code, so they can contain internal names you did not intend to publish.

Shrink the input first, then keep refreshes incremental, then keep queries small.

1. Ignore bulk. Put vendor/, node_modules/, dist/ and generated code in .graphifyignore.
2. Start structural. Run graphify extract . --code-only for a fast, model-free first graph.
3. Stay incremental. Use graphify update ., watch or hook install instead of full rebuilds.
4. Separate worktrees. Set GRAPHIFY_OUT per worktree so graphs do not collide.
5. Query narrowly. Name a subsystem, filter with --context call and cap output with --budget.

For CI and teams, build the graph in a job and post pull request impact from it, or self-host a shared MCP server over HTTP. On hosted Graphify, prefer query_graph over the canvas for very large graphs, since the console can decline to draw one that is too large to display.