api-patterns
3CX's native PBX MCP server: the per-PBX endpoint shape (every PBX is its own FQDN and its own OAuth authorization server — there is no shared mcp.3cx.com),…
PostHog cohorts (saved user/group segments), raw analytics events, and timeline annotations. Read-only lookups — listing and retrieving existing records, not defining new segments or emitting events.
$ npx -y skills add wyre-technology/msp-claude-plugins --skill cohorts-and-events --agent claude-codeHow it fires
How this skill gets triggered: by you, by Claude, or both.
/cohorts-and-eventsContext preview
The summary Claude sees to decide when to auto-load this skill.
PostHog cohorts (saved user/group segments), raw analytics events, and timeline annotations. Read-only lookups — listing and retrieving existing records, not defining new segments or emitting events.
name: "PostHog Cohorts & Events" description: > PostHog cohorts (saved user/group segments), raw analytics events, and timeline annotations. Read-only lookups — listing and retrieving existing records, not defining new segments or emitting events. when_to_use: >- When looking up a saved user segment, raw event activity, or a timeline annotation in PostHog. Use when: posthog cohort, posthog event, posthog annotation, user segment, event query, cohort membership, or deploy marker.
A cohort is a saved segment of users or groups — static (a fixed list) or dynamic (defined by a rule that PostHog re-evaluates). Events are the raw analytics stream: every tracked interaction, tied to a person or `distinct_id`, carrying whatever properties the client's application sent. Annotations are timestamped notes on a project's timeline — deploys, incidents, config changes — used to explain a shift in a metric. This skill covers looking these up, not defining them.
into a trend; use `insights-and-dashboards`, which is what PostHog's own computed insights are for.
skill only covers listing and retrieving cohorts and events themselves; use `feature-flags-and-experiments` for what a flag or experiment is configured to target.
Cohorts group people or groups by shared property or behavior. Events carry an event name, a `distinct_id`, a timestamp, and a properties payload whose shape depends entirely on what the client's application instruments — PostHog imposes no fixed schema on event properties. Annotations are lightweight, timestamped, and scoped to a project (or a specific insight), and exist specifically so a human reviewing a metric later can see "what changed here."
The confirmed read tool family for this domain:
This plugin exposes only these read tools; there is no cohort-definition, event-ingestion, or annotation-authoring tool in this plugin's surface. PostHog's own docs carry the exhaustive tool catalog: [posthog.com/docs/model-context-protocol/tools](https://posthog.com/docs/model-context-protocol/tools).
1. List events scoped to the relevant event name (e.g. an error or exception event the client's app emits) and a bounded, recent date range 2. Retrieve individual events for detail if a pattern needs closer inspection 3. Cross-reference against `insights-and-dashboards` if the client already has an error-tracking dashboard — don't re-derive a trend PostHog has already computed
1. List annotations on the relevant project or insight for the reported time window 2. Match a deploy or config-change annotation against the metric shift the client is asking about 3. Report the correlation, not a causal claim — this skill surfaces timeline markers, it doesn't establish root cause
1. Retrieve the cohort in question 2. Check whether the reported user/`distinct_id` matches the cohort's current membership 3. Note that dynamic cohorts re-evaluate — membership can have changed since the client last checked
user IDs, or other identifying data depends entirely on what the client's application sends — this plugin has no way to know in advance. Treat event and cohort output as potentially sensitive by default; see [GOVERNANCE.md](../../GOVERNANCE.md), *Data handling*.
large; an unbounded pull is a way to exhaust rate limits and return more data than the question needs.
rule re-evaluates over time — "who's in this cohort" answered now may not match what it was when an incident happened.
One command to supercharge Claude Code for MSP workflows. Then restart Claude Code. That's it. Documentation: mcp.wyre.ai
Repo: wyre-technology/msp-claude-plugins
3CX's native PBX MCP server: the per-PBX endpoint shape (every PBX is its own FQDN and its own OAuth authorization server — there is no shared mcp.3cx.com),…
3CX's live-operations surface: read-only visibility into active calls, recordings, voicemail, department and queue membership, and forwarding/presence…
3CX's read-only directory surface: resolving a caller by email or by exact extension, searching the PBX's own phonebooks, searching contacts synced from an…
3CX's system-and-configuration surface: server time, PBX event log and application log search, service status, database schema and the read-only SELECT-only…
Abnormal Security abuse mailbox cases: user-reported email submissions, case statuses and judgments, the case lifecycle, bulk and remediation actions, and…
Abnormal Security message analysis: message retrieval, email header inspection, attachments, sender reputation, delivery context, and SPF/DKIM/DMARC…