Deterministic static analysis builds a continuously fresh inventory of every service, every API, every field, and every downstream consumer. Centralized across your org, or local on a single repo. Used by platform engineers, technical PMs, and AI coding agents.
API schemas describe contracts. They do not describe who consumes them, which fields are still used, or what breaks when something changes. The teams that need that picture most are improvising.
OpenAPI, protobuf, and GraphQL schemas tell you what an API is. They do not tell you which services call it, which fields are touched, or what fails when you change it.
The spreadsheet goes stale the moment a PR merges, and the next planning cycle starts from guesswork.
"Who calls this?" gets asked in Slack and answered with a half-remembered service name. The real answer lives across millions of lines and dozens of repos, with no one source of truth.
The catalog is built by a deterministic static analyzer that reads your code on every pull request. No manual data entry. No nightly batch that lags reality. No "please update the wiki" Slack pings.
Every service in every repo, with language, protocol, and code-owner attribution pulled from the source tree.
Every endpoint, RPC, query, mutation, and field, extracted from protobuf, OpenAPI, GraphQL schemas, and handler code.
For every API, the exact list of services that call it and the line numbers where they call it. No grepping.
A directed graph of service-to-service relationships, queryable through CLI, MCP, or a visual viewer.
Here's an example based on the Google Cloud Online Boutique microservices demo (eleven polyglot microservices, gRPC over protobuf). The protobuf change is one line. The blast radius is what matters.
// shared/protos/demo.proto message Address { string street_address = 1; // deprecated string address_line_1 = 5; string address_line_2 = 6; string city = 2; string state = 3; string country = 4; }
Four services across three teams, two languages, four call sites. Each one needs a PR before street_address can be safely removed.
The catalog is regenerated from source on each PR, not on a schedule and not by hand. Nothing drifts.
A GitHub, GitLab, or Bitbucket integration runs the HoundDog analyzer against the diff and the working tree.
Parses gRPC today, with GraphQL and REST coming soon. Source languages: Python, JavaScript, TypeScript, C#, Go, and Java.
The catalog refreshes in place. AI agents and humans query the same source of truth through CLI, MCP, or a web viewer.
Two deployment models for two scales. Local for individuals and small repos. Centralized for the codebases no developer can keep checked out on a laptop.
The MCP server runs as a local process and indexes whatever code is checked out locally. No infrastructure to stand up. Free.
Cloud or on-premises. Connects directly to GitHub, Bitbucket, or GitLab. Auto-scans every selected repo from your SCM, with no local checkout needed. Developers and AI agents query a centralized catalog that already holds the answer.
See the engine generate the catalog, serve context to a coding agent, and reason about a cross-service change end to end.
Designed against the codebases no laptop can hold: tens of millions of lines, hundreds of services, every language pulling its weight. Indexed centrally, queried per-developer.
The catalog earns its keep before you ever turn on an AI coding agent. Three readers, one source of truth.
Pull request review, migration planning, deprecation hygiene, on-call investigations. Stop asking "who calls this?" in Slack.
Org-wide service inventory, ownership clarity, what we ship to which customer segment. Replace the spreadsheet you keep apologizing for.
Claude Code, Cursor, Codex, and Copilot read the same catalog through a local MCP server. The catalog is what lets them reason about cross-repo change without grep-bombing.
Early access is rolling out now. Bring a real repo. We will help you generate the first catalog the same day.