Tweetsmash

List the user's Twitter BOOKMARKS — posts they deliberately saved. Never includes X Likes; use list_likes for those. Supports filtering and pagination. Supports filtering by read status, media type, author, tags, date ranges, and sorting options. IMPORTANT: Use this tool (with the 'author' parameter) when the user asks to show tweets by a specific author.

List the posts the user LIKED on X (not their bookmarks). Likes are a lighter signal than a save — use list_bookmarks for things the user deliberately saved, and this when the user explicitly asks about likes or about what they react to. Same filters and pagination as list_bookmarks.

Search through a user's Twitter bookmarks using keyword search (q), semantic search (vector_search_term), or author filtering (author). At least one of q, vector_search_term, or author should be provided. IMPORTANT: Use the 'author' parameter for filtering by author, not the 'q' field.

Get the total count of user's bookmarks with optional filtering. Useful for understanding the size of bookmark collections before listing them.

List all user's labels with their usage counts. Useful for discovering existing labels before adding new ones.

Takes no parameters.

Add a label to a list of tweets. Can use an existing label by ID or create a new label by name. Either label_id or label_name must be provided.

Remove a label from a list of tweets using label_name.

Delete a label from the account entirely — the label itself plus every bookmark's assignment of it. The BOOKMARKS are not deleted; they simply lose this label. IRREVERSIBLE: before calling, tell the user how many bookmarks carry the label (list_labels returns the count) and get an explicit yes. To take a label off SOME bookmarks instead, use remove_labels_from_tweets. If the name matches more than one label the call fails with the candidates — re-run with label_id.

Initialize the vector store for semantic bookmark search. CRITICAL: When vector/semantic search fails with 'Vector Store Not Setup' error, call this tool. This is an async operation that may take a few minutes for large bookmark collections.

Takes no parameters.

START HERE for any open-ended request. Lists the task playbooks this server supports — systematic learning from bookmarks, organising into themes, cleaning up, X-list intelligence, exporting data out, finding a half-remembered save, digests, and diagnosing sync. Each names when to use it; call get_skill for the exact tool sequence.

Takes no parameters.

Get the full playbook for a task: when to use it, the exact tool sequence with the arguments that matter, tips, and the pitfalls that cause empty results. `name` takes EITHER an exact skill name (learn_from_bookmarks, organise_into_themes, cleanup_library, list_intelligence, get_my_data_out, find_that_thing, stay_on_top, diagnose_sync, connect_your_tool) OR a plain description of the job — both resolve. You do NOT need list_skills first: if you already know what the user is trying to do, call this directly with their request and skip the round trip. Reach for list_skills only to browse what exists.

A snapshot of the whole library: total bookmarks, unread, untagged, breakdown by type (threads/media/links/notes), every label with its count, and the years covered. Use this FIRST for anything open-ended (organise, clean up, learn from my saves, 'how many do I have per topic') instead of paging through bookmarks.

Takes no parameters.

Answer questions about Tweetsmash itself — features, how-to, pricing, plans, limits, account/subscription. Searches the bundled product guide and returns the most relevant sections for you to answer from. Call with an empty query to list the help topics.

Get a single saved bookmark with FULL content in one call — the full X Article body, the unrolled thread, notes, and (optionally) replies. Use `include` (comma list of article,thread,notes,replies) to narrow it; defaults to article,thread,notes. Use this when the user wants to read or summarize a specific saved tweet/thread/article in depth.

Add a label to EVERY bookmark matching a filter, in a single call. Prefer this over listing then looping when the user says 'tag all my … as …'. Resolves an author name to its id automatically. Reports matched/tagged/failed counts.

Archive, unarchive, delete, undelete, or mark read/unread a list of bookmarks by id (max 500). This is a bulk write; for destructive actions (delete) confirm with the user first. Reports how many changed.

Apply archive/unarchive/delete/undelete to EVERY bookmark matching a filter, in one call. Destructive by nature — confirm with the user before delete. Reports counts.

List the user's Smart Views (saved filtered views). Each has a slug you pass to the other smart-view tools.

Takes no parameters.

Get a single Smart View by slug (its filter, tabs/buckets, and sort).

List the bookmarks inside a Smart View, optionally scoped to one tab/bucket. Use the returned ids with archive_bookmarks / tagging tools to act on the view.

Create a Smart View from a filter so the user can reuse it. Provide a name and the base_query (filter).

Update a Smart View (name, filter, tabs, sort) by slug.

Delete a Smart View by slug.

Create a public, read-only share link for a set of bookmarks (explicit ids or everything matching a filter). Returns a share_url valid for 7 days. Free plans share up to 10 bookmarks.

Revoke a previously created share link by its token.

Start a PDF export of the user's bookmarks (explicit ids, everything matching a filter, or the whole library). Returns a job id; tell the user the file will appear in the Export Center.

Start a CSV export (explicit ids, a filter, or the whole library). Returns a job id; the file appears in the Export Center.

Start a JSON export (explicit ids, a filter, or the whole library). Returns a job id; the file appears in the Export Center.

List the user's email-digest schedules (frequency, time, paused state) for bookmark and Smart View digests.

Takes no parameters.

Update a digest schedule (enable/pause, frequency, time) by id.

Remove a digest schedule by id.

List past digests sent to the user's email, newest first. This is Digest 1.0 (the cluster pipeline). For the AI-composed Digest 2.0, use list_mash_digests.

Takes no parameters.

The user's Mash Digest 2.0 digests — the AI-composed ones. An account can have SEVERAL (a morning read and an evening skim are two digests, not two sections of one), so START HERE and use the returned `id` for the other digest tools. Returns each digest's name, where its sections read from, and its schedule.

Takes no parameters.

Past issues of the user's Digest 2.0, newest first — what arrived and when. Deliberately WITHOUT the content: pick one and call get_mash_digest_issue for the whole thing. Pass digest_id to narrow to one digest.

One digest issue in full: its title, intro, every section, and per item the summary, why it was picked and why it matters to this user. Use it to answer 'what was in my digest?', 'why was this in there?' or to carry on a conversation about something the user just read. Items carry tweet IDS, not post text — resolve them with get_bookmark if the user asks about a specific post.

Compose one of the user's Digest 2.0 digests NOW rather than waiting for its schedule. SPENDS A DIGEST CREDIT and takes about a minute, so only call it when the user asks for a fresh digest — not to inspect the current one (use get_mash_digest_issue for that). Returns an issue_id to read back once composing finishes.

Show the user's app-sync integrations (Notion, Google Sheets, Zotero): whether each is connected/enabled, synced vs pending counts, and any errors.

Takes no parameters.

Show whether a specific bookmark has synced to a given integration connection.

List the X (Twitter) lists the user follows in Tweetsmash. Returns each list's name plus its `connect_id` — pass that to get_list_tweets / send_list_digest. START HERE for any 'what's in my list' request.

Takes no parameters.

Get recent tweets for a followed X list — the latest, or (sort=POPULARITY) the top/trending tweets in a look-back window. Serves a cached copy when it's fresh and otherwise fetches from X automatically, so it always returns real tweets; `meta.source` says cache or fetched and `meta.cache_age_hours` how old it is. Pass max_age_hours:0 to force a refresh. Get connect_id from list_twitter_lists. hours defaults to 24.

List past Twitter-list email digests for the user.

Takes no parameters.

Build and email a digest of a Twitter list's high-signal tweets to the user now.

Rank a followed X list exactly the way the digest ranker would, WITHOUT sending anything, and show the work: each unit carries its rank_signals (lane_fit = matches what the user builds/studies, affinity = an author they trust, engagement, substance, noise demotions) plus author groups (`group_size` + `related_items` = several posts by one author, best one leading). Use this to answer 'what's worth reading in my list?', 'why was this picked?', or to check how a preference change would land. `meta.inert_dimensions` names signals that had no data for this pool.

The user's stated author preferences for list digests: `boost` = never-miss authors, `hide` = muted authors.

Takes no parameters.

Remember how the user feels about an author in their list digests. action=boost → never miss this author's posts (they will always be included, low-signal ones collapsed rather than dropped); action=hide → mute them; action=clear → forget the preference. Use when the user says things like 'don't let me miss marclou's updates' or 'stop showing me X'. Takes effect from the next digest and in preview_list_ranking immediately.

Get the current user's account: identity, current plan and status, and usage (e.g. AI chat credits). Use this to answer 'who am I' / 'what plan am I on'.

Takes no parameters.

Check whether the user's tweets can be pulled: the X (Twitter) API connection (connected / disconnected), whether the browser extension has synced recently, and a rolled-up can_pull + how (x_api or extension). Use this before a sync, or when the user asks why bookmarks aren't updating. Note: the extension is browser-only and can't be driven by an agent.

Takes no parameters.

Force-pull the user's most recent bookmarks from the X API now (server-side). Requires a connected X account; if the account only syncs via the browser extension, this reports that a browser sync is needed. Use when the user asks to refresh / fetch their latest saves. For Twitter-list freshness, use get_list_tweets instead.

Save a durable PREFERENCE about how this user wants their bookmark library handled — the themes they organise by, topics to exclude, preferred summary length/format, which account is their main one. It carries across sessions AND into the Tweetsmash web app, which your own client memory cannot reach. Use it for lasting preferences the user states or confirms, not for general chat context, task state, or anything secret.

Read back the user's saved library preferences (optionally filtered by a substring). Worth calling before an open-ended organise, summarise or cleanup task so you follow how they already like things done.

Delete a saved library preference by key (optionally narrowed by kind). Use when the user changes their mind or asks you to drop something.

Read what this user is actually interested in, inferred from their saved bookmarks, hand labels, questions and digest clicks — not from anything they typed. Returns topics with a 0-1 strength, whether each is active this week, and a `coverage` field saying how much evidence exists (`lite` means a new account: treat it as a first guess and check before relying on it). Use it to prioritise, filter or explain — then confirm with the user rather than asserting it back as fact. Evidence itself is not returned.

Takes no parameters.

Record the user's correction to an inferred interest, using a key from get_interests. Corrections are sticky — they survive every future recompute. Use `confirm` when they agree, `rename` for their own wording, `hide` to stop using an interest while keeping its history, `boost` when they want it weighted higher. `forget` is different and IRREVERSIBLE: it erases the underlying history so the topic cannot re-form — only use it when the user clearly asks to delete, and say what it means first.