hashnode-mcp-server
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| HASHNODE_TOKEN | Yes | Your Hashnode Personal Access Token |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| hashnode_get_meA | Returns the authenticated user's profile and a list of their publications. Use this first to discover your publicationId(s) before creating or listing posts. Returns:
Examples:
|
| hashnode_get_publicationA | Fetch metadata for a Hashnode publication by its host/domain. Args:
Returns: id, title, url, about, author info Examples:
|
| hashnode_list_draftsA | List drafts in a Hashnode publication. Args:
Returns: list of drafts with id, title, subtitle, tags, updated date |
| hashnode_create_draftA | Create a new draft in a Hashnode publication. Does NOT publish — use hashnode_publish_draft afterwards. Args:
Returns: draft id, title, slug, tags, updatedAt |
| hashnode_update_draftB | Update fields of an existing draft. Only provided fields are changed. Args:
|
| hashnode_publish_draftA | Publish an existing draft, making it a live blog post. Args:
Returns: post id, title, slug, url, publishedAt, tags Examples:
|
| hashnode_list_postsA | List published blog posts in a publication, ordered by publish date (newest first). Args:
Returns: posts with id, title, slug, url, publishedAt, views, readTime, tags |
| hashnode_get_postA | Fetch full details of a published post by its slug. Args:
Returns: full post data including content brief, views, tags, cover image, author |
| hashnode_publish_postA | Publish a new blog post directly without creating a draft first. Prefer hashnode_create_draft + hashnode_publish_draft for a safer workflow. Args:
Returns: post id, title, slug, url, publishedAt, tags |
| hashnode_update_postA | Update fields of an already-published post. Only provided fields are changed. Args:
|
| hashnode_delete_postB | Permanently delete a published post. This action cannot be undone. Args:
⚠️ WARNING: This permanently deletes the post. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 11 tools
Each tool maps to a distinct resource (publication, draft, post) plus action, so most selections are unambiguous. The only real overlap is the two publishing paths — hashnode_publish_post versus hashnode_create_draft + hashnode_publish_draft — though the descriptions explicitly recommend the latter for safety.
Every tool uses the same hashnode_ prefix with a verb_noun structure (list_drafts, create_draft, publish_draft, update_post, delete_post). The lone outlier, hashnode_get_me, is still readable and consistent in style.
At 11 tools the surface is well-scoped: two discovery/read tools, a full draft lifecycle, and full post CRUD. No tool looks redundant enough to remove, and nothing feels padded.
Posts have full lifecycle coverage (list, get, publish, update, delete) and drafts cover list/create/update/publish. The notable gap is the absence of a delete_draft (and any comment operations), which agents can work around but leaves drafts unmanageable once created.