The Storyblok MCP server with Linkeddit data, working inside Claude

The Storyblok MCP server gives Claude the Management API through seven tools. The Agent Index listing shows search, describe, execute_readonly, execute_mutating, execute_destructive, upload_asset and upload_asset_finish. Instead of one tool per endpoint, Claude searches for an operation, describes its parameters, then executes it, which Storyblok says lets it confirm parameters before acting.

The tools are split by risk: reads run through execute_readonly, creates and updates through execute_mutating, and deletes through execute_destructive, which needs explicit confirmation. It works on the Management API, not the Content Delivery API, so it cannot read published content as visitors see it. It also does not know your market, which is the gap Linkeddit fills.

Storyblok 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 using your existing components, and calls Storyblok to save the story as a draft. Storyblok's own example prompt, "Create a new campaign landing page using our existing hero, feature grid, and CTA components," is the right shape: reuse what your space already has.

Audience voice on Storyblok is mostly about editing. A viewer on a YouTube video about Storyblok wrote that "having a live preview, especially for clients, is a game changer". Linkeddit does not touch that part. It supplies the evidence for what the draft should say.

Ask Linkeddit for the project's open gaps with answer_gaps_get, then have Claude draft the story that would answer the question and create it in Storyblok as an unpublished 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.

Linkeddit's answer_sources_fetch can read the pages the engines cited for that question. It spends credits and returns an estimate first, so it is a step for you to approve, not something these pages ran. Claude then creates the story through execute_mutating. Storyblok's own guide warns a write can publish early or land in the wrong folder, so have Claude read back its plan first. Afterwards, answer_verify_start re-checks 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 the space already has a story for each. Storyblok's own example, "Find all published stories that mention our autumn collection," shows the pattern, and narrow field filters help because Management API rate limits apply.

Where no story exists, Linkeddit's keyword_research_get can assemble a brief for the chosen keywords, and Claude builds a draft from your components. 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 Storyblok stories that own them and update a 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, Storyblok's example prompt "Update the meta description on this product page and save the change as a draft" is the exact move: small edits, saved as drafts, reviewed before publishing.

Yes. Linkeddit's article_save stores an article for your approval, and Claude can then read it and create the matching Storyblok story as a draft. Linkeddit holds the article and Storyblok holds the story, so nothing goes live until you publish it or ask Claude to.

One limit matters for articles with images. Storyblok's guide says uploading new asset files may need shell access to run a curl command, and the connector page says this works in Claude Code, not Claude.ai or Claude Desktop. In those apps, upload the image yourself or reuse one already in the asset library.

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 story in Storyblok. 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 access and scope first. The Storyblok landing page says access runs through OAuth and scoped access tokens, and the docs say the model chooses operations and target spaces, so grant least privilege. The Agent Index lists this connector at the community verification tier.

Then check the habits. Storyblok recommends testing in a sandbox space, having the agent summarize its plan before any mutating call, and verifying IDs and names before a destructive one. It adds that MCP results are non-deterministic and recommends the Storyblok CLI for repeatable, high-volume or CI/CD work, and for bulk changes across many stories.