Two blogs. One writer. Two different author IDs for the same person, with the same email address sitting on both records.
That small, unglamorous detail is what finally pushed me off the copy-paste publishing workflow. We publish on IndiaNIC's Signal and on the NICGulf blog, and every article used to mean the same round trip: draft the piece somewhere, paste it into the editor, repair whatever the editor mangled on the way in, hand-fill the meta title and the excerpt and the social card, hunt for an image that wasn't another stock handshake, then stop and remember which author account this one belonged to. Twenty minutes of thinking. An hour of clerical work around it.
The realisation came the day I set up the second blog and saw the two IDs side by side. The writing was never the bottleneck. The plumbing was.
The last mile is where publishing quietly costs you
For a long time I filed this under "writing problem", and I was wrong about it. It's a sequencing problem. The words were always going to be the cheap part; the expensive part is everything that happens between a finished draft and a live URL, and better prompting was never going to touch that.
Think about what that last mile actually contains. Meta title and description. Excerpt. Open Graph card. X card. Canonical URL. Tags. A hero image and at least one in-body image. Structured data, if you care about being cited. The right author. The right timezone. HTML that survives the platform's ingest rules rather than arriving as unstyled grey text.
None of it is hard. All of it is skippable under deadline. And what gets skipped is exactly what compounds: the post that goes out with no social card, the one attributed to the house account instead of a human, the table that publishes as a wall of plain text because Ghost threw the container away.
Here's what I've learned watching content teams over the years. Consistency doesn't fail dramatically. It erodes, one skipped field at a time, until the blog reads like six different companies wrote it.
What is Byline, and what does an MCP server actually do?
Byline is an open-source MCP server that gives an AI assistant a credentialed, direct line into your Ghost or WordPress blog. MCP stands for Model Context Protocol, an open standard Anthropic published in November 2024 so that assistants can call real tools instead of only producing text. Byline is one such tool server, aimed squarely at publishing.
According to the Model Context Protocol specification, a server exposes a named set of capabilities that the assistant can invoke with structured arguments. In practice that means the assistant stops handing you an article to paste and starts doing the pasting, the tagging, the image upload and the publish call itself.
The Byline repository exposes eight of those capabilities. Two of them, health_check and score_draft, exist purely to tell you when something is wrong before a reader finds out.
The four-layer model I use before touching any AI writing tool
Most tools in this category solve one layer and quietly assume the other three. That's why they demo beautifully and disappoint in production. Voice without delivery gives you a lovely draft you still have to paste. Delivery without craft gives you the fastest route yet to publishing something forgettable.
Run your own stack against the four rows above before you buy anything. If a tool covers one row, it's a feature. If it covers all four, it's a workflow.
And be honest about which layer is actually hurting you. For most teams I speak to, it isn't voice. It's delivery.
How do I run two Ghost blogs in one voice?
One persona file. Two site entries. Byline keeps the author profile in a single YAML file under ~/.byline/personas/, and inside it a platform_authors block maps each site slug to that blog's own author ID. Write the voice once, publish it anywhere, and the byline resolves correctly per site.
When I added the NICGulf blog to my own setup this week, the whole job took under 10 minutes, and the shape of the work is worth describing because it's where the design choices show. Two Ghost installs, two Admin API keys, both keys stored as variables in ~/.byline/.env with mode 600 permissions, and both referenced from config.yaml as ${NICGULF_ADMIN_API_KEY} style placeholders rather than pasted values. Config is safe to commit. Secrets never are. That split is not a detail; it's the reason I was willing to point an assistant at a live publishing credential at all.
Each site was validated the moment it was added. Ghost 6.43.1 answered on one, Ghost 6.44.1 on the other, both with an HTTP 200 and the blog's own title echoed back. That verification-on-write behaviour matters more than it sounds. A credential that fails silently at setup fails loudly six weeks later, at the worst possible time.
Then, about a minute later, came the part nobody warns you about. I updated the persona file with the two new author IDs, asked the server to read it back, and it cheerfully returned the old placeholder values. Personas are cached when the server starts. The file on disk was already correct; the running process didn't know. Two seconds of confusion, one restart, done. It's the kind of thing you only learn by doing it, and it's why I'd rather run a tool that reports what it did than one that hides the mechanism.
| The mistake that costs an afternoon. Ghost issues two different keys, and only the Admin API key can create posts — a Content API key will authenticate and then refuse to write. Ghost's Admin API documentation keeps them on separate pages for a reason, so copy the key from Integrations, not from the theme's front-end settings. |
What Byline does that the copy-paste workflow never did
Three things changed materially, and only one of them is speed.
The first is that SEO metadata stopped being optional. Meta title, description, excerpt, Open Graph and X card, tags, canonical URL, plus Article and FAQPage JSON-LD, all travel with the publish call. Google's FAQPage documentation is explicit that the structured data must match the visible page, and Byline builds the schema from the same FAQ array that renders on the page, so the two can't drift apart. On WordPress, the README reports that core can't inject JSON-LD into the head and says so as a warning rather than dropping it quietly.
The second is that every article now gets real images. A hero and an in-body shot, generated to a fixed camera register so the two match, uploaded into the blog's own media library rather than hotlinked from somewhere that will 404 next year.
The third is the one I didn't expect to value most: the scorer. score_draft counts sentence-length variance, flags a fixed lexicon of machine tells, checks that claims carry evidence, and verifies the HTML will survive the target platform. It has no taste. It's a mechanical check, and that's precisely why it's useful — it catches the things a tired human editor at 11pm will wave through.
A tool that tells you what it refused to do is worth ten that quietly do something else.
Let's be honest about the trade-off. Handing an assistant a live publishing credential is a real decision, and the answer isn't to pretend it's risk-free. It's to keep the secrets on your own disk, publish as a draft while you're building trust, and read the thing before it goes out. I still read every article before it goes live, this one included. That isn't going to change.
Where I'd push back, including on our own tool
Automated publishing makes it trivially easy to produce more, and more is almost never the problem. Nobody is short of blog posts in 2026. Readers are short of blog posts worth finishing. If a team uses this to go from four thin posts a month to twenty thin posts a month, the tool worked and the strategy failed.
There are honest limits too. WordPress behaviour was measured on single-site administrator accounts, so roles without the unfiltered_html capability remain untested. Image models sometimes refuse prompts involving people; the retry is reported rather than hidden, but a refusal is still a refusal. And research providers lag genuinely breaking news, which is why the tool separates evergreen writing from news mode instead of pretending one set of rules covers both.
Peter Drucker's line still applies: there is nothing so useless as doing efficiently that which should not be done at all. Speed up a bad publishing habit and you get a faster bad habit.
How do you set up Byline on your own blog?
Install it globally with npm, run byline init, and answer a short setup wizard that validates every credential against the live blog before it accepts it. The wizard detects existing AI tools, backs up your MCP config before writing to it, and prints the exact file paths where everything lives. Budget fifteen minutes.
A practical order of work, based on how I'd do it again:
- Start with one blog, not two. Add the second only after the first has published something you're happy with.
- Get the credential right before anything else. For Ghost, that's an Admin API key from Integrations. For WordPress, that's an Application Password — WordPress documentation records that these arrived in version 5.6, released in December 2020, so anything current supports them.
- Write the persona file properly. This is the highest-leverage hour in the whole setup, and the one people rush.
- Publish your first three articles as drafts. Read them end to end. Fix the persona, not the article.
- Only then let anything go straight to live, and keep
byline doctorin your routine so a rotated key surfaces on your schedule rather than a reader's.
The code is MIT licensed and the architecture is deliberately platform-agnostic, so a new destination is one folder and one line of code. If your team publishes to a newsletter or a partner site as well as a blog, that's the extension worth building first.
The bigger picture is that this is what production AI looks like inside a real workflow. Not a demo. Not a chat window you copy out of. A tool with credentials, permissions, verification and a scorecard, doing a job that someone used to do by hand at 11pm. Pick the noisiest manual step in your own content pipeline this week, and ask whether an assistant could hold the credential for it. That question is more useful than any model comparison you'll read this year.
Frequently asked questions
Is Byline free to use?
Byline is open source under the MIT licence and free to install and run. Costs come from the services you connect to it, not the tool itself: an image provider such as Gemini or Grok, and optionally a research provider such as Brave or Tavily. The blog credentials are your own, and there is no hosted account.
Does Byline work with WordPress as well as Ghost?
Yes. Byline supports both Ghost and WordPress today, authenticating to Ghost with an Admin API key and to WordPress with an Application Password. The writing brief adapts to each platform's ingest rules, and it reports WordPress core's inability to inject JSON-LD into the page head as a warning rather than failing silently.
Where are my blog credentials stored?
Credentials live only on your own machine, in ~/.byline/.env with owner-only file permissions. The config file references them as variable names rather than values, so it stays safe to share or commit. Keys are sent only in Authorization headers to the APIs you configured, with no telemetry and no hosted component.
