SPRKL Team
We wanted to publish to our website and our LinkedIn page from a chat window, with a human still signing off on every word. Here is exactly how we built it.
Most content teams lose hours in the gap between writing and publishing. The draft lives in one tool, the blog in another, the LinkedIn page in a third. Someone copies, pastes, reformats, and hopes the link works. It is the same reason we argue that efficiency beats content volume.
We closed that gap at SPRKL with the Model Context Protocol (MCP). Today, one conversation with Claude drafts an article, stages it on our Framer website, queues a post for the SPRKL LinkedIn page, and then waits for a human to approve both. This article was published that way.
What MCP actually changes
MCP is an open standard that lets an AI assistant use real tools through a defined interface. Instead of asking a model to explain what you should do in your CMS, you give it a connector and it does the work, inside the permissions you set.
For publishing, we needed two connectors:
Framer MCP: reads and writes our website through Framer, including the CMS collection that powers this blog.
A self-hosted LinkedIn publisher: posts to our company page through LinkedIn’s official API.
Choosing the LinkedIn side
This was the hard part. We reviewed more than 200 LinkedIn MCP servers listed in public directories. Most fell into one of three buckets: browser automation that logs in as you and breaks LinkedIn’s terms, hosted services that keep your tokens on their servers, or full social suites that need a stack of databases just to run.
We wanted the opposite. Official API only. Our own server. No third party holding credentials. A human approval step built in. We chose pendpost, an open-source, zero-dependency Node.js planner with an MCP endpoint and an approval gate the AI cannot bypass. Claude can draft and stage a post. It cannot approve its own work.
The architecture, in plain terms
One small cloud instance: 1 GB of RAM for a few dollars a month. The publisher runs as a system service and listens only on localhost, so the app has no public port.
Cloudflare Tunnel: connects the instance to a subdomain through an outbound connection. Nothing on the server is exposed directly to the internet.
Cloudflare Access: sits in front with an email-based policy. Only named people get in, and adding a teammate is one line in the policy.
Managed OAuth: Access handles the sign-in when Claude connects as a custom connector, so we did not write any authentication code.
A LinkedIn developer app: verified by an admin of our company page, it issues the token the publisher uses to post as SPRKL. You create one on LinkedIn Developers.
The workflow
Brief Claude in plain language, from a laptop or a phone.
Claude drafts the article and the LinkedIn post, following our brand rules.
The article is created in the Framer CMS as a draft. The LinkedIn post is staged in the publisher, unapproved.
We review mobile previews of both in the chat, then approve or ask for edits.
Claude publishes the website, confirms the article is live, then releases the LinkedIn post with the live link.
Lessons from the build
Keep the publisher private. Let the tunnel and the access policy do the gatekeeping, not the app.
Keep secrets out of the chat. Tokens are created by a person in a short terminal step and never pasted into a conversation.
Plan for LinkedIn’s review. Posting to a company page needs your app verified by a page admin and the right marketing product approved. Start this early.
Treat approval as a feature. An agent that can publish without review is a reputation risk, however good the drafts are.
Stay lightweight. One small instance, no database server, no container cluster. Less to patch, less to pay for.
Who this is for
Lean marketing teams and founders who publish often, want AI to do the heavy lifting, and are not willing to hand their brand voice or their credentials to a black box. It is the same thinking behind why a senior, lean team beats a big agency. The setup also extends to other networks later without changing the approval model.
At SPRKL, we build these systems for teams that want speed without giving up control. If you want a setup like this for your brand, talk to us.
The SPRKL Take: AI should shorten the distance between an idea and a published post. It should not remove the person who owns the message. Build the pipe, keep the gate.
