MCP servers

Read this first — what Context Blog is, how it relates to the Context MCP (approvals live there), tools, tiers and rules.

Machine-readable Context Blog contract: version, tools, workflows, harnesses, auth methods and limits.

Active skills on the shared skill channel (key, kind, version, name, description, depends, url).

One skill revision (active by default) with its SKILL.md content, extra files and provenance.

CALL THIS FIRST when starting Context Blog work in a repo or chat.

Server-side render of a draft article or page into one self-contained HTML page with the tenant's design tokens as CSS variables.

The MACHINE half of the blog-checker playbook, no side effects: answer-first ≤ 60 words, each H2 followed by a 40–75-word paragraph, table/list for comparison·listicle·how-to, FAQ 3–5 × 80–150 words, inline HTML allowlist (em/strong/a), ≥ 2 outbound citations, ≥ 2 numeric statistics, ≥ 1 original artifact, hub assigned, localised slug/title/description vs master, style rotation vs recent_styles, banned phrases, first-person density.

Append one blog-checker verdict for a draft: tenant_slug, subject_kind (article | page | instagram), subject_ref (the Context issue id, or a draft id before one exists), round (1 = first check), verdict (pass | bounce | escalate), findings (the verdict document's checks, as JSON) and models ({maker, checker}).

Every recorded blog-checker verdict for a subject_ref (Context issue id or draft id), oldest round first — use it to know the current round before bouncing again (bounce ≤ 2 rounds, then escalate).

Create a tenant (a site such as getmeetly.ai/blog).

Tenant settings plus brand profile, audiences, hubs, domains and content counts.

Patch tenant settings (name, tier, products, recurrence, locales, default_locale, timezone, mount_path, primary_hostname, context_epic_id, context_epic_surface: phone | web — where the epic was created, so the settings page leads with context://tasks/<epic> or the web URL).

Replace the tenant's brand profile: voice (persona, banned_phrases[], …), byline (author name/url), design_tokens (blog-agent/templates/design-tokens.json shape — used by previews and the renderer), optional organization_ld / software_application_ld (JSON-LD).

Upsert audience segments by key (name, description, pains[], queries[]).

Upsert topic hubs by slug (title, description, pillar_article_id).

Create or update topics (the research backlog): hub_slug, title, target_query, fanout_queries[], status (idea | researched | drafting | published | retired), context_issue_id, source.

Topics of a tenant, newest first, optionally filtered by status.

Create or update an article draft.

One article by id, or by slug + locale.

Articles of a tenant, newest first, without bodies.

Move an article one step forward: draft → in_review → approved → published → retired (any other jump is `conflict`).

Create or update a site page (about, pricing, landing).

One page by id, or by slug + locale.

Pages of a tenant, newest first, without bodies.

Move a page one step forward (draft → in_review → approved → published → retired).

Publish exactly one of article_id | page_id | instagram_post_id.

Reserve an asset row and get a signed PUT URL into the Supabase Storage bucket blog-assets (valid 2 h).

Mark an uploaded asset ready and record width / height / alt.

Create or update an Instagram carousel draft: caption (≤ 2200 chars), slides (asset ids of this tenant, 1–10, in order), publish_at, context_issue_id.

One Instagram post by id: caption, slides, status, context_issue_id, Postiz id and permalink once posted.

Instagram posts of a tenant, newest first.

Move an Instagram post one step forward: draft → in_review → approved → published → retired (any other jump is `conflict`).

Record a hostname for the tenant and return the DNS / proxy instructions plus copy-paste snippets (vercel.json rewrites as getmeetly.ai uses them, next.config.js rewrites(), nginx location; the DNS record for cname).

Verify a connected hostname and store the result.

How the blog is doing over a period (7d | 28d | 90d, default 28d, ending yesterday; or from/to): totals (pageviews, visitors, visits, bounces, time), the previous period for comparison, channel split with the AI-referral share and per-engine visitors, Search Console clicks/impressions/position when ingested, AI-visibility cited rate when a probe ran, top 5 posts.

Posts ranked by pageviews over the period (default 28d), joined to the article (title, url, locale) with AI-referral pageviews and Search Console clicks per post.

One article over the period (by article_id, or slug + locale): daily pageviews, AI-referral pageviews per engine, Search Console totals + top queries for its URL, and the probe results that cited it.

Visitors and pageviews that arrived from AI assistants (chatgpt, perplexity, gemini, claude, copilot, grok, meta, you, google_aio) over the period: per engine, per day, and the landing pages.

Search Console query × page rows over the period (ingested nightly when GSC_SERVICE_ACCOUNT_JSON and tracking.gsc_property are set): clicks, impressions, CTR, position, striking_distance (position 5–20 — a refresh candidate).

Per query × engine: the latest probe status in the period (cited | mentioned | absent | error | no_ai_answer), citation rank and URL, and the status in the previous period (trend).

Upsert the tenant's target queries for the AI-visibility probe (≈ 30; the blog-assessment skill probes the active ones weekly): query, topic, priority (1 = money query probed daily, 3 = weekly), article_id (the post that should be cited), active.

Store one agent-side probe run (the blog-assessment skill: ~30 queries × engines, the owner's OPENROUTER_API_KEY etc.

IndexNow submissions (publish pings to api.indexnow.org — 200/202 = accepted) and the recent publish events for the tenant, optionally for one URL.

What is configured for this tenant's analytics and what is missing, by NAME: Umami (script slot + API for ingestion), GA4 (BYO, consent-gated), Search Console (property + service account), Bing, IndexNow, the probe query list, the nightly cron.

Use this when you need to orient yourself in Context before doing anything else — at the top of a session, whenever you are unsure which tool fits, or when the user greets Nomi or says "Nomi, get me started".

Use this when you need to find something by words rather than by id — an Epic, Issue, Artifact or memory whose id you do not have.

Use this when you need to know which Spaces exist before naming one in a `space` argument.

Use this when you need to survey the goals in flight rather than open one specific Epic.

Use this when you need to see one goal in full — its blueprint, derived status, child Issues, Artifacts and recent activity in a single read.

Use this when you need to open a new goal in a Space, optionally seeding its first Issues in the same call.

Use this when you need to change one Epic's title, goal, labels or Space — never its status, which is derived from its Issues.

Use this when you need to remove an Epic that should not exist at all — this is also how you retire work that would otherwise be `canceled`, which v3 does not expose as a state.

Use this when you need to see the queue rather than one Issue — what is open, what is yours, what sits under an Epic.

Use this when you need to read one Issue in full before acting on it — acceptance criteria, state, `blocked_by` edges, child Issues, Artifacts, comments and delivery/claim state in a single read.

Use this when you need to add one or more units of work under an Epic or under another Issue — decomposition in v3 is always child Issues, never a checklist.

Use this when you need to edit, re-state, re-parent or re-block existing Issues — including moving one to `in_progress` or `in_review`.

Use this when you need to move Issues to `done` because the work is finished and accepted.

Use this when you need to remove Issues that should not exist at all — including work that would otherwise be `canceled`, which v3 does not expose.

Use this when you need to say something on the record — progress narration, an answer to the user's review comment, or a note anchored to a passage of an Artifact.

Use this when you need to get a person to decide something before work continues — an Epic's plan, an Issue's outcome, or an Artifact's content.

Use this when you need to put on the record, with evidence, that an Issue's acceptance criteria are met (ADR-0008).

Use this when you need to record how you actually checked a claim — the method, the per-criterion results and the evidence.

Use this when you need to find the reviewable documents attached to a Space or to one Epic or Issue.

Use this when you need to read one Artifact — its metadata, its content or a resource link to it, its revision list and its comment threads.

Use this when you need to attach a reviewable document to a piece of work — a spec, a decision record, a report, a file.

Use this when you need to change an Artifact's content — v3 appends an immutable revision and advances the head rather than overwriting, so the old text stays citable.

Use this when you need to change only an Artifact's title, labels, kind or Space, leaving its content exactly as it is.

Use this when you need to remove Artifacts from the account entirely.

Use this when you need to check whether an `attach_artifact` upload plan you followed actually completed.

Use this when you need to know what happened while you were working — review decisions, comments, and operations the user's phone applied.

Use this when you need to know whether a queued write actually reached the user's device, instead of assuming that acceptance meant application.

Use this when you need to give work its own container because it genuinely does not belong in `shared`, `personal` or `work`.

Use this when you need to remove an empty private Space.

Use this when you need to read what the user captured on their phone, most recent first — the raw material behind briefings and coaching.

Use this when you need to read one memory in full — raw text, the AI-enhanced version, extracted logs and people links, and a deep link that opens it on the phone.

Use this when you need to persist something the user told you beyond this session — a memory entry, or an atomic durable fact (a preference, a decision, biographical detail).

Use this when you need to remove whole memories from the user's phone — their extracted logs and todos go with them.

Use this when you need to read the user's atomic logged events — meals, workouts, expenses, or health readings (blood pressure, body metrics, HealthKit-mirrored items) — one row per event.

Use this when you need to give the user a meal to eat — meal prep, a restaurant order, a macro-targeted suggestion.

Use this when you need to give the user exercise to do.

Use this when you need to remove logged rows that are wrong — a mis-transcribed meal, a duplicated expense.

Use this when you need to read the roster the user opted to share — names, aliases, organizations.

Use this when you need to read everything Context knows about one person — the profile the user synced, and optionally the memories linked to them.

Use this when you need to create a profile for someone the user talks about who has none.

Use this when you need to record something you learned about people the user already has profiles for — contact-card fields, or `remembered_facts` for what the user TOLD you.

Use this when you need to remove app-created or junk profiles that should not exist at all — and ONLY those.

Use this when you need to fold several profiles of the same real person into one — this is the durable fix for duplicate contacts, unlike deletion.

Use this when you need to read raw HealthKit rows the user opted into agent collection — steps, heart rate, sleep, HRV, glucose.

Use this when you need to answer a question about a trend or a total rather than individual readings — daily steps, weekly sleep, monthly weight.

Use this when you need to read the user's schedule — what a day held, who was in a meeting, what is coming up.

Use this when you need to read one meeting in full — attendees and which resolve to people, organizer, location, join link, and the memories, Artifacts and Issues attached to it.

Use this when you need to find the playbooks the user or an agent stored on the phone — how THIS user wants a recurring job done.

Use this when you need to read the full markdown of a stored skill that covers the job you are about to do.

Use this when you need to keep a playbook for next time — omit `skill_id` to add a new skill, pass it to overwrite an existing one.

Use this when you need to fetch device-held content that routine sync deliberately does not carry — a document body, a contact field, a health sample.

Use this when you need to know whether the phone has answered a `request_content` you are waiting on.