Shipstar
Automated product marketing over MCP.
От сообщества: Добавлен пользователем или импортирован; проверьте владельца перед подключениемРаботаетБез входаГлобальныйБесплатноМожет изменять данные
Что умеет
- List Changelogs: List this project's published changelogs, newest first. Returns an array of changelog objects. Each object contains the parsed JSON payload (headline, summary, items, etc.) plus a `sl
- Get Changelog: Get a single published changelog by its public slug. Args: slug: The `public_slug` returned by `list_changelogs`. Raises: ValueError: If no published changelog exists with that slug, or
- List Blog Posts: List this project's published blog posts, newest first. Returns an array of blog post objects with `slug`, markdown `content`, `category`, `period_start`, `period_end`, `published_at`
Какие данные видит
Нужен ли аккаунт
Не нужен: сервер работает без входа
Automated product marketing over MCP. Connect a Shipstar project and turn shipped code into marketing content: generate changelogs, blog posts, KB articles, release notes emails, and social posts from recent commits, then review, approve, publish, and email them — the same pipeline the Shipstar dashboard drives. OAuth 2.1 sign-in; each connection is scoped to one project.
Список инструментов сервера (26)
Технические названия из tools/list. Нужны только разработчикам.
| list_changelogs | List this project's published changelogs, newest first. Returns an array of changelog objects. Each object contains the parsed JSON payload (headline, summary, items, etc.) plus a `slug` field that can be passed to `get_changelog`. |
| get_changelog | Get a single published changelog by its public slug. Args: slug: The `public_slug` returned by `list_changelogs`. Raises: ValueError: If no published changelog exists with that slug, or if the stored content is not valid JSON. |
| list_blog_posts | List this project's published blog posts, newest first. Returns an array of blog post objects with `slug`, markdown `content`, `category`, `period_start`, `period_end`, `published_at`, and `created_at`. |
| get_blog_post | Get a single published blog post by its public slug. Args: slug: The `public_slug` returned by `list_blog_posts`. Raises: ValueError: If no published blog post exists with that slug. |
| list_kb_article_sets | List this project's published knowledge base article sets, newest first. Each set bundles multiple articles under a single `slug`. Entries whose stored content is not valid JSON are skipped. |
| get_kb_article_set | Get a single published knowledge base article set by slug. Args: slug: The `public_slug` returned by `list_kb_article_sets`. Raises: ValueError: If no published KB set exists with that slug, or if the stored content is not valid JSON. |
| get_banner | Get this project's live announcement banner. Exactly one banner is live per project: the one-line announcement bar the project embeds at the top of its site (`badge`, `headline`, `body`, `cta_label`, `link_url`). Publishing a new banner replaces it under the same `slug`, which is the embed key. Raises: ValueError: If no banner is live (never published, replaced, or past its take-down time), or if the stored content is not valid JSON. |
| generate_changelog | Kick off generation of a public changelog from recent commits. Analyses commits on the project's tracked GitHub repositories between `start_date` and `end_date` (defaults: last 7 days) and returns a pending content record. The content is generated in the background; use `list_changelogs` / `get_changelog` (or the REST API) once the record's status transitions to `completed`. Args: start_date: Earliest commit timestamp to consider (ISO-8601). end_date: Latest commit timestamp to consider (ISO-8601). product_name: Override the product name used in the header. idea: Optional `{title, summary}` suggestion to focus the piece on; commits unrelated to the idea are ignored. audience: Technical depth of the writing — "technical" (developers; name APIs, config keys, migration notes), "business" (plain-language outcomes, no code identifiers), or "mixed". Omit to use the project default (see `get_project_context` → `content_guidelines`). instructions: Free-text guidance on scope, tone, or terminology (e.g. "don't mention marketing website changes"). Max 2000 chars. Omit to use the project default. repos: Restrict the commit source to these tracked repositories (full names as listed by `get_project_context.tracked_repositories`, e.g. ["acme/backend"]). Omit to use every active tracked repo. |
| generate_blog_post | Kick off generation of a blog post from recent commits. Args: start_date: Earliest commit timestamp to consider. end_date: Latest commit timestamp to consider. product_name: Optional product name override. idea: Optional object with `title`, `summary`, `angle`, and optional `category` to steer the post. Pair with `generate_blog_post_ideas` to pick one first. blog_options: Optional dict with keys: - `length`: "short" (600-1000 words, default) or "long" (1200-1800 words) - `seo`: true/false — include SEO optimization (target keyword, meta description, related topics) - `focus`: "multi_feature" (default) or "single_feature" (deep-dive on one feature) audience: Technical depth of the writing — "technical" (developers; name APIs, config keys, migration notes), "business" (plain-language outcomes, no code identifiers), or "mixed". Omit to use the project default (see `get_project_context` → `content_guidelines`). instructions: Free-text guidance on scope, tone, or terminology (e.g. "don't mention marketing website changes"). Max 2000 chars. Omit to use the project default. repos: Restrict the commit source to these tracked repositories (full names as listed by `get_project_context.tracked_repositories`, e.g. ["acme/backend"]). Omit to use every active tracked repo. |
| generate_blog_post_ideas | Brainstorm blog post angles from recent commits (synchronous). Unlike the other generation tools, this returns ideas immediately rather than kicking off a background task. Each idea has a `title`, `summary`, `angle`, and optional `category` that can be passed back to `generate_blog_post` via the `idea` argument. |
| generate_feature_page | Kick off generation of a marketing feature landing page. Args: start_date: Earliest commit timestamp to consider (ISO-8601). end_date: Latest commit timestamp to consider (ISO-8601). product_name: Override the product name used in the page. idea: Optional `{title, summary}` suggestion naming the feature to spotlight; commits unrelated to the idea are ignored. audience: Technical depth of the writing — "technical" (developers; name APIs, config keys, migration notes), "business" (plain-language outcomes, no code identifiers), or "mixed". Omit to use the project default (see `get_project_context` → `content_guidelines`). instructions: Free-text guidance on scope, tone, or terminology (e.g. "don't mention marketing website changes"). Max 2000 chars. Omit to use the project default. repos: Restrict the commit source to these tracked repositories (full names as listed by `get_project_context.tracked_repositories`, e.g. ["acme/backend"]). Omit to use every active tracked repo. |
| generate_kb_articles | Kick off generation of knowledge base articles from recent commits. Args: start_date: Earliest commit timestamp to consider (ISO-8601). end_date: Latest commit timestamp to consider (ISO-8601). product_name: Override the product name used in the articles. idea: Optional `{title, summary}` suggestion for the article(s) to write (e.g. a specific feature to document); pick a date range covering when that feature was built — commits unrelated to the idea are ignored. audience: Technical depth of the writing — "technical" (developers; name APIs, config keys, migration notes), "business" (plain-language outcomes, no code identifiers), or "mixed". Omit to use the project default (see `get_project_context` → `content_guidelines`). instructions: Free-text guidance on scope, tone, or terminology (e.g. "don't mention marketing website changes"). Max 2000 chars. Omit to use the project default. repos: Restrict the commit source to these tracked repositories (full names as listed by `get_project_context.tracked_repositories`, e.g. ["acme/backend"]). Omit to use every active tracked repo. |
| generate_featurebase_articles | Kick off generation of Featurebase help-center articles from recent commits. The draft is a set of articles for review. Approving it (`approve_content`) creates the articles in the project's connected Featurebase help center — in the schedule's collection, else the destination's default collection — and only then does the content read "published". Featurebase must be connected under Destinations in the dashboard first (`list_destinations` shows `featurebase.connected`). Seed mode (`seed=true`, 300 credits) builds the *initial* help center instead of a what-changed set: it reads the tracked repositories' README and docs folders plus the last six months of commits, outlines collections and up to `max_articles` articles (default 20, skipping titles already in the help center), and writes them all into one reviewable set. On approve each article is filed under its collection, created if missing. Args: seed: Build the initial help center from the repo docs (see above). max_articles: Seed mode cap on proposed articles, 5–30 (default 20). start_date: Earliest commit timestamp to consider (ISO-8601). end_date: Latest commit timestamp to consider (ISO-8601). product_name: Override the product name used in the articles. idea: Optional `{title, summary}` suggestion for the article(s) to write (e.g. a specific feature to document); pick a date range covering when that feature was built — commits unrelated to the idea are ignored. audience: Technical depth of the writing — "technical" (developers; name APIs, config keys, migration notes), "business" (plain-language outcomes, no code identifiers), or "mixed". Omit to use the project default (see `get_project_context` → `content_guidelines`). instructions: Free-text guidance on scope, tone, or terminology (e.g. "don't mention marketing website changes"). Max 2000 chars. Omit to use the project default. repos: Restrict the commit source to these tracked repositories (full names as listed by `get_project_context.tracked_repositories`, e.g. ["acme/backend"]). Omit to use every active tracked repo. |
| generate_release_notes_email | Kick off generation of a release notes email from recent commits. Once the record's status is `completed` (poll `get_generation_status`), review it with `get_content_draft` and deliver it to mailing lists with `send_release_email`. Args: start_date: Earliest commit timestamp to consider (ISO-8601). end_date: Latest commit timestamp to consider (ISO-8601). product_name: Override the product name used in the email. idea: Optional `{title, summary}` suggestion to focus the email on; commits unrelated to the idea are ignored. audience: Technical depth of the writing — "technical" (developers; name APIs, config keys, migration notes), "business" (plain-language outcomes, no code identifiers), or "mixed". Omit to use the project default (see `get_project_context` → `content_guidelines`). instructions: Free-text guidance on scope, tone, or terminology (e.g. "don't mention marketing website changes"). Max 2000 chars. Omit to use the project default. repos: Restrict the commit source to these tracked repositories (full names as listed by `get_project_context.tracked_repositories`, e.g. ["acme/backend"]). Omit to use every active tracked repo. |
| generate_twitter_thread | Kick off generation of an X (Twitter) thread from recent commits. Args: start_date: Earliest commit timestamp to consider (ISO-8601). end_date: Latest commit timestamp to consider (ISO-8601). product_name: Override the product name used in the thread. idea: Optional `{title, summary}` suggestion to focus the thread on; commits unrelated to the idea are ignored. audience: Technical depth of the writing — "technical" (developers; name APIs, config keys, migration notes), "business" (plain-language outcomes, no code identifiers), or "mixed". Omit to use the project default (see `get_project_context` → `content_guidelines`). instructions: Free-text guidance on scope, tone, or terminology (e.g. "don't mention marketing website changes"). Max 2000 chars. Omit to use the project default. repos: Restrict the commit source to these tracked repositories (full names as listed by `get_project_context.tracked_repositories`, e.g. ["acme/backend"]). Omit to use every active tracked repo. |
| generate_banner | Kick off generation of an announcement banner from recent commits. The banner is the one-line bar a site shows at the top of the page (`badge` tag, `headline` ≤ 80 chars, one-sentence `body` ≤ 160 chars, `cta_label`) announcing the single most impactful change of the period. Exactly one banner is live per project: publishing this draft replaces the current banner under the same embed key. Read it back with `get_banner`; embed it with `<script src="https://shipstar.ai/embed.js" data-type="banner" data-shipstar-key="<slug>">`. Args: start_date: Earliest commit timestamp to consider (ISO-8601). end_date: Latest commit timestamp to consider (ISO-8601). product_name: Override the product name used in the banner. idea: Optional `{title, summary}` suggestion to focus the banner on; commits unrelated to the idea are ignored. link_url: Where the call-to-action points. Omit to fall back to the project's configured Changelog page, then the period's published changelog permalink; with neither the banner renders without a link. expires_after_days: Stop serving the banner 7, 14, or 30 days after publication. Omit to keep it live until the next banner replaces it. badge: Short label shown before the headline, at most 16 chars (e.g. "Beta", "v2.0"). Omit for the project default ("New" unless changed under Destinations → Website). show_badge: Pass false to render the banner without a badge. audience: Technical depth of the writing — "technical", "business", or "mixed". Omit to use the project default (see `get_project_context` → `content_guidelines`). instructions: Free-text guidance on scope, tone, or terminology. Max 2000 chars. Omit to use the project default. repos: Restrict the commit source to these tracked repositories (full names as listed by `get_project_context.tracked_repositories`). Omit to use every active tracked repo. |
| generate_linkedin_post | Kick off generation of a LinkedIn post from recent commits. Args: start_date: Earliest commit timestamp to consider (ISO-8601). end_date: Latest commit timestamp to consider (ISO-8601). product_name: Override the product name used in the post. idea: Optional `{title, summary}` suggestion to focus the post on; commits unrelated to the idea are ignored. audience: Technical depth of the writing — "technical" (developers; name APIs, config keys, migration notes), "business" (plain-language outcomes, no code identifiers), or "mixed". Omit to use the project default (see `get_project_context` → `content_guidelines`). instructions: Free-text guidance on scope, tone, or terminology (e.g. "don't mention marketing website changes"). Max 2000 chars. Omit to use the project default. repos: Restrict the commit source to these tracked repositories (full names as listed by `get_project_context.tracked_repositories`, e.g. ["acme/backend"]). Omit to use every active tracked repo. |
| get_generation_status | Check the status of a content record kicked off by a `generate_*` tool. `status` is the generation state (`pending` → `processing` → `completed`, or `failed` with `error_message`). `review_status` is the publication state of the associated review event, when one exists (`ready_for_review`, `approved`, `published`, `skipped`). Poll every 20-30 seconds; generation normally finishes within a few minutes. Args: content_id: The `content_id` returned by a `generate_*` tool. |
| get_content_draft | Read the full draft of a generated content record. Returns the status payload plus the draft itself: `content` (markdown, or a JSON string for structured types like changelogs and release notes emails), `category`, and the commit window (`from_date` / `to_date`). Args: content_id: The `content_id` returned by a `generate_*` tool. |
| update_content | Revise the draft text and/or category of a generated content record. Replaces the stored draft wholesale — pass the complete revised text, not a diff. For structured types (changelogs, KB article sets, release notes emails, banners) the draft must remain JSON in the same shape as the original; pass it as a JSON string or object. Banner drafts are validated and clamped to the widget's limits (headline 80, body 160, cta_label 24, badge 16 chars; link_url an http(s) URL or null). Edits to already-published content update the public copy. Args: content_id: The `content_id` returned by a `generate_*` tool. content: Replacement draft text (or JSON object for structured types). category: Replacement category label. |
| approve_content | Approve generated content for publication. Side effect: if the associated review event's scheduled time has already passed, the content is published immediately; otherwise it is marked approved and the scheduler publishes it when the time arrives. Only call this after the user has reviewed the draft and confirmed. Dispatches the `content.approved` webhook. Args: content_id: The `content_id` returned by a `generate_*` tool. |
| publish_content | Publish a completed changelog, blog post, KB article set, or banner directly. Use this for on-demand generations that have no review event (where `approve_content` fails); it assigns a public slug and makes the content live immediately. Only call this after the user has reviewed the draft and confirmed. KB caveat: exactly ONE knowledge base set is live at a time — publishing a `kb_articles` record takes over the stable KB slug and unpublishes the previous set. To add articles instead of replacing the whole KB, first merge the live set's articles into your draft with `get_kb_article_set` + `update_content`, then publish the merged record. Banner caveat: exactly ONE banner is live per project — publishing a `banner` record replaces the current banner and inherits its slug (the embed key), so existing snippets show the new banner immediately. Args: content_id: The `content_id` returned by a `generate_*` tool. |
| get_project_context | Describe the project this MCP connection is scoped to. Returns the project name, the GitHub repositories Shipstar tracks for content generation, which destinations are connected, the mailing lists available for release notes emails, and the project's default content guidelines (`content_guidelines.audience` / `.instructions`) that every generation tool applies unless overridden per call. Call this first in a session to understand what generation will operate on. |
| list_destinations | List the delivery destinations connected to this project. Covers Slack, Intercom, Featurebase, X (Twitter), and the number of webhook endpoints. Destinations are connected in the Shipstar dashboard (OAuth for Slack/Intercom/X, an org API key for Featurebase) — if one the user wants is missing, direct them there rather than retrying. |
| list_mailing_lists | List the project's mailing lists for release notes emails. Returns each list's `id` (pass to `send_release_email`), `name`, and active recipient count. Lists and recipients are managed in the Shipstar dashboard under Destinations → Email. |
| send_release_email | Send a completed release notes email to the selected mailing lists. Side effect: marks the content published and queues one email per active recipient (deduplicated across lists, each with a one-click unsubscribe link). Each content record can be sent at most once — a repeat call fails rather than double-sending. Only call this after the user has confirmed the draft and the target lists. Args: content_id: A `completed` record from `generate_release_notes_email`. mailing_list_ids: One or more list ids from `list_mailing_lists`. |