Docs / Bring your own agent

Tutorial: publish a blog post about your app, from Cursor

You're building an app in Cursor (or Claude Code). You want a launch post, a changelog article, or a "how we built X" piece on your blog, written by the agent that already knows your codebase, published through your CMS, with your brand rules enforced. This walks through the whole flow with Wavefront's MCP tools.

Prerequisite: the server is connected and authenticated (getting started). Tool names below are what your agent calls; you just prompt it.

Part 1: One-time workspace setup (admin)

Skip this if your workspace is already configured; get_settings and list_cms_connections show the current state.

  1. set_site_base_url with your site, e.g. https://myapp.com. Powers sitemap checks, internal-link verification, and rank tracking.
  2. learn_brand_from_url with the same URL - infers your product name and palette into the brand kit. Review with get_brand_profile; fine-tune with set_brand_profile (voice, banned words, image style, word-count targets).
  3. set_cms_connection - where publishes land. Providers: WordPress, Webflow, Ghost, Shopify, HubSpot, Sanity, Strapi, Contentful, a signed webhook, or a git repo of markdown. The connection is live-tested on save.
  4. Optional: set_content_template to pin per-type editorial contracts (word targets, structure, QC checklist), and set_webhook_subscription to get content.published events in Slack/Zapier/your own endpoint.

A useful prompt for step 1-3: "Set up my Wavefront workspace: site is https://myapp.com, learn the brand from it, and connect my WordPress at https://blog.myapp.com with this application password."

Part 2: Write and publish the article

Prompt your agent with something like: "Write a launch post about the realtime collaboration feature we just shipped (see src/collab/). Use Wavefront: plan it, draft it, add images including a real screenshot, validate, and publish to staging."

The tool sequence the agent should follow (also returned at runtime by get_agent_context):

1. Bootstrap and plan

  • get_agent_context - master workflow + constants. Always first.
  • plan_article with the topic and resourceType - one pre-flight call that checks keyword cannibalization, slug availability, picks an author, and returns the full editorial contract (word target, structure, QC checklist) with a go/no-go verdict.
  • get_generation_rules - the voice/SEO/format rules the draft must follow.

2. Draft

Two options:

  • create_draft - the agent writes the markdown itself (best here: it has your codebase in context and can describe the feature accurately). Pass title, slug, bodyMarkdown, resourceType, seoDescription, shortDescription, primaryKeyword.
  • generate_draft - the platform LLM writes it from a topic + your rules (metered in credits).

Drafts are versioned; update_draft edits with conflict detection, revert_draft rolls back.

3. Images: real screenshots + generated art

  • upload_image - attach REAL images of your app: pass base64 + mimeType (e.g. a screenshot the agent just took, or a file from your repo) or an https url, plus the documentId, a descriptive filename, role (hero/body), and altText. PNG/JPEG/WebP/GIF up to 5MB; identical bytes are deduped.
  • generate_image_prompt then generate_image - brand-styled generated art for the hero or supporting images.
  • set_image_alt, list_draft_images, remove_image to manage what's attached.

4. Validate and finish

  • assign_author (skippable: publish auto-assigns when missing).
  • validate_draft - runs the full QC rules engine (voice, SEO, structure, cited stats, image count...) and persists a score with per-rule findings. Fix and re-run until it passes; publish is gated on it.

5. Publish

  • publish_draft - the durable publish workflow: QC gate -> image upload -> markdown-to-richtext -> entry upsert -> publish. Default target is staging. Poll get_publish_status with the returned run id.
  • Review the staged article, then promote_to_production (admin) - or publish straight to your connected CMS with publish_to_cms.
  • Editing later: import_published_to_draft -> update_draft -> validate_draft -> update_published_entry (detects if someone edited the live entry directly in the CMS).

Part 3: Promote it

  • generate_social_posts - platform-ready copy (LinkedIn, X, Facebook, Instagram) plus an on-brand social-card image prompt.
  • publish_social - dry run by default: it returns the exact payloads without posting. Re-call with live: true to publish via your Ayrshare account (admin stores the key once with set_org_credential, kind ayrshare). Idempotency keys prevent double-posts; scheduleDate schedules.
  • Webhook subscribers receive content.published with the full document payload (markdown, HTML, image URLs) for any further automation.

Variants

  • Fully autonomous: generate_article runs draft -> validate -> publish as a background agent run; track with list_agent_runs.
  • Ideation first: suggest_topics and list_keyword_opportunities rank what's worth writing from your own Search Console data.
  • Ongoing series: create_calendar_entry / schedule_article put the piece on the editorial calendar; autopilot (set_autopilot) can work the calendar on a schedule.

Reference

  • Tool catalog - every tool with roles and parameters.
  • Webhooks - payload contract and signature verification.
  • get_agent_context - canonical workflow recipes, always current.