/site-activity

name: webflow-mcp:site-activity
description: Query and summarize site activity logs for a Webflow enterprise site. Surfaces recent changes, identifies who made them, and generates human-readable activity reports. Use for site monitoring, change tracking, publish preparation, or weekly activity summaries. Enterprise plans only.

Site Activity

Query, analyze, and summarize Webflow site activity logs for enterprise sites. Provides natural-language querying of recent changes, filtered summaries by event type or user, and formatted reports for team sharing.

Important Note

**ALWAYS use Webflow MCP tools for all operations:**

• Use Webflow MCP's `data_sites_tool` with action `list_sites` for listing available sites
• Use Webflow MCP's `data_sites_tool` with action `get_site` for detailed site information
• Use Webflow MCP's `data_enterprise_tool` with action `list_site_activity_logs` for retrieving activity log events
• Use Webflow MCP's `webflow_guide_tool` to get best practices before starting
• DO NOT use any other tools or methods for Webflow operations
• All tool calls must include the required `context` parameter (15-25 words, third-person perspective)

**Enterprise Only:** Activity logs are only available for sites on Enterprise hosting plans. If the tool returns an error, inform the user that this feature requires an Enterprise plan.

**Tool Parameters for `list_site_activity_logs`:**

• `site_id` (required): The site's unique identifier
• `limit` (optional): Maximum records to return (max 100)
• `offset` (optional): Pagination offset for fetching beyond the first page

Instructions

Phase 1: Site Selection & Context

1. **Identify target site**: If the user does not provide a site ID, use `data_sites_tool` with action `list_sites`. Each site in the response has `displayName`, `lastPublished`, and `lastUpdated`.

**Sort order**: 1. ⚠️ sites (unpublished changes) before ✅ sites (up to date) 2. Within each group, most recently updated first (by `lastUpdated` descending)

**Truncation**: Show the top **10** sites only. If there are more than 10 total, append a line `…and N more sites. Reply "show all" to see the rest.` below the list. When the user replies "show all" (or similar), re-present the full list in the same format.

Present the list in this exact format:

    📋 Site Activity — Site Selection

    Available Enterprise Sites:

    1. <Site Name> ⚠️  — last published <short date>, updated <short date> (<N> days unpublished)
    2. <Site Name> ✅  — published & updated <short date>
    3. <Site Name> ⚠️  — never published, updated <short date>

    …and 4 more sites. Reply "show all" to see the rest.

    Which site would you like to review?

Format rules:

• Dates: abbreviated ("Mar 6", "Apr 14"). Add the year only if it isn't the current year.
• Use ⚠️ when `lastUpdated > lastPublished` OR `lastPublished` is null; ✅ when `lastUpdated <= lastPublished`.
• When `lastPublished == lastUpdated`, collapse the right-hand side to "published & updated <date>".
• Omit the "…and N more sites" line when the workspace has 10 or fewer sites.
• Do not omit the status flag or the dates — they are required for every site.

2. **Fetch selected-site details**: After the user selects a site (or when a site ID was provided up front), call `data_sites_tool` with action `get_site` **once, for the selected site only**, to retrieve fields not returned by `list_sites` — in particular:

• Custom domains
• Locale / localization settings
• Any additional site metadata needed for the analysis

`lastPublished` and `lastUpdated` are already known from step 1 (or from `get_site` if the user provided a site ID directly). Keep these in memory for the pre-publish filter in Phase 3. 3. **Infer intent from the prompt** (do not ask a follow-up question if the prompt is clear). Map the request to one of:

• Recent activity summary ("what changed this week?")
• Specific user's activity ("what did Sarah change?")
• Specific activity type ("any CMS changes recently?")
• Pre-publish review ("what's changed since last publish?")
• General overview (default when the prompt is ambiguous)

Only ask a clarifying question if the request is genuinely ambiguous (e.g., "show me activity" with no time window, user, or event type context).

Phase 2: Fetch Activity Logs

4. **Fetch activity logs**: Use `list_site_activity_logs` with the site ID

• Default to `limit: 100` (maximum per request) for comprehensive results
• The API returns events in reverse chronological order (newest first)

5. **Handle pagination**: If the user needs older activity or the results suggest more data exists:

• Use `offset` parameter to fetch additional pages
• Combine results across pages for analysis
• Warn the user if going back further than available data

Phase 3: Analysis & Summarization

6. **Parse each activity log entry**: Each event contains:

• `id`: Unique event identifier
• `createdOn`: Timestamp (ISO 8601)
• `lastUpdated`: Last update timestamp
• `event`: Event type string (see Event Types below)
• `user`: Object with `id` and `displayName` (absent for system events like backups)
• `resourceOperation`: The operation performed (`CREATED`, `MODIFIED`, `DELETED`)
• `resourceId`: ID of the affected resource (when applicable)
• `resourceName`: Human-readable name of the affected resource
• `payload`: Additional event-specific details (see Payload Details below)

7. **Categorize events** into human-readable groups (41 event types):

**Page Changes:**

• `page_dom_modified` — Page structure/element changes
• `page_created` — New page creation
• `page_deleted` — Page deletion
• `page_duplicated` — Page duplication
• `page_renamed` — Page rename
• `page_settings_modified` — Page settings updates (SEO, slug, etc.)
• `page_custom_code_modified` — Page-lev