Why not just grep?

For a few repositories, grep is probably enough. This page says where Wirecheck helps, where it does not, and exactly what its results mean.

When you do not need Wirecheck

• Your repositories live in one checkout and you can search them all.
• You change shared credentials or MCP servers rarely, and by hand.
• The name you are changing is unique enough to search for in every repo.
• Your agent already has the other repositories available and you are happy to have it search them each time.

Why not ripgrep or GitHub code search?

They find text, and for any single pattern they find at least as much as Wirecheck. Wirecheck recognizes fewer patterns than grep. What it adds is a stored result: each finding is a file-to-dependency relationship with a file and line, kept per scan, so you can query it later, compare two scans, and re-check after a change without redoing the search.

Why can't my agent search my other repositories?

It can, when it has access to them. The cost is repeating the search for each change and each repository, and nothing is kept afterward. Wirecheck gives the agent the stored result from the last scan, with a freshness timestamp. The agent still has to be told to run wirecheck preflight, for example from CLAUDE.md or AGENTS.md. Nothing queries Wirecheck automatically.

Why not write a script?

If you only need to list files that contain a string across four repositories, write the script. Wirecheck is what that script becomes when you also want a persistent graph, scan diffs, baselines, an UNKNOWN state for unresolved references, and verification after a change.

Isn't this another dependency graph?

It is not a package or service graph. It models environment-variable credential references, MCP servers declared in config or referenced inline, the files that use them, and selected webhook routes and cron schedules.

Why trust a scanner that supports selected patterns?

Do not treat “no finding” as proof. Every relationship records a file and line you can open, and the boundaries are published on supported detections, including what is not detected.

What a known consumer means

A consumer is a file with a detected static reference to the target. Known means its path is not UNKNOWN. It does not mean the code is deployed, runs, or uses a live credential. Two repositories that use the same variable name are shown as one dependency.

What the confidence levels mean

• HIGH: a variable that matches a known provider, an MCP server declared in a config file, an inline reference that matches a declaration, a cron schedule, or a file with an SDK import and a tool signal.
• MEDIUM: a credential-shaped name outside the known list, a route path containing “webhook”, a file with no agent signal, or a file with a tool signal but no SDK import.
• LOW: exists in the data model. Current detectors do not assign it.
• UNKNOWN: a recognized MCP reference with no matching declaration. A server with an UNKNOWN reference lists all its consumers as unresolved.