eddy Overview Get early access

For teams building AI agents on their product

Agents that see what they change.

eddy is a hosted analytics database that keeps your product’s metrics current from your Postgres and serves them to your agent over MCP. Every number traces to its source rows, and the agent’s next read sees what it just did.

Nothing installed in your database but one publication and one replication slot; the role needs REPLICATION and SELECT. We onboard every team by hand. How pricing works.

See the product →

01 · The loop

Read, act, and read the result.

A warehouse answers with last night’s numbers, so an agent that acts can’t tell whether it worked. With eddy the write lands in your Postgres and the metric is current again within milliseconds.

1 · readget_view account_healtha snapshot, current to the last commit
2 · explainprovenancethe source rows behind the number
3 · actyour APIa write like any other, into your Postgres
4 · see itget_view againmilliseconds later, the metric has moved

02 · Tools

Every operation is a tool.

Add the workspace’s MCP server to Claude, Claude Code or any MCP client; each person signs in, readers get the reads, and writers you name can change models. The tools are generated from the same HTTP API your app uses.

claude mcp add --transport http eddy https://acme.eddy.example/mcp

Sources: your Postgres and product events from Kafka · the same views over MCP, psql and HTTP

read · every signed-in reader

  • get_views
  • get_view
  • query
  • provenance
  • get_model
  • get_catalog
  • get_graph
  • get_history
  • get_commands
  • get_command
  • get_stats
  • get_table
  • get_profile
  • get_shops
  • preview_model
  • preview_replace
  • model_review
  • model_steps
  • model_step_rows
  • model_step_values
  • model_steps_cost
  • and the rest of the API

write · only the writers you name

  • create_model
  • replace_model
  • drop_model
  • add_table
  • drop_table

eddy never writes to your database: these change eddy’s own model definitions. Each is previewed first, returns a command to poll with get_command (queued, hydrating, ready), and the history records who asked: by: mcp:you@acme.com. Your agent acts on your product through your own API.

03 · In practice

From “why” to “done” in one conversation.

Asked which accounts are at risk, the agent reads the view, traces the number to fourteen deleted seats, restores them through your API, and reads the view again.

Which accounts are at risk this week, and why?
eddyget_view account_health · risk = 'high'3 rows
eddyprovenance account_health · id = 5714 seats · 31 events
Contoso (#57) is high risk: usage fell after 14 seats were removed in one statement on Sep 22. It looks like a mistake; I’ll restore them.
your APIrestore_seats(account_id = 57)committed
eddyget_view account_health · id = 57high → watch
Done. The restored seats are already reflected in account_health.

04 · Trust

Numbers an agent can defend.

Every number comes with where it came from, and every metric is checked against Postgres after every transaction. An agent that changes a model sees what the change does to the data before anything changes.

0disagreements with Postgres, which recomputes every metric after every transaction in our harness and demo
7 msfrom a commit to every metric fresh, on a 7.2M-row inventory snapshot
0.09 msto read that report; 15.7 s as a plain Postgres view

Keep going

DevelopersBuild with it from your editorThe MCP server, the model lifecycle, and your workspace’s endpoints.SaaS engineering teamsAnalytics inside your productPer-customer metrics your app serves, live, with no warehouse.The productSee every screen up closeThe pipeline, the model workspace, review, provenance and the trace.

Connect your agent to your data.

Tell us what your agent should watch and act on. We’ll connect it to eddy on your own schema.

Get early accessSee the product