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 and Thrift today, with GraphQL and REST coming soon. Source languages: Python, JavaScript, TypeScript, C#, Go, and Java. See the full list of supported languages and protocols.
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.
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.
AI agents are great at reasoning. They are an expensive and inefficient way to repeatedly rediscover deterministic facts about your codebase.
Without precomputed context, every agent has to search files, follow references, inspect protobuf definitions, and reconstruct dependencies before it can start solving the actual problem. Multiply that across developers, prompts, and repositories, and you repeatedly pay for the same discovery in tokens, latency, and compute.
HoundDog.ai separates discovery from reasoning.
The Dataflow Context Engine computes API, field, consumer, and service relationships deterministically, keeps them current as code changes, and makes that evidence available to your existing AI agents through MCP.
AI coding agents are only as useful as the context they can access. In large codebases, that context changes every time services, APIs, fields, consumers, or dependencies change. HoundDog.ai integrates directly into your CI workflows to continuously regenerate this context from source code.
Our fast, deterministic analysis engine runs on standard CPU infrastructure with minimal impact on CI latency. Instead of asking AI agents to repeatedly search repositories and reconstruct the same relationships, HoundDog.ai computes those relationships once and refreshes them as your code changes.
The resulting evidence can power your service catalog, API and gRPC and Thrift discovery, microservices documentation, change blast radius analysis, and organization wide context for AI coding agents.
Through MCP, authorized agents such as Claude Code can query this continuously updated context whenever they need it.
Generate a continuously updated service catalog directly from your code. See every service, API, field, downstream consumer, and dependency across your repositories without spreadsheets, stale documentation, or manual discovery.
Run locally for free, or connect your repositories to give your entire organization one source of truth.