MCP Server

hounddog mcp [path] runs an MCP (Model Context Protocol) server over stdio that serves two categories of insights to connected coding agents:

• The API catalog — gRPC and Thrift services, methods, server implementations, and client call sites.
• Dataflows — sensitive data reaching data sinks, with AI review verdicts, privacy violations, and remediation guidance.

One server instance serves the repository containing path (default: the current directory). The insights come from the local scan state store, so agents get deterministic, precomputed context instead of rediscovering it by grepping the codebase on every prompt.

Client Configuration

bash

# Claude Code (per project)
claude mcp add hounddog -- hounddog mcp

For any other MCP client, configure a stdio transport:

{ "command": "hounddog", "args": ["mcp"] }

Global CLI flags (--no-cloud, --debug, and so on) work as usual and are forwarded to scans triggered through the run_scan tool, except that uploads are always disabled for those scans.

The server needs no API key and no prior scan to start: it opens the local scan state store read-only on every call, warns and keeps running when there is nothing to read, and falls back to the bundled rules when the Cloud Platform is unreachable — so it works fully offline.

Freshness Model

Tools serve the most recent stored scan; nothing scans implicitly. Every response embeds a scan_context with the repository, branch, last scan metadata (commit, timings, scanner version), the current HEAD commit, a scanned_commit_matches_head staleness signal, and a hint telling the agent what to do next. The run_scan tool refreshes the results on demand — differential scanning makes repeat scans of a lightly edited repository fast. The git branch is re-resolved on every tool call, so branch switches mid-session are handled.

Tools

Tool	Parameters	Purpose
get_scan_status	—	Store state, last scan metadata, tracked file count, added/changed/deleted counts since the scan, and stored result counts. The entry point for a fresh session.
run_scan	—	Produce or refresh the stored results every other tool reads (differential when possible). Reports success, duration, the pre-scan added/changed/deleted counts, and refreshed result counts; a failed scan returns its full error chain instead of failing the tool call.
list_api_services	protocol? (grpc | thrift), name_contains?	Catalog services with definition location, method/server/client counts, implementation languages, and the count and maximum severity of sensitive dataflows into each service.
get_api_service	full_name, protocol?, client_offset? (default 0; 100 client call sites per page)	One service in full: methods with IDL definition locations, server implementation sites, paged client call sites, and the sensitive dataflows reaching each method.
list_dataflows	min_severity?, data_element?, data_element_tag?, data_sink?, file_path?, api_service?, api_protocol?, vulnerable_only?, include_ignored?, limit? (default 50, max 200), offset? (default 0)	Open dataflows sorted by effective severity, with sink, data elements, location, and API service attribution.
get_dataflow	hash	Full detail for one dataflow: offending code, data elements with traces, endpoints, CWE/OWASP/privacy references, remediation guidance, and the AI review verdict.

Severity filters and sorting use the effective severity: an AI review verdict overrides the scanner-derived severity, and ignored dataflows — AI-review false positives and dataflows excluded by your rules — are omitted unless include_ignored is set. The data_sink filter matches parent sinks against their children (filtering by aws matches aws-dynamodb), like filtering everywhere else in the product.

Dataflow findings are presented to agents as static-analysis leads to investigate, not confirmed problems — the tool descriptions instruct agents to read the code at each location and judge whether a finding is a real issue before acting on it.

Behavior Notes

• Scan rules are loaded once at server startup (bundled defaults merged with your organization’s cloud rules). Restart the server to pick up rule changes; when the cloud is unreachable, the server falls back to the bundled defaults.
• run_scan never uploads. An MCP-triggered scan runs with the CLI’s defaults and your environment (API key, HOUNDDOG_AI_*), but results are never uploaded to the Cloud Platform as a side effect of a tool call. Concurrent run_scan calls are serialized.
• First scans can be slow. A first scan of a large repository (or one with AI review configured) can exceed MCP client tool timeouts; run hounddog scan manually once in that case.
• Non-git directories are supported: without usable git metadata the server serves the directory as-is (--no-git forces this mode).