Dependency context for coding agents

Before your agent changes a dependency, see what else relies on it.

A credential can look unused in the repo your agent is editing while another connected repo still uses it. Wirecheck shows the known consumers with file and line evidence, and what stays unresolved. Re-scan afterward to see what remains.

Test fixture, real CLI output
Agent: remove zendesk-mcp
Edits one repo
5 consumers
3 connected repos
4 remain
after the edit
Pattern-based detection

Regex and JSON parsing. No LLM is involved in detection.

File and line evidence

Every relationship records the file and line of its first match.

UNKNOWN stays visible

A recognized reference with no matching declaration is reported, not dropped.

Re-scan, then verify

Verification reads the latest scans and lists what still references the target.

How it works

Your agent checks the repos it can reach. Wirecheck keeps a record of the ones you connect.

Agents can search several repos when they have access. The cost is doing it again for every change. Wirecheck scans connected repos for supported patterns, stores the results, and lets you query them before and after an edit.

Before

Your agent wants to remove or change a credential or MCP server. Preflight lists the files in your connected repos that reference it.

wirecheck preflight zendesk-mcp --operation REMOVE
During

Each finding carries the file and line behind it, so the agent can check why a reference exists before editing.

wirecheck evidence zendesk-mcp
After

Re-scan, then verify which known or unresolved consumers remain.

wirecheck verify retirement zendesk-mcp --operation REMOVE
Example

The agent removed zendesk-mcp from one repo. Two others still reference it.

Test fixture: real CLI output from three small fixture repos, not customer data.

  1. Agent
    Remove zendesk-mcp.
  2. Edited repo, after the edit
    0 references left.
  3. Wirecheck, before the edit
    5 consumers in 3 connected repos, plus 1 scheduled job.
  4. After the edit and a re-scan
    4 known consumers remain in 2 repos.
    CONSUMERS_REMAIN
Evidence behind the count
  • support-agent: mcp.json:3
    WORKFLOW, MEDIUM
    Removed
  • support-agent: src/support-bot.ts:10
    AGENT, HIGH
    Removed
  • ops-jobs: config/mcp.json:3
    WORKFLOW, MEDIUM
    Still references it
  • ops-jobs: jobs/nightly-ticket-sync.ts:11
    AGENT, HIGH
    Still references it
  • ops-jobs: jobs/nightly-ticket-sync.ts:6
    SCHEDULE (node-cron), HIGH
    Still references it
  • billing-tools: .mcp.json:3
    WORKFLOW, MEDIUM
    Still references it

A consumer is a file with a detected static reference. WORKFLOW is the default type for a file with no agent signal, not necessarily a CI workflow. Wirecheck does not know whether the code runs.

Unknown

No known consumers is not the same as safe.

If a reference to an MCP server matches no declaration, Wirecheck marks the server UNKNOWN and lists its consumers as unresolved, not known. Patterns it does not recognize may not appear at all. See supported detections, or read when grep is enough.

0 known consumers+2 unresolved
Agent workflow

Context before the change. Evidence after.

Your agent only uses Wirecheck if you tell it to. One instruction in CLAUDE.md or AGENTS.md has it run preflight first. See the setup.

wirecheck preflight zendesk-mcp --operation REMOVE
5 direct, 1 indirect, 0 orphaned integrations
Affects: acme/billing-tools, acme/ops-jobs, acme/support-agent
wirecheck verify retirement zendesk-mcp --operation REMOVE
CONSUMERS_REMAIN
4 known consumers still reference this

Output trimmed, from the same test fixture. The CLI runs from the repository today and is not on npm yet. Setup.

Verification ends in one of three outcomes. See what each means.

Pricing

Try it on real code. Keep it current as the code changes.

Explorer
$0

3 lifetime scans, up to 3 repositories.

Pro
$29/month

No lifetime scan limit (50 per 24h), scheduled re-scans, up to 20 repositories, and the retirement queue.

Find out what depends on it before your agent touches it.