$npx -y skills add webflow/webflow-skills --skill site-activityQuery 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 on
| 1 | # Site Activity |
| 2 | |
| 3 | 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. |
| 4 | |
| 5 | ## Important Note |
| 6 | |
| 7 | **ALWAYS use Webflow MCP tools for all operations:** |
| 8 | - Use Webflow MCP's `data_sites_tool` with action `list_sites` for listing available sites |
| 9 | - Use Webflow MCP's `data_sites_tool` with action `get_site` for detailed site information |
| 10 | - Use Webflow MCP's `data_enterprise_tool` with action `list_site_activity_logs` for retrieving activity log events |
| 11 | - Use Webflow MCP's `webflow_guide_tool` to get best practices before starting |
| 12 | - DO NOT use any other tools or methods for Webflow operations |
| 13 | - All tool calls must include the required `context` parameter (15-25 words, third-person perspective) |
| 14 | |
| 15 | **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. |
| 16 | |
| 17 | **Tool Parameters for `list_site_activity_logs`:** |
| 18 | - `site_id` (required): The site's unique identifier |
| 19 | - `limit` (optional): Maximum records to return (max 100) |
| 20 | - `offset` (optional): Pagination offset for fetching beyond the first page |
| 21 | |
| 22 | ## Instructions |
| 23 | |
| 24 | ### Phase 1: Site Selection & Context |
| 25 | 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`. |
| 26 | |
| 27 | **Sort order**: |
| 28 | 1. ⚠️ sites (unpublished changes) before ✅ sites (up to date) |
| 29 | 2. Within each group, most recently updated first (by `lastUpdated` descending) |
| 30 | |
| 31 | **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. |
| 32 | |
| 33 | Present the list in this exact format: |
| 34 | |
| 35 | ``` |
| 36 | 📋 Site Activity — Site Selection |
| 37 | |
| 38 | Available Enterprise Sites: |
| 39 | |
| 40 | 1. <Site Name> ⚠️ — last published <short date>, updated <short date> (<N> days unpublished) |
| 41 | 2. <Site Name> ✅ — published & updated <short date> |
| 42 | 3. <Site Name> ⚠️ — never published, updated <short date> |
| 43 | |
| 44 | …and 4 more sites. Reply "show all" to see the rest. |
| 45 | |
| 46 | Which site would you like to review? |
| 47 | ``` |
| 48 | |
| 49 | Format rules: |
| 50 | - Dates: abbreviated ("Mar 6", "Apr 14"). Add the year only if it isn't the current year. |
| 51 | - Use ⚠️ when `lastUpdated > lastPublished` OR `lastPublished` is null; ✅ when `lastUpdated <= lastPublished`. |
| 52 | - When `lastPublished == lastUpdated`, collapse the right-hand side to "published & updated <date>". |
| 53 | - Omit the "…and N more sites" line when the workspace has 10 or fewer sites. |
| 54 | - Do not omit the status flag or the dates — they are required for every site. |
| 55 | 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: |
| 56 | - Custom domains |
| 57 | - Locale / localization settings |
| 58 | - Any additional site metadata needed for the analysis |
| 59 | |
| 60 | `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. |
| 61 | 3. **Infer intent from the prompt** (do not ask a follow-up question if the prompt is clear). Map the request to one of: |
| 62 | - Recent activity summary ("what changed this week?") |
| 63 | - Specific user's activity ("what did Sarah change?") |
| 64 | - Specific activity type ("any CMS changes recently?") |
| 65 | - Pre-publish review ("what's changed since last publish?") |
| 66 | - General overview (default when the prompt is ambiguous) |
| 67 | |
| 68 | 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). |
| 69 | |
| 70 | ### Phase 2: Fetch Activity Logs |
| 71 | 4. **Fetch activity logs**: Use `list_site_activity_logs` with the site ID |
| 72 | - Default to `limit: 100` (maximum per request) for comprehensive results |
| 73 | - The API returns events in reverse chronological order (newest first) |
| 74 | 5. **Handle pagination**: If the user needs older activity or the results suggest more data exists: |
| 75 | - Use `offset` parameter to fetch additional pages |
| 76 | - Combine results across pages for analysis |
| 77 | - Warn the user if going back further than available data |
| 78 | |
| 79 | ### Phase 3: Analysis & Summarization |
| 80 | 6. **Parse each activity log entry**: Each eve |