You run a publication on Hashnode, and you have been putting off letting an AI client near it. Not because you doubt the idea. Because every setup you have seen starts the same way: generate a token, paste it somewhere, and hope it never ends up in a chat transcript or a config file you forgot about. So the blog stays manual, and the drafts pile up.
Hashnode has just published a post that goes straight at that hesitation. It describes a remote MCP server that lets AI clients "publish, draft, edit, search, and delete posts" on a Hashnode blog. The pitch is short: "Add one URL, log in with your Hashnode account, and you're connected. No API token, nothing to install."
Here is what that looks like for you. In Claude Code it is one command. In ChatGPT and other clients, you paste the same URL where the client asks for a remote server. Then, in the post's words, "your browser opens Hashnode. Log in and approve access." That is the whole setup. The post gives no figures, and it doesn't need any, because the access model is the substance. "You never handle a token. Every client you connect shows up in Developer Settings, and you can disconnect any of them at any time. Access stops immediately."
If you run a team blog, the roles matter as much as the login. The tool list follows the publication's existing roles. Contributors "can't publish directly," so when an agent works for a contributor it submits a draft for review, and an owner or admin publishes it. There are tools for submitting, rejecting and listing drafts awaiting review. You don't have to invent a new approval process for the agent. The one you already have applies.
Then comes the simplest safety advice in the series, and it is worth taking literally: "Posts go live immediately. To look first, ask your agent to save a draft, then publish it when you're ready." If you take one habit from this, take that one.
The post also tells you which door to use. If you work with a coding agent and want the full GraphQL API, there is a skill for that. If you are in a chat client, or you would simply rather not manage a token, use the MCP server.
Now the turn, and it concerns the record rather than the launch. APIs.io holds the API underneath this, the Hashnode GraphQL API on the Hashnode provider page. Its Agent Readiness score lights up spec presence, auth clarity, error semantics, the rate limit signal, the event surface and agent skills. What it does not light up is the MCP server itself, along with delegated identity, protected resource metadata and dynamic client registration. Those last three are what a log-in-and-approve remote server without a token typically implements. So by the catalog's own account, the thing Hashnode just announced is the thing the catalog can't yet see.
That is a gap in the catalog's timing, not necessarily in Hashnode's work. The launch is newer than the record's last probe. For now the Kin Score sits at 56.9, in the strong band, with developer ergonomics at 78.6 and operational transparency at 63.2, against contract governance at 4.5. The Agent Readiness score is 28.8, agent-ready, and it should move on the next pass if the server publishes the metadata its login flow implies.
What do you take away? First, you can connect an agent to your blog without ever putting a secret in a transcript, and you can cut it off from Developer Settings whenever you like. Second, draft first, then publish, because posts go live immediately. Third, your contributor and reviewer roles already act as a human in the loop, built into the publication rather than bolted onto the agent. The post deserves credit for both, since a draft-first workflow is a dry run expressed in the product. And when you read a score for this API today, remember it predates the launch. The record needs one more probe to see it.
Read the original: https://apis.io/2026/10/20/hashnode-ships-an-mcp-server-with-no-token-to-handle/