AI & MCP
Point Claude — or any MCP client — at Hubcast, and it drafts, tailors and schedules posts for Facebook, Instagram, X, TikTok and Bluesky in your own workspace. You keep the say over what ships.
It is a hosted, remote MCP server. There is nothing to install and no process to keep running — you add a URL.
Step one
In your client’s connector settings, add:
https://www.hubcast.io/api/mcp
The client registers itself; there is no key to paste and no application to fill in.
Step two
You sign in as yourself and read a consent screen that lists the connection’s abilities one by one, and names the workspaces it will cover. It acts with your role — it cannot reach anything you cannot. If Hubcast later widens what an assistant may do, the connection stops and asks again rather than growing quietly.
Step three
In plain language, in whatever language you work in. It reads your brand, checks what each channel accepts, writes the per-channel versions and leaves them as drafts for you to approve.
No OAuth in your client? Mint a Personal Access Token in Settings instead, pick how long it should live, and send it as a bearer token. Tokens are stored only as a hash and can be revoked at any time.
The whole surface, named. This list is generated from the server, so it is the one the connection actually exposes.
The newsletter tools are open to workspaces on the newsletters beta — ask at [email protected]. A newsletter can never be sent over MCP; there is no tool for it.
Yes — a remote one, hosted, at https://www.hubcast.io/api/mcp. Add that URL in any MCP client that supports remote servers and it registers itself, so there is nothing to install, run or keep running. There is also a local stdio server in the repository for development.
Any client that speaks the Model Context Protocol. Claude — the desktop app, the web app and Claude Code — is what it is tested against and what most people use it with. Hubcast does not ship a model and does not resell one: the assistant is yours, on your own subscription, and swapping it for a different one costs you nothing.
That is decided by the approval switch, not by the connection. With approval on, only a person can publish and the publish tool refuses outright, whoever is operating it. With approval off, an assistant can publish — the same latitude you have yourself, which is the point in a one-person workspace. Either way everything it creates lands as a draft in the same queue as everything else, stamped as having come from an assistant.
Your posts, the places you publish to, your media library's filenames and dimensions, and your brand settings. Not your newsletter subscribers. Media that has not been published is behind a session, and a connection token is not a session, so it gets a URL it cannot open.
By OAuth, through a consent screen that lists exactly what the connection may do and names the workspaces it will cover — you approve it as yourself, and it acts with your own role and nothing more. For a client that does not do OAuth, you can instead mint a Personal Access Token in Settings, choose how long it lives, and revoke it whenever you like. Tokens are stored only as a hash.
Existing connections stop and ask again. A consent screen is a promise about what a token can do, so widening the tool surface would otherwise quietly widen every token already approved under the old wording. Instead the consent version is bumped, tokens granted under the old screen are refused, and the client reconnects through the normal flow — where the holder reads the new list and approves it, or doesn't.
No. The MCP connection is in both plans, like every other feature, and it is optional and off until you connect something. You pay for your own assistant separately, to whoever provides it.
The connection is in every plan, optional, and off until you turn it on.