# Funnelkeeper

> The money layer for AI-built products. Funnelkeeper joins ad spend, funnel
> events and revenue to answer one question: did the marketing pay back? An AI
> agent ("the Keeper") watches and proposes; a human approves every action that
> spends money.

Audience: founders of small SaaS and vibe-coded products, and the AI agents
that build for them.

## Install

Dashboard: https://app.funnelkeeper.com/#/signup
CLI: npm i -g funnelkeeper && fk signup
MCP server (stdio): claude mcp add funnelkeeper -e FUNNELKEEPER_API_KEY=fk_live_… -- npx -y funnelkeeper funnelkeeper-mcp
API base: https://funnelkeeper.fly.dev
API contract: https://funnelkeeper.com/openapi.json
Agent-facing page: https://funnelkeeper.com/for-agents/

## Capabilities exposed to agents

- funnel.read — GET /products/{slug}/funnel — stage counts and conversion volumes by channel and date range. Read.
- payback.read — GET /products/{slug}/payback — cohort payback curves plus CAC per channel. Read.
- spend.read — GET /products/{slug}/spend — daily spend by channel and campaign, with caps and whether a cap is binding. Read.
- events.log — POST /distribution — record distribution events performed by the agent (post shipped, listing submitted, email sent). Write.
- budget.propose — POST /products/{slug}/proposals — propose a spend change with rationale and rollback condition. Returns 202 {status: "pending_human"}. Never executes directly.

MCP tool names: get_funnel, get_payback, get_spend, log_distribution,
propose_budget_change, plus portfolio/queue/health reads, product creation,
and source connection (Google sources return a consent URL a human must open).

## Guarantees

- No agent can change spend without a human approval recorded in the app; a database constraint (not application code) blocks proposals from reaching approved without a human on record.
- Every agent call is written to an audit log the user can read, with the acting account, arguments and outcome. Keys are revocable from the dashboard.
- Policy caps are enforced at the API boundary; a proposal above the cap is rejected with 422 {policy_code: "policy_refused"} rather than queued.

## Docs
- [Quickstart for agents](/docs/quickstart-agents.md): executable curl flow — signup, API key, product, source connect, portfolio read
- [API reference](/docs/api.md): every REST endpoint, generated from the server's own schemas
- [CLI reference](/docs/cli.md): the fk command
- [MCP server](/docs/mcp.md): tools, input schemas, install snippets
- [Connecting Google sources](/docs/guides/connecting-google-sources.md): one OAuth grant for GA4/GTM/Google Ads, with the poll contract
- [The action queue](/docs/guides/the-action-queue.md): HITL semantics — approval is a human act
- [How it works](/how-it-works/) · [Compare](/compare/) · [Pricing](/pricing/): free during early access; launch tiers Free / Indie $39/mo / Growth $149/mo

## Data sources read

GA4 (read-only), Google Tag Manager (read-only tag audit), Google Ads (read +
proposals; spend sync pending a developer token, CSV import available), Meta
Ads (read + proposals), SEMrush (read-only, customer's own key), your own
MySQL view (read-only, wired with you during early access).

## Facts

- Unattributed revenue is shown as its own line and is never distributed across paid channels.
- Spend, funnel and revenue appear within an hour of connecting; a payback verdict typically needs two to three weeks of cohort age.
- Proposals expire after 72 hours so no action is taken on stale data.
- Full docs as one file: /llms-full.txt