Add analytics to Zed.
Zed calls MCP servers context servers and takes remote ones over HTTP, so smolanalytics is one block in your settings.json. That single connection reaches every project in your org: pass project="checkout" to any of the 79 tools and it routes to that project's instance, with the read key kept server-side. Then the Agent Panel can instrument your app and answer questions about it without leaving Zed.
// ~/.config/zed/settings.json (cmd-, on macOS, or the "zed: open settings" command)
// Zed calls MCP servers "context servers". A remote one takes url + headers;
// a local stdio one takes command + args + env instead.
{
"context_servers": {
"smolanalytics": {
"url": "https://smolanalytics.com/api/mcp",
"headers": { "Authorization": "Bearer ORG_TOKEN" }
}
}
}Zed's settings.json allows comments, so this pastes in as-is. Check it took under Settings > AI > MCP Servers: the dot next to smolanalytics goes green when the server is actually running, and the tools then show up in the Agent Panel.
how do I add analytics to zed?
Zed calls MCP servers context servers and takes remote ones over HTTP, so smolanalytics is one block in your settings.json. That single connection reaches every project in your org: pass project="checkout" to any of the 79 tools and it routes to that project's instance, with the read key kept server-side. Then the Agent Panel can instrument your app and answer questions about it without leaving Zed.
The Zed-specific detail is the vocabulary and where to look when it silently does nothing. It is context_servers, not mcpServers, and the remote shape is url plus headers, not a command to spawn. Do not trust a clean-looking file: open Settings > AI > MCP Servers and confirm the indicator is green, because a wrong key parses fine and just never connects.
Zed reads a .rules file at the worktree root (then .cursorrules, .windsurfrules, .clinerules, .github/copilot-instructions.md, AGENT.md, AGENTS.md, CLAUDE.md, first match wins), and that is the right home for your tracking plan: the event names, what counts as activation, which properties are required. Now the agent uses the same names when it writes track calls and when it queries them back, so asking whether checkout_started is still firing resolves to the event that actually exists. For the install itself the agent drops the script tag in your root layout and puts track() at the real call sites, or you connect the repo on smolanalytics and we open the instrumentation PR for you to review in Zed.
Zed is built around not waiting, so the point is never opening a dashboard tab. One connection covers the whole org: create_project provisions a new project without a browser, and project="<name>" routes any tool to it. Answers are computed reports rather than generated SQL, and a CI agreement test asserts the editor's number equals the dashboard's for the same question. You bring your own model, so asking costs nothing extra. 14-day full trial with no card, then $49/mo for 1M events or $149/mo for 10M, and the self-hosted binary is free forever.
Honest pricing: 14-day full trial, no credit card. Then Pro $49/mo, never metered on seats or sites. Overage is $8/million with an emailed receipt, the dashboard never locks, and self-hosting the single Go binary is free forever (MIT).
Add analytics to Zed tonight.
One snippet, or one endpoint. Tomorrow morning the verdict tells you which part of the funnel to fix.