The Sanity MCP server with Linkeddit data, working inside Claude

The Sanity MCP server lets Claude run GROQ queries, read your deployed schema, create and patch documents, and publish them. The Agent Index listing for the Claude connector shows 31 tools: 14 reads, 10 writes, 1 admin tool, 3 meta tools and 3 it does not classify. Sanity's own docs describe a larger, changing set, and Scalekit notes that the tool set can change with server updates.

Edits land in drafts or release versions, never directly in published content, and publishing needs every required field filled. That draft-first design is why the workflows below are safe to run. It does not know which buying questions AI engines answer without you, which keywords your buyers type, or what your competitors changed this week.

Sanity is the content system of record and Linkeddit is the evidence. Linkeddit's connector reads from Answer Radar, which records which brands the five engines name and recommend, from Compete, which tracks competitor moves, and from Google keyword and Search Console data. Both come with one plan at $60 a month.

Linkeddit writes no page copy and does not publish. Claude reads the evidence, drafts in the shape of your Sanity schema, and calls Sanity to save it as a draft. A Sanity editor then reviews it in Studio. Each side does the one job it can verify.

One commenter on a Sanity MCP video asked the question most editors ask: "Does Claude ever struggle with ‘hallucinating’ blocks that don't exist or does the MCP keep it strictly within the provided schema?" Have Claude call get_schema first and use only the types it returns, then check the draft in Studio.

Ask Linkeddit for the project's open gaps with answer_gaps_get, then have Claude draft the page that would answer the question and save it to Sanity as a draft. On Linkeddit's test project, plausible.io, a live read returned one open gap: Not represented for 'Umami vs Matomo for self-hosted analytics', with an intent score of 0.6 and an evidence score of 22.

That gap names a question where an engine recommended someone else, and Linkeddit's answer_sources_fetch can read the pages the engines cited for it. That call spends credits and returns an estimate first, so it is a step for you to approve, not something these pages ran. Claude then drafts the comparison, writes a document of the matching type with create_documents, and leaves it unpublished. Once the page is live, re-checking the question with answer_verify_start shows whether the engines now name you, again after an estimate.

Start from a completed keyword research job, take the highest priority keywords with a suggested landing page, and have Claude check whether Sanity already has a document for each. query_documents with a GROQ filter on title or slug answers that in one call, and a projection keeps the result under the 64 KiB limit Sanity's docs set for query results.

Where no page exists, Linkeddit's keyword_research_get can assemble a brief for the chosen keywords, and Claude writes the page into a new draft. On the test project, two research jobs are stored, each with 60 scored keywords. Treat the brief as evidence for the page, and decide the angle yourself.

Use gsc_queries_get on the striking_distance view, which lists queries at an average position of 11 to 20 with real impressions, then ask Claude to find the Sanity documents for the pages that own them and patch a revised draft. It needs the customer's own Search Console connected to the project.

On the test project it is not connected, and Linkeddit says so plainly instead of guessing, which is what a good run should do. With data, Claude edits intros and headings in a draft or a release version. Sanity's docs advise creating a version before patching in a release, and never patching the published ID first.

Yes. Linkeddit's article_save stores an article for your approval, and Claude can then read it and create the matching Sanity document, as a draft. Linkeddit holds the article and Sanity holds the published page, so nothing goes live until an editor presses publish or Claude calls publish_documents at your request.

Sanity's docs say patches go to drafts or release versions. Markdown can become Portable Text on the Sanity side: the Agent Index listing shows create_documents_from_markdown and patch_document_from_markdown for that, so the article text does not need hand conversion.

Pull compete_signals_get for the week's competitor moves and search_competitors_get for who beats you on the keywords you track, then have Claude draft a comparison page in Sanity. The test project's footprint covers 59 checked keywords and 47 AI answer samples across 358 domains, and matomo.org was cited 23 times in the latest finished answer run, 21 of them by ChatGPT.

The same week the project had four Compete signals, all low priority, from Simple Analytics and Umami blog posts. A low priority signal is a reason to wait, not to write. Have Claude cite the source link for each claim so an editor can check it.

Check the access first. With OAuth, Claude acts as you, scoped to your role. If you set an API token in the header, OAuth is skipped and every call runs with that token's role, which removes per-user identity, according to Sanity's docs and Scalekit. Use an editor role, not an admin token.

Then check the limits. The docs say custom validation rules are skipped through MCP, patch_documents takes at most 25 documents per call, and OAuth sessions typically expire after about 7 days. Admin tools such as create_project and deploy_schema can change the project, so tell Claude to leave them alone. Scalekit also lists what the MCP does not cover: webhooks, document history, export and text-generating Agent Actions.