Add analytics to Cline.
Cline is an autonomous coding agent inside VS Code and it speaks MCP, so it can read your real numbers instead of guessing at what shipped. You add smolanalytics as one remote MCP server in cline_mcp_settings.json, and that single connection reaches every project in your org: pass project="checkout" to any of the 79 tools and it routes there, while each project's read key stays server-side.
// Cline panel > MCP Servers icon > Configure > "Configure MCP Servers" opens the file.
// Recent Cline keeps it in a shared data dir, not the VS Code extension folder:
// ~/.cline/data/settings/cline_mcp_settings.json
// Older builds kept it in the extension globalStorage and migrate it forward on upgrade,
// so open it with that button instead of guessing the path for your version.
{
"mcpServers": {
"smolanalytics": {
"type": "streamableHttp",
"url": "https://smolanalytics.com/api/mcp",
"headers": { "Authorization": "Bearer ORG_TOKEN" },
"disabled": false,
"autoApprove": []
}
}
}The file is plain JSON, so drop the comment lines. "type": "streamableHttp" is exact camelCase: leave it out and Cline can fall back to the older SSE transport, which fails like a broken server rather than a config typo. ORG_TOKEN is your organization API token from Settings. Self-hosting instead? smolanalytics connect cline writes this block for you.
how do I add analytics to cline?
Cline is an autonomous coding agent inside VS Code and it speaks MCP, so it can read your real numbers instead of guessing at what shipped. You add smolanalytics as one remote MCP server in cline_mcp_settings.json, and that single connection reaches every project in your org: pass project="checkout" to any of the 79 tools and it routes there, while each project's read key stays server-side.
The Cline-specific parts are the dialect and the approvals. The streamableHttp type is the one people get wrong, and the failure looks like a server problem rather than a config typo. The other one worth setting is autoApprove: list the read-only report tools there (start with overview) and Cline stops asking permission every time it checks a number, which matters because it will call several tools before it answers you. Keep your event names in a .clinerules/ file, something like analytics.md, so the plan Cline proposes uses the same names the code ends up firing and the same names you query later.
Instrumenting is where Cline earns its keep. In Plan mode it reads the repo and proposes where the events belong, in Act mode it makes the edits as diffs you approve file by file, so tracking lands at the real call sites instead of a pile of copy-pasted track calls. Prefer not to do it in the editor at all? Connect the repo on smolanalytics and we open the instrumentation PR ourselves, and you review it in VS Code like any other PR.
Why the answers hold up: the tools are deterministic computed reports, not LLM-generated SQL, and a CI test pins the /v1 API, the MCP tools and the dashboard to the same answer for the same question, so Cline cannot report a number it never computed. Your own model does the reasoning, so asking is never metered by us. 14-day full trial with no card, then Pro is $49/mo for 1M events or Scale $149/mo for 10M, $8 per extra million, and self-hosting the single MIT Go 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 Cline tonight.
One snippet, or one endpoint. Tomorrow morning the verdict tells you which part of the funnel to fix.