hashnode-mcp-server

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.1.1
Disambiguation5/5
Each tool targets a distinct resource and action: user, publication, drafts, and posts each have their own verbs (get/list/create/update/publish/delete). The overlap between publish_post and create_draft+publish_draft is explicitly disambiguated, making tool selection clear.
Naming Consistency5/5
All tools follow the consistent pattern 'hashnode_<verb>_<resource>' in snake_case (e.g., get_me, list_drafts, update_post). There are no mixed conventions or vague names.
Tool Count5/5
11 tools is well-scoped for a blog platform, covering user info, publication lookup, draft management (list/create/update/publish), and post management (list/get/publish/update/delete). Each tool earns its place without bloat.
Completeness4/5
The core blogging workflow is covered, including draft creation, updating, publishing, and post lifecycle. Minor gaps exist: there is no delete_draft or unpublish post operation, which agents might need for full lifecycle management.
Average 4.2/5 across 11 of 11 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 21 commits in the last 12 weeks
- Last stable release on June 26, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior, so the bar is lower. The description adds value by specifying the response includes content brief, views, tags, cover image, and author, and it mentions the response_format option. However, it does not disclose any additional behavioral traits like rate limits or error cases, so a 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact, separated into Args and Returns sections, and clearly front-loads the main purpose. It avoids unnecessary fluff, though the Args list slightly duplicates schema info. The format is easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (3 params, no output schema), the description is sufficiently complete: it states the purpose, lists required and optional parameters, and describes the return content. It does not mention authentication or error scenarios, but annotations cover safety and read-only behavior, so no major gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage, describing all three parameters (host, slug, response_format) with types and constraints. The description adds a concrete example for slug ('my-first-post') and restates the response_format options, but does not provide significant new meaning beyond the schema. Baseline 3 is fitting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool fetches full details of a single published post by slug, with a specific verb (fetch) and resource (published post). This distinguishes it from siblings like hashnode_list_posts (which lists posts) and hashnode_get_publication (which gets publication info).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when a specific post slug is known and full details are needed, contrasting with list_posts for summaries. It does not explicitly name alternatives or state when not to use, but the context is clear from the phrase 'single post by slug' and the listed return fields.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=false and destructiveHint=false, so the mutation behavior is known. The description adds the key behavioral nuance that only provided fields are changed, which is important for partial updates. It does not mention auth requirements or rate limits, but with annotations present, this is acceptable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with a meaningful sentence, but the subsequent 'Args:' list redundantly repeats parameter information already present in the input schema. This adds bloat without new information. It is readable, but not every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 7-parameter mutation tool with 100% schema coverage and annotations, the description covers the essential partial-update behavior and output format options. It does not describe the return value or potential errors, but no output schema exists and the tool's purpose is straightforward. Overall, it is sufficiently complete for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the input schema fully documents each parameter. The description duplicates the parameter list without adding new per-parameter semantic detail. However, the introductory sentence clarifies the partial-update semantics of optional parameters, which adds value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Update fields of an existing draft' with a specific verb and resource, and the title reinforces this. It distinguishes itself from siblings like create_draft and publish_draft by focusing on modifying an existing draft. The phrase 'Only provided fields are changed' adds valuable scope clarification.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for modifying an existing draft versus creating or publishing one. It does not explicitly name alternatives like hashnode_create_draft or hashnode_update_post, but the 'existing draft' context is unambiguous. It lacks explicit exclusions or fallback guidance, but the intended use case is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral context with 'Only provided fields are changed', clarifying that unspecified fields remain untouched, which is valuable beyond the annotations. It complements the readOnlyHint=false and destructiveHint=false by indicating partial-update semantics without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear first sentence and a formatted Args list. However, the Args section duplicates schema information, making it longer than necessary. The 'Only provided fields are changed' note adds value, and the overall structure remains easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, and the description does not explicitly state what the operation returns (e.g., updated post object or success message). While the 'response_format' parameter hints at output format, it lacks clarity on the return value. The description covers input parameters well but leaves the response ambiguous.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the description's Args section largely reiterates the schema without adding new semantic meaning (e.g., no examples, no constraints on tag slugs). It provides a minimal convenience by referencing where to obtain post_id, but does not exceed the baseline for fully documented schemas.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Update') and a clearly defined resource ('fields of an already-published post'), distinguishing it from sibling tools like hashnode_update_draft which target drafts. The phrase 'already-published' is crucial for disambiguation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly states the tool operates on already-published posts, which guides the agent on when to use it versus draft-focused siblings. However, it does not explicitly name alternatives or provide exclusion conditions beyond this scope.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate non-read-only and non-idempotent behavior. The description adds the important nuance that this tool only creates a draft and does not publish, plus it lists the return fields. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The opening sentences are concise and front-loaded with crucial workflow info. However, the exhaustive Args list duplicates schema descriptions, adding length without new information. It could be trimmed to just the non-obvious notes.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description compensates by listing return fields (draft id, title, slug, tags, updatedAt). Combined with the 100% schema coverage and annotations, the tool is well-specified for correct invocation. Minor gaps like error handling are not critical.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema covers 100% of parameters with descriptions. The Args list in the description largely repeats schema information, adding only minor clarifications like 'slug must be lowercase with hyphens' which is already in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it creates a new draft in a Hashnode publication, using a specific verb and resource. It also distinguishes itself from the sibling tool hashnode_publish_draft by explicitly noting it does not publish.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Does NOT publish — use hashnode_publish_draft afterwards.' This provides clear when-to-use guidance and names the alternative, fulfilling the behavioral exclusion requirement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds the response structure (fields and publications array), which is helpful, but it doesn't disclose potential failure modes (e.g., unauthenticated requests) or pagination. Given strong annotations, this is acceptable but not exceptional.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is succinct and well-structured: a one-sentence core purpose, a bulleted list of returns, and two concrete examples. Every sentence earns its place, and the most important usage guidance is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with no output schema and one optional parameter, the description is complete enough. It explains what the tool returns and when to use it, but it omits edge cases like empty publications or authentication errors. These are minor for such a straightforward tool, so a slight deduction is appropriate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single parameter (response_format), with the schema already providing its description and enum. The tool description adds no further parameter details, so it stays at the baseline 3 without needing to compensate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Returns the authenticated user's profile and a list of their publications', using a specific verb and resource. It also distinguishes itself from sibling tools by noting 'Use this first to discover your publicationId(s) before creating or listing posts.'
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use this first to discover your publicationId(s) before creating or listing posts', providing clear when-to-use context. Examples such as 'What is my publication ID?' and 'List my Hashnode blogs' further illustrate appropriate use cases, making it easy to select this tool over siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true. The description adds useful behavioral details such as pagination via 'after', response formats, and the returned field list, going beyond what annotations provide without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: a short intro, bulleted arguments, and a return specification. Every sentence carries useful information with no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only list operation, the description covers the required argument, optional pagination, and return fields. It does not provide an example or detail error scenarios, but for a low-risk read-only tool with annotations, the level of detail is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description repeats parameter details already present in the schema (e.g., default limit, pagination cursor) and adds minimal new semantics like 'from hashnode_get_me' and 'max 50', which are already in the schema properties.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List drafts in a Hashnode publication' with a specific verb and resource. It is distinct from sibling tools like hashnode_list_posts and hashnode_publish_draft, leaving no ambiguity about its function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context that publication_id comes from hashnode_get_me, suggesting a workflow. However, it does not explicitly mention when to use this over hashnode_list_posts or other alternatives, so guidance is implied rather than stated directly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already indicate destructiveHint=true, but the description adds crucial context: 'permanently delete', 'cannot be undone', and a warning. This goes beyond the structured data, clearly disclosing the irreversible destructive nature. It does not mention authentication or other behaviors, but for a simple delete tool this is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the essential action and warning. The Args list and warning are clearly structured, and every sentence contributes to understanding the tool's purpose and risks. No waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple nature of the delete operation and the fact that the input schema fully documents parameters, the description is complete. It covers the action, irreversibility, required param, and optional response_format. No output schema is needed for a tool with such straightforward behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already fully documents both parameters. The description lists the parameters but adds no new meaning beyond what the schema provides. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific verb 'delete' and the resource 'published post', distinguishing it from sibling tools like update or get. The permanent nature is emphasized, clarifying the exact scope of the operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool: to permanently delete a published post. However, it does not explicitly address when not to use it or mention alternative tools for deletion vs. updating/drafting. The warning about irreversibility adds important contextual guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, so the tool's safety is known. The description adds transparency by listing the returned fields (id, title, url, about, author info) and noting the configurable response_format, which helps set expectations beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-structured with clear sections for args, returns, and examples. Every sentence adds useful information without unnecessary fluff, and the main purpose is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with two parameters and full schema coverage, the description provides enough detail: it states purpose, parameters, return fields, and an example. The absence of an output schema is compensated by the explicit return list, making the description complete for an agent to invoke successfully.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description repeats parameter explanations and adds an example host value, providing marginal value beyond the schema but not significantly enriching parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Fetch metadata for a Hashnode publication by its host/domain', using a specific verb and resource. It distinguishes this tool from sibling tools like get_me or get_post by emphasizing publication-level metadata and host/domain identification.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on when to use the tool (to fetch publication metadata by host/domain) and includes a concrete example. It does not explicitly mention alternatives or exclusions, but the usage intent is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. The description adds value by specifying the return fields (id, title, slug, url, publishedAt, views, readTime, tags), the default ordering, and pagination cursor behavior. This enriches the agent's understanding beyond the annotations without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: it opens with a clear summary sentence, then lists parameters in an Args block and concludes with a Returns line. Every element earns its place, with no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, the presence of a complete schema, and rich annotations, the description is sufficient. It covers the key contextual aspects: ordering, pagination via the 'after' cursor, allowed response formats, and the returned fields. There is no output schema, but the Returns line fills that gap. No additional information seems necessary.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides full descriptions for all four parameters (host, after, limit, response_format) with defaults and constraints. The description largely repeats this information (e.g., limit default 20 max 50, after as cursor). It does not introduce new semantic details beyond what the schema covers, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List'), names the resource ('published blog posts'), and adds scoping details ('in a publication', 'ordered by publish date (newest first)'). It clearly distinguishes from sibling tools like hashnode_list_drafts by explicitly stating 'published'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a clear context for when to use this tool (listing published posts) and mentions ordering/pagination. It does not explicitly name alternatives or exclusions, but the sibling tool names (e.g., list_drafts) imply the distinction. This matches 'clear context, no exclusions'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false, idempotentHint=false, and destructiveHint=false. The description adds that the draft becomes a live post and lists return fields, but does not disclose side effects like the draft being consumed. This is adequate given the annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: a one-sentence summary, an args section, a returns section, and an example. Every part serves a purpose with no redundant content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with 2 parameters, annotations, and a return list, the description is complete. It covers the action, parameter sourcing, output format, and return value, along with a helpful example.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes both parameters with 100% coverage. The description adds value by specifying that draft_id should be obtained from hashnode_create_draft or hashnode_list_drafts, which is helpful beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Publish an existing draft, making it a live blog post', specifying the action and result. It also distinguishes itself from sibling tools like create_draft or publish_post by focusing on the draft-to-post transition.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context by indicating that draft_id comes from hashnode_create_draft or hashnode_list_drafts, and shows a typical workflow. It does not explicitly mention alternatives or exclusions, but the example clarifies the intended use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate this is a mutating, non-idempotent operation. The description adds context that the publication happens directly without a draft step, emphasizing immediacy and the lack of a review buffer. It also lists the returned fields, which is helpful behavioral output information.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with purpose and workflow guidance, followed by a structured parameter list and return values. It is somewhat long due to 12 parameters, but every section is purposeful and there is no filler. The format is easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex publishing tool with 12 parameters and no output schema, the description covers the essential context: what it does, when to use an alternative, all parameters, and the return structure. It is complete enough for an agent to select and invoke the tool correctly without needing additional external context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already covers all 12 parameters with detailed descriptions (100% coverage). The description adds a useful cross-reference for publication_id ('from hashnode_get_me') and restates the parameters in a compact list, making the tool self-contained. This goes slightly beyond the schema but is not a major extension.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'Publish a new blog post directly' and explicitly distinguishes itself from the draft workflow by stating 'without creating a draft first.' It is clearly differentiated from sibling tools like hashnode_create_draft and hashnode_publish_draft.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly recommends an alternative workflow: 'Prefer hashnode_create_draft + hashnode_publish_draft for a safer workflow.' This tells the agent when not to use the tool and names the safer alternative, making the usage context clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![mcp-hashnode MCP server](https://glama.ai/mcp/servers/kieksme/mcp-hashnode/badges/card.svg)](https://glama.ai/mcp/servers/kieksme/mcp-hashnode)

Score Badge

Copy to your README.md:

[![mcp-hashnode MCP server](https://glama.ai/mcp/servers/kieksme/mcp-hashnode/badges/score.svg)](https://glama.ai/mcp/servers/kieksme/mcp-hashnode)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/kieksme/mcp-hashnode'

If you have feedback or need assistance with the MCP directory API, please join our Discord server