Which integrations are available for this server?

Enables conversion of Markdown content into styled HTML specifically optimized for seamless pasting into Google Docs with preserved formatting. Provides tools to convert Markdown into various styled document formats, manage a document library, and publish Markdown content to shareable public URLs. Converts Markdown text into formatting optimized for Slack's messaging interface, including support for bold text, lists, and code blocks.

How do I use Unmarkdown MCP Server?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Unmarkdown MCP Server Convert these meeting notes for Google Docs using the Executive template" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

Unmarkdown MCP Server

by UnMarkdown

Overview Schema Related Servers Score Discussions

JavaScript

Remote

Unmarkdown MCP Server

npm version License: MIT Smithery

A Model Context Protocol (MCP) server that connects AI assistants to the Unmarkdown API. Convert markdown to beautifully formatted documents, manage your document library, and publish pages to the web, all from inside Claude, Cursor, VS Code, or any MCP-compatible client.

Also available as: Chrome Extension | Web App | REST API

Features

Convert markdown to styled HTML for 8 destinations: Google Docs, Word, Slack, OneNote, Email, Plain Text, generic HTML, and raw HTML
62 visual templates with light and dark themes (Swiss, Executive, Terminal, GitHub, and more)
Create, read, update documents in your Unmarkdown library, organized into folders
Publish documents to shareable public URLs at unmarkdown.com/d/your-slug
Track API usage and quota for the current billing period

Related MCP server: Gen-PDF MCP Server

Installation

Claude Desktop / Claude for macOS

Add this to your Claude Desktop configuration file:

macOS: ~/Library/Application Support/Claude/claude_desktop_config.json Windows: %APPDATA%\Claude\claude_desktop_config.json

{
  "mcpServers": {
    "unmarkdown": {
      "command": "npx",
      "args": ["-y", "@un-markdown/mcp-server"],
      "env": {
        "UNMARKDOWN_API_KEY": "um_your_api_key_here"
      }
    }
  }
}

Cursor

Add to your Cursor MCP settings (.cursor/mcp.json):

{
  "mcpServers": {
    "unmarkdown": {
      "command": "npx",
      "args": ["-y", "@un-markdown/mcp-server"],
      "env": {
        "UNMARKDOWN_API_KEY": "um_your_api_key_here"
      }
    }
  }
}

VS Code

Add to your VS Code MCP settings (.vscode/mcp.json):

{
  "servers": {
    "unmarkdown": {
      "command": "npx",
      "args": ["-y", "@un-markdown/mcp-server"],
      "env": {
        "UNMARKDOWN_API_KEY": "um_your_api_key_here"
      }
    }
  }
}

Global Installation

If you prefer to install globally instead of using npx:

npm install -g @un-markdown/mcp-server

Then use unmarkdown-mcp as the command instead of npx:

{
  "mcpServers": {
    "unmarkdown": {
      "command": "unmarkdown-mcp",
      "env": {
        "UNMARKDOWN_API_KEY": "um_your_api_key_here"
      }
    }
  }
}

Configuration

Required

Variable	Description
`UNMARKDOWN_API_KEY`	Your Unmarkdown API key (starts with `um_`). Get one from Settings > API in your Unmarkdown account.

Optional

Variable	Description	Default
`UNMARKDOWN_API_URL`	Custom API base URL	`https://api.unmarkdown.com`

Usage Examples

Example 1: Convert a meeting notes draft for Google Docs

"Take this markdown and convert it for Google Docs using the Executive template:

# Q1 Planning Meeting

## Attendees
- Sarah Chen (Product)
- Mike Torres (Engineering)
- Lisa Park (Design)

## Action Items
- [ ] Finalize roadmap by Friday
- [ ] Schedule design review for new dashboard
- [ ] Update stakeholder presentation
```"

Claude will use the convert_markdown tool with destination: "google-docs" and template_id: "executive", returning styled HTML ready to paste into Google Docs with proper headings, fonts, and colors.

Example 2: Create a document in a folder

"Create a new document called 'API Changelog - February 2026' in my Release Notes folder with this content, then publish it."

Claude will:

Call create_document with the title, markdown content, and folder: "Release Notes"
Call publish_document with the returned document ID

The document is created directly in the specified folder, and you get back a live URL like https://unmarkdown.com/d/api-changelog-february-2026.

Example 3: Update and move a document

"Move the Q4 report to the Archive folder and update its title."

Claude will:

Call list_documents to find the document
Call update_document with the new title and folder: "Archive"

Example 4: Format markdown for Slack

"Convert this project update to Slack format so it looks good when I paste it in our team channel."

Claude uses convert_markdown with destination: "slack", producing output optimized for Slack's rendering (bold, lists, code blocks, emoji support).

Example 5: Check API usage

"How many API calls have I used this month?"

Claude calls get_usage and returns your current usage count, monthly limit, and billing period.

Tools Reference

Tool	Description	Read-only	Idempotent
`convert_markdown`	Convert markdown to styled HTML for any of 8 destinations	Yes	Yes
`create_document`	Create a new document in your library (optionally in a folder)	No	No
`list_documents`	List saved documents with pagination (optionally filter by folder)	Yes	Yes
`get_document`	Fetch a document by ID with full content	Yes	Yes
`update_document`	Modify a document's title, content, template, metadata, or folder	No	Yes
`publish_document`	Publish a document to a shareable public URL	No	Yes
`get_usage`	Check API quota for the current billing month	Yes	Yes

Destinations

The convert_markdown tool supports these output formats:

Destination	Description
`google-docs`	Optimized for pasting into Google Docs
`word`	Formatted for Microsoft Word
`slack`	Slack-compatible formatting
`onenote`	Microsoft OneNote compatible
`email`	Email client friendly HTML
`plain-text`	Plain text with ASCII formatting
`generic`	General-purpose styled HTML
`html`	Raw HTML output

Templates

Pass any template ID to convert_markdown, create_document, or update_document. Popular templates include:

Template	Category
`swiss`	Free (default)
`mono`	Free
`github`	Free
`terminal`	Free
`executive`	Business (Pro)
`consulting`	Business (Pro)
`startup`	Business (Pro)

Browse all 62 templates at unmarkdown.com/templates.

API Limits

Plan	Monthly API Calls	Rate Limit
Free	1,000	10 req/sec
Pro ($8/mo annual)	10,000	30 req/sec

Overage: $1.00 per 1,000 additional calls (Pro only). Free plan has a hard limit.

Privacy

This MCP server sends your markdown content and document data to the Unmarkdown API (api.unmarkdown.com) for processing. No data is stored locally by the MCP server itself. All data handling is governed by the Unmarkdown Privacy Policy.

Specifically:

Markdown content sent via convert_markdown is processed and returned immediately. It is not stored on Unmarkdown servers.
Documents created via create_document or update_document are stored in your Unmarkdown account and can be deleted at any time.
API keys authenticate requests and are never logged or shared.

For the full privacy policy, visit unmarkdown.com/privacy.

Support

Issues: github.com/UnMarkdown/mcp-server/issues
Documentation: docs.unmarkdown.com
API Reference: docs.unmarkdown.com/api/overview
Contact: unmarkdown.com/contact

Development

# Clone the repo
git clone https://github.com/UnMarkdown/mcp-server.git
cd mcp-server

# Install dependencies
npm install

# Build
npm run build

# Run locally (requires API key)
UNMARKDOWN_API_KEY=um_your_key node build/index.js

License

MIT. See LICENSE for details.

Available Tools

7 tools

convert_markdownA

Read-onlyIdempotent

Inspect

Convert markdown to destination-specific HTML and plain text. Returns JSON with 'html' and 'plain_text' fields. For Slack, present the plain_text to the user. For Google Docs/Word/OneNote, direct users to unmarkdown.com to use the copy button (raw HTML cannot be pasted into these apps). Does not render Chart.js, Mermaid, Graphviz, or KaTeX; use publish_document for documents with diagrams or math.

ParametersJSON Schema

Name	Required	Description
`markdown`	Yes	Markdown content to convert
`destination`	No	Target format (default: "generic")
`template_id`	No	Visual template ID (default: "swiss")
`theme_mode`	No	Color theme (default: "light")

TDQS

A4.7/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already indicate read-only, idempotent, non-destructive; description adds key behavioral details: output format (JSON with html/plain_text), paste limitations for certain apps, and unsupported rendering features.

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?

Very concise, well-structured: purpose, output format, destination-specific instructions, limitations, and alternative. Every sentence adds value.

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?

The tool is simple (4 params, no output schema) and the description covers output, usage constraints, and alternatives, making it fully actionable.

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?

With 100% schema description coverage, the schema already explains all parameters adequately; the description does not add significant new meaning beyond what schema provides.

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 converts markdown to destination-specific HTML and plain text, and explicitly distinguishes from sibling publish_document by noting limitations (no diagram/math rendering).

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?

Provides explicit instructions for different destinations (e.g., Slack: use plain_text; Google Docs/Word/OneNote: use unmarkdown.com) and directly says when to use publish_document instead.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

create_documentBInspect

Create a new markdown document in Unmarkdown

ParametersJSON Schema

Name	Required	Description
`title`	No	Document title
`content`	No	Markdown content (default: empty)
`folder`	No	Folder name (case-insensitive) or folder ID to place the document in
`template_id`	No	Visual template ID (default: "swiss")
`theme_mode`	No	Color theme (default: "light")

TDQS

B3.3/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations provide readOnlyHint=false, destructiveHint=false, idempotentHint=false, and openWorldHint=true. The description adds little beyond stating creation. It does not disclose return behavior, error handling, or side effects, which is minimal given no output schema.

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 a single, concise sentence. It is front-loaded and easy to parse, but it is somewhat terse and could provide more utility without sacrificing brevity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema and 5 parameters fully described in the schema, the description lacks completeness about return values, success conditions, or potential errors. It does not sufficiently compensate for the absence of output schema information.

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 documents all parameters. The description does not add extra meaning beyond stating the tool creates a document, so 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 action (create), resource (markdown document), and context (Unmarkdown). It distinguishes from sibling tools like update_document, get_document, and convert_markdown by specifying creation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies when to use the tool (to create a new document) but provides no explicit guidance on alternatives or when not to use it. Given sibling tools exist (e.g., update_document), this is a gap.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_documentA

Read-onlyIdempotent

Inspect

Get a document by ID, including its full markdown content

ParametersJSON Schema

Name	Required	Description	Default
`id`	Yes	Document UUID

TDQS

A3.9/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, idempotentHint=true, etc. Description adds that the response includes full markdown content, but no further behavioral details. Adequate given 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?

One concise sentence, front-loaded with key information. No wasted words.

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 one parameter and no output schema, the description is sufficient: it states the operation, parameter, and return content.

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 has 100% coverage with a clear description for the single 'id' parameter. Description does not add extra semantics beyond stating retrieval by ID.

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?

Description clearly states the action (Get), resource (document), method (by ID), and content included (full markdown). Distinguishes from sibling tools like list_documents and update_document.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit guidance on when to use vs alternatives like list_documents for searching or create_document for new ones. However, for a simple retrieval tool, usage is implicitly clear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_usageA

Read-onlyIdempotent

Inspect

Check your API usage quota for the current billing month

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.2/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already indicate read-only, non-destructive, idempotent; description adds temporal context 'current billing month', but no details on response or potential errors.

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?

Single sentence, 10 words, front-loaded and efficient.

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?

Simple tool with no parameters; annotations cover safety; description adds usage period; lacks response format but adequate for a quota check.

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?

No parameters in schema; description not needed for parameter semantics, baseline 4 applies.

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?

Description states specific verb 'check' and resource 'API usage quota for the current billing month', clearly distinguishing it from sibling document tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit when-to-use or when-not-to-use guidance, but context with siblings makes purpose clear; could be improved with prerequisites or alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_documentsA

Read-onlyIdempotent

Inspect

List your saved documents with pagination. Optionally filter by folder name or ID.

ParametersJSON Schema

Name	Required	Description
`folder`	No	Optional. Filter by folder name (case-insensitive) or folder ID.
`limit`	No	Max results per page (default: 20, max: 100)
`cursor`	No	Pagination cursor from a previous response

TDQS

A4.1/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already mark it as read-only, idempotent, and non-destructive. The description adds pagination and filtering behavior, which goes beyond annotations, but omits details like rate limits or error handling.

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?

A single, front-loaded sentence that efficiently conveys the tool's main purpose and optional features with no wasted words.

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 list operation with 3 optional parameters and no output schema, the description covers pagination and filtering adequately, leaving no critical gaps.

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 provides 100% coverage of parameter descriptions, so the description adds little beyond stating optional filtering. Baseline 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 tool lists saved documents with pagination and optional filtering. It distinguishes from siblings like 'get_document' (single document) and 'create_document'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for listing with optional filtering, but no explicit guidance on when not to use or alternatives (e.g., search). Usage is clear from context but not fully explicit.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

publish_documentA

Idempotent

Inspect

Publish a document to a shareable web page. Default visibility is 'link' (unlisted). Published pages render all content including Chart.js charts, Mermaid diagrams, Graphviz graphs, and KaTeX math. Email-based sharing is not available here; direct users to unmarkdown.com for that.

ParametersJSON Schema

Name	Required	Description
`id`	Yes	Document UUID
`slug`	No	Custom URL slug (auto-generated if omitted)
`description`	No	SEO description for published page
`visibility`	No	"public" or "link" (default, unlisted)
`page_width`	No	Page width for published view

TDQS

A4.2/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already indicate non-destructive, idempotent, open-world. The description adds that published pages render specific chart/diagram content and default visibility, which is beyond annotations and helpful. No contradictions.

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?

Two sentences, no fluff, front-loaded with verb and resource. 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?

Given annotations and schema, the description covers purpose, defaults, rendering, and an exclusion. No output schema, but the description implies what to expect (published page with content). Could mention the response, but overall complete.

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 has 100% coverage for parameters; description adds minimal new info (e.g., default visibility already in schema, rendering details not parameter-specific). Does not enhance parameter meaning beyond 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 the tool publishes a document to a shareable web page, specifies default visibility, and lists supported content types, distinguishing it from siblings like create_document or update_document.

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?

It provides context on when to use (publishing to web) and explicitly says email-based sharing is not available here, directing users elsewhere. However, it does not explicitly contrast with all siblings or state prerequisites.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

update_documentC

Idempotent

Inspect

Update a document's content or metadata

ParametersJSON Schema

Name	Required	Description
`id`	Yes	Document UUID
`title`	No	New title
`content`	No	New markdown content
`folder`	No	Move to folder by name (case-insensitive) or folder ID. Set to null to move to Unfiled.
`template_id`	No	New template ID
`theme_mode`	No	New color theme
`description`	No	Document description (null to clear)
`page_width`	No	Page width for published view

TDQS

C2.9/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=false, destructiveHint=false, idempotentHint=true, openWorldHint=true. The description adds no behavioral context beyond what the annotations imply (e.g., no mention of partial updates, idempotency, or what happens with missing fields).

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?

A single concise sentence that is front-loaded. Could be slightly more informative without sacrificing conciseness.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema, and the description does not mention return values or behavior for the 8 parameters. Given the tool's complexity and the lack of return value documentation, the description is insufficient.

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 coverage is 100%, so baseline is 3. The description summarizes 'content or metadata' but does not add meaning beyond the schema's parameter descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action (update) and the resource (document), plus specifies scope (content or metadata). However, it does not distinguish from sibling tools like create_document or publish_document.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool vs. alternatives such as create_document or publish_document. The description lacks usage context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.9/5.0

Disambiguation5/5

Each tool targets a distinct operation: conversion, document CRUD (except delete), publishing, and usage. No overlap in purposes.

Naming Consistency5/5

All tools follow a consistent verb_noun pattern (e.g., convert_markdown, create_document, get_usage). No mixing of styles.

Tool Count5/5

7 tools is well-scoped for a document management and conversion service, covering essential operations without excess or deficiency.

Completeness4/5

Covers create, read, update, list, conversion, and publishing, but lacks a delete_document tool, which is a notable gap in basic CRUD operations.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

Need Help?

Reddit Discussion

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

mcp
com.mdtidy
Clean, repair, and convert AI-generated Markdown to HTML/PDF/DOCX/PNG; save and share documents.
Content Management Systems Developer Tools
2
drafturl A
io.github.Bamdule
Share HTML/Markdown documents via URL instantly. Create, edit, delete docs from any AI tool.
Content Management Systems App Automation Workplace & Productivity
2
GRTwo Docs
io.github.grtwo-jcansler
Publish and share Markdown/HTML docs from AI assistants. Requires grtwo.app Pro. OAuth or API key.
Content Management Systems Documentation Access
2
file2markdown A
ai.file2markdown
Convert documents and web pages to clean Markdown: PDF, DOCX, XLSX, EPUB, scanned files, any URL.
Browser Automation Documentation Access Web Scraping
41

Related MCP Servers

Confluence MCP Server
Content Management Systems Developer Tools App Automation
manateeit
F
license
Not graded
quality
D
maintenance
Enables AI assistants to interact with Confluence by converting Markdown documents to professionally styled Confluence pages with Mermaid diagram support.
Updated a year ago (2025-06-11 03:21 UTC)
19
1
Gen-PDF MCP Server
Developer Tools Content Management Systems Workplace & Productivity
gen-pdf
A
license
Not graded
quality
D
maintenance
Enables AI assistants to generate professional PDF documents from markdown content with advanced typography, syntax highlighting, math equations, dark mode, and customizable styling options.
Updated 6 months ago (2026-03-11 22:55 UTC)
MIT
Word MCP Server
Workplace & Productivity Content Management Systems Developer Tools
mndambuki
F
license
Not graded
quality
D
maintenance
Enables creation and management of Word documents from markdown content, with support for multiple templates and conversion of chat conversations to formatted Word documents.
Updated 9 months ago (2025-12-07 09:04 UTC)
AI Answer Copier
App Automation Developer Tools Education & Learning Tools
XJTLUmedia
A
license
A
quality
D
maintenance
A Model Context Protocol (MCP) server that gives your AI assistant the power to convert Markdown into 14 professional document formats — PDF, DOCX, HTML, LaTeX, CSV, JSON, XML, XLSX, RTF, PNG, and more. Stop copy-pasting. Let the AI do the exporting.
Updated 5 months ago (2026-04-20 05:37 UTC)
33
3
MIT

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/UnMarkdown/mcp-server'

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

Unmarkdown MCP Server

Features

Installation

Claude Desktop / Claude for macOS

Cursor

VS Code

Global Installation

Configuration

Required

Optional

Usage Examples

Example 1: Convert a meeting notes draft for Google Docs

Example 2: Create a document in a folder

Example 3: Update and move a document

Example 4: Format markdown for Slack

Example 5: Check API usage

Tools Reference

Destinations

Templates

API Limits

Privacy

Support

Development

See Also

License

Available Tools

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API