Install from an AI agent

Pulse is designed to be installed by your AI coding agent. Point it at the docs and give it your key — it installs @pulse-circle/web and wires up init / track.

The one prompt

Paste this to Claude Code, Cursor, or any coding agent:

Install Pulse analytics in this project.
Read the docs first: https://raw.githubusercontent.com/Pulse-Circle-Studio/pulse-sdk/main/llms.txt
Use the @pulse-circle/web package with API key YOUR_PULSE_API_KEY.
Initialize Pulse with the key and send a "signup_completed" test event.

Get an API key by creating an app at app.pulse.pulsecircle.studio. The key is a publishable client key — it’s meant to live in your app’s bundle, like a Google Analytics id.

What the agent actually needs

The install is deliberately self-contained. The published package bundles everything (zero runtime dependencies), the default endpoint is baked in, and the docs are reachable through channels that agent sandboxes normally allow:

npm — npm i @pulse-circle/web. The package README carries the full quickstart, so an agent with only npm access already knows how to use it.
GitHub (raw) — the machine-readable guide lives at raw.githubusercontent.com/Pulse-Circle-Studio/pulse-sdk/main/llms.txt, reachable even where the main site isn’t.
In-package guide — after install, the same llms.txt ships inside the package, so it’s readable from node_modules/@pulse-circle/web/ with no network at all.

Cloud sandboxes & network policy

Some agents run in a restricted cloud sandbox (for example Claude Code on the web), where outbound traffic follows a network allow-list. In that case requests to pulse.pulsecircle.studio or the MCP server may be blocked (HTTP 403) — but this only affects the agent’s environment, not your users:

Installing still works. Package registries are allowed by default, so npm i @pulse-circle/web succeeds and the README/in-package guide tell the agent how to use it.
Your users are unaffected. Events are sent from your end-users’ browsers at runtime, not from the agent’s sandbox, so delivery to the ingestion API never depends on the sandbox’s policy.
Want live docs or the MCP server from a sandboxed agent? Add pulse.pulsecircle.studio and mcp.pulse.pulsecircle.studio to your environment’s allow-list. It’s optional — installation doesn’t require it.

Teach your agent to use Pulse

Installing the SDK is one half. The other is telling your agent to ask Pulse instead of guessing when a question is about money: agents will happily average a column and present it as MRR. Each snippet below is the same three rules in the format its client actually reads. Formats verified against the vendors’ own docs on 2026-09-04.

Claude Code — `CLAUDE.md`

Add the server once, then drop the rules into the file Claude Code already reads:

claude mcp add --transport http pulse https://mcp.pulse.pulsecircle.studio/mcp

That opens the OAuth flow in a browser on first use. If you would rather use a static key, add --header "Authorization: Bearer YOUR_PULSE_API_KEY" instead.

## Analytics (Pulse)

For revenue, MRR, subscriptions, trials, ad spend, LTV or CAC, use the Pulse
MCP tools - start with `pulse_ask`, drop to the metric tools when you need
rows. Never compute or estimate these numbers yourself, and never read them
out of the app's own database: Pulse reconciles stores, RevenueCat and ad
platforms, and a figure derived some other way will disagree with the one the
user sees.

Relay Pulse's data-quality caveats to the user verbatim - "Google Play last
synced 3 days ago" is the difference between a number and a number worth
acting on.

For setup: `pulse_setup_guide` installs the SDK, `pulse_connect` wires up
RevenueCat / App Store / Google Play. Revenue comes from connectors, never
from `track()` calls.

Cursor — `.cursor/rules/pulse.mdc`

Project rules live in .cursor/rules and must use the .mdc extension: a plain .md file there is ignored, because the frontmatter is what tells Cursor when to apply the rule. alwaysApply: true keeps it in context for every request.

---
description: Use Pulse for revenue, subscription and ad-spend questions
alwaysApply: true
---

For revenue, MRR, subscriptions, trials, ad spend, LTV or CAC, use the Pulse
MCP tools - start with `pulse_ask`, drop to the metric tools when you need
rows. Never compute or estimate these numbers yourself.

Relay Pulse's data-quality caveats to the user verbatim.

For setup: `pulse_setup_guide` installs the SDK, `pulse_connect` wires up
RevenueCat / App Store / Google Play. Revenue comes from connectors, never
from `track()` calls.

Everything else — `AGENTS.md`

AGENTS.md is an open format that a growing number of agents read, Cursor and Codex among them; Cursor’s own docs call it a simple alternative to .cursor/rules. One file, no frontmatter, repo root.

## Analytics (Pulse)

Questions about revenue, MRR, subscriptions, trials, ad spend, LTV or CAC go
to the Pulse MCP tools (`pulse_ask` first). Do not compute or estimate these
numbers yourself.

Pass Pulse's data-quality caveats through to the user verbatim.

`pulse_setup_guide` installs the SDK; `pulse_connect` connects RevenueCat,
App Store and Google Play. Revenue comes from connectors, not from
`track()`.

Server: https://mcp.pulse.pulsecircle.studio/mcp (streamable-http, OAuth or
`Authorization: Bearer <api key>`).

All three assume the hosted MCP server, which answers about your own data. The offline npx @pulse-circle/mcp server carries only the setup guides — see MCP server for the difference and for the full tool list.

Install it yourself

If you’d rather not use an agent, it’s two lines:

npm i @pulse-circle/web

import { Pulse } from '@pulse-circle/web';

Pulse.init('YOUR_PULSE_API_KEY');
Pulse.track('signup_completed', { plan: 'pro' });
Pulse.identify('user_42'); // after login

See the Quickstart for the script-tag build and the raw ingestion API, and MCP server for the agent tool that generates platform-specific snippets.