Why an agent needs OpenCodeHub

What an agent cannot see without it

A coding agent’s default tools — Read, Grep, Glob — see one file at a time. They cannot answer:

• Which symbols call this function across the repo, transitively?
• If I rename this type, which test files and which call sites move?
• What HTTP route is wired to this handler?
• Which services in the group consume this API, and at what version?

These are graph questions. Text search returns false positives (a matching string in a comment), false negatives (a re-exported symbol under a different name), and no ranking by structural distance.

OpenCodeHub answers them with a hybrid structural + semantic graph built from your repo and queried over MCP. The agent gets a deterministic, blast-radius-aware answer in one tool call.

Three concrete failure modes

1. Missed dependencies

Agent edits a function. Its callers in three other packages break at runtime because Grep missed the imports re-exported via barrel files.

2. Broken call chains

Agent renames a method. Two stale references in dynamic dispatch sites ship to production unchanged because regex rename does not understand inheritance.

3. Blind edits

Agent touches a hot path with no idea this function sits on every request the API serves. No risk tier, no review escalation, merged.

impact, detect_changes, and verdict close all three — the agent sees the blast radius and the affected diff before it writes the edit.

What changes after codehub init

The agent gets 28 MCP tools at the next session start, grouped into four families. Every tool is read-only with respect to your source — they tell the agent what a change touches; the agent (or your editor) makes the edit:

• Exploration — query, context, impact, detect_changes, sql, list_repos. Concept-to-code search; per-symbol callers, callees, and processes; blast-radius depth-N.
• Cross-repo groups — group_list, group_query, group_status, group_contracts, group_cross_repo_links, group_sync. Federate the same questions across a named set of repos.
• Findings and verdicts — scan, list_findings, list_findings_delta, list_dead_code, license_audit, verdict, risk_trends. Scanner output, PR decisions, license tiers, dead-code listing.
• HTTP and routing — route_map, api_impact, shape_check, tool_map. HTTP routes and handlers; structural drift in payloads; CLI/MCP tool surfaces.
• Meta — project_profile, dependencies, owners, pack_codebase. Repo overview, external deps, top contributors, deterministic code-pack for context windows.

Every per-repo response includes a next_steps array and a _meta.codehub/staleness hint when the index might be behind HEAD.

Tool decision matrix Pick the right tool for the intent at hand.