changelog
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| POSTHOG_HOST | No | PostHog host URL. Use https://eu.posthog.com for EU cloud. | https://us.posthog.com |
| POSTHOG_PROJECT_ID | Yes | Numeric PostHog project ID, found in the PostHog project URL. | |
| CHANGELOG_TELEMETRY | No | Set to '1' to opt in to anonymous telemetry. | off |
| CHANGELOG_TELEMETRY_URL | No | URL where telemetry counts are sent. Without it, telemetry is a no-op. | |
| CHANGELOG_OPERATOR_HOSTS | No | Comma-separated SQL LIKE patterns used to exclude operator traffic at the person level. Set to empty string to disable. | localhost%,%.vercel.app |
| POSTHOG_PERSONAL_API_KEY | Yes | PostHog personal API key (starts with phx_). Required for authentication; needs scopes annotation:read, annotation:write, query:read. | |
| CHANGELOG_EVENT_VALID_FROM | No | Comma-separated event:YYYY-MM-DD pairs marking the start of trustworthy history for events. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| log_changeA | Record ONE user-visible product change as a PostHog annotation so it can be graded later. Log only changes a user could notice: pricing, copy, onboarding, packaging, email, channel. Never log refactors, dependency bumps, tests, infra, CI, or internal tooling. One change per call — never batch. Non-code changes count and matter most: a price change announced in a chat session logs exactly as well as a merged PR does. If unsure whether something qualifies, ask the user once; never log speculatively. |
| check_changesA | Return a verdict for each logged change: moved, did not move, or cannot tell yet. Computes the minimum detectable effect from the project's real baseline before reporting anything, excludes operator traffic at the person level, prefers the metric closest to the change over the revenue metric, and refuses to grade changes that overlap in time on the same metric. Returns "cannot tell yet" rather than "did not move" whenever the data could not have detected a meaningful change. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 2 tools
log_change records a new change while check_changes evaluates already-logged changes. They operate on different phases of the same lifecycle, so there is no practical ambiguity about which tool to call.
Both tool names follow a clear verb_noun pattern: log_change and check_changes. The naming style is consistent and immediately communicates each tool's action.
Two tools is below the typical 3-15 range, but the server is narrowly scoped to logging and evaluating changes. Each tool is necessary and the pair covers the full intended workflow without redundancy.
The server covers the complete lifecycle for its stated purpose: log a user-visible change, then check whether that change moved a metric. There are no obvious dead ends or missing operations for this narrow domain.