Coding agents and MCP

Flowhawk is an MCP server. Claude Code, Cursor and other agents can set Flowhawk up, read production data while they write code, and propose changes.

Connect

The server is at https://api.flowhawk.dev/mcp (streamable HTTP). You sign in once in the browser, and the agent then acts as you, with your role in the workspace.

Claude Code

claude mcp add --transport http flowhawk https://api.flowhawk.dev/mcp
# then run /mcp in Claude Code and choose Authenticate

Cursor

In .cursor/mcp.json (this project) or ~/.cursor/mcp.json (all projects):

{
  "mcpServers": {
    "flowhawk": { "url": "https://api.flowhawk.dev/mcp" }
  }
}

Other clients

Any client that supports remote MCP servers over streamable HTTP with OAuth works. Add the URL above. When you connect, the consent page names the workspace the connection is for. To use another workspace, switch to it there first.

CI and clients without a browser

Create an MCP key in Settings > API keys and send it as Authorization: Bearer <key>. A key has a fixed role, viewer or editor, and never more than the role of the person who made it.

Let the agent set Flowhawk up

Ask the agent to "set up Flowhawk". It reads Flowhawk's install guide for each language and adds the SDK to each service with your workspace's addresses, keeping the ingest key in FLOWHAWK_API_KEY. It then drafts your business map from the routes in your code, sends the map to Flowhawk as a proposed change and opens a pull request. Your agent does the code work with your own model budget. You review the pull request and accept the map in the app.

What the agent can do

The tools are the same as those of the agent built into Flowhawk, limited by your role. Viewers get read tools only.

Group	Examples	Changes anything?
Query	`flow_health`, `compare_periods`, `search_logs`, `search_traces`, `query_metric`, read-only `query_sql`, database query insights	No
Context	`setup_status`, `get_incident`, `list_changes`, `get_config`, `seen_before` (past incidents and runbooks), `uptime_checks`	No
Config	`propose_change`, then `apply_change` after you confirm the diff; `undo_change`	Only after you confirm
Triage	`update_issue`: resolve, ignore, assign, comment	When you ask (editors)
Actions	`propose_action` (a rollback, a flag change), `approve_action`	Only after a person approves; nobody approves their own client's proposal

Some things to ask while you code: "Is checkout healthy since my last deploy?", "Which queries does the orders service run most, and from where?", "Show the errors in the pay step this morning", "Review this pull request against production".

Safety

Every tool call, and every refused one, is in your workspace's audit log under the person or key that made it.
Config changes are proposals with a diff and a preview. Nothing applies until someone confirms, and every applied change can be undone.
SQL from the agent runs read-only, with time and row limits, and only sees your workspace.