How do I use md-to-text?

1. Click on "Deploy 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., "@md-to-text Convert README.md to plain text" 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.

md-to-text

by MD-TO-TEXT

Overview Schema Source Related Servers Discussions Admin

TypeScript

Hybrid

Markdown to Text MCP Server

A powerful Model Context Protocol (MCP) server that converts Markdown documents to plain text. Supports both stdio and HTTP transport protocols for use as local tools or remote services.

Features

📝 Complete Markdown Support: Handles all common elements including headers, lists, links, images, code blocks, tables, etc.
🎛️ Flexible Conversion Options: Multiple output formats and style configurations
🔧 Dual Protocol Support: stdio mode (Claude Desktop) and HTTP mode (remote clients)
📁 Batch Processing: Directory scanning and bulk file conversion
🌐 URL Support: Direct processing of remote Markdown files
🔒 Security Hardened: Comprehensive input validation and security protection
⚡ High Performance: Optimized conversion engine with concurrency control

Related MCP server: markdown-to-html

Quick Start

Installation

Option 1: Clone and Build

git clone <repository-url>
cd md_to_text_mcp
npm install
npm run build

Option 2: Use with npx (Recommended)

# From npm registry (if published)
npx md_to_text_mcp --help

# From GitHub repository  
npx https://github.com/MD-TO-TEXT/md_to_text --help

# Local development
npm pack
npx ./md_to_text_mcp-1.0.0.tgz --help

Basic Usage

# Stdio mode (default)
npm start
# or with npx
npx md_to_text_mcp

# HTTP mode
npm run dev:http
# or with npx  
npx md_to_text_mcp --mode http --port 3000

Using with npx

npx allows you to run the tool without installing it globally. Here's how to use it:

Quick Test

# Test the tool help
npx md_to_text_mcp --help

# Run in stdio mode for Claude Desktop
npx md_to_text_mcp --mode stdio

# Start HTTP server
npx md_to_text_mcp --mode http --port 3000

# Custom configuration
npx md_to_text_mcp --mode http --host 0.0.0.0 --port 8080 --cors

From Local Package

If you're developing locally:

# Create package
npm run build
npm pack

# Run with npx
npx ./md_to_text_mcp-1.0.0.tgz --help
npx ./md_to_text_mcp-1.0.0.tgz --mode stdio

Integration with Claude Desktop via npx

You can configure Claude Desktop to use the tool via npx:

{
  "mcpServers": {
    "md-to-text": {
      "command": "npx",
      "args": ["md_to_text_mcp", "--mode", "stdio"],
      "cwd": "/tmp"
    }
  }
}

Note: Using npx in Claude Desktop config requires that the package is published to npm registry or available in a git repository.

Tools

convert_text - Text Conversion

Convert Markdown text directly to plain text.

convert_file - File Conversion

Read and convert local Markdown files.

convert_url - URL Conversion

Fetch and convert remote Markdown content from URLs.

batch_convert - Batch Conversion

Batch process Markdown files in directories.

Conversion Options

preserveLinks: Preserve link URLs
listStyle: List style (bullets/numbers/none)
codeHandling: Code handling (preserve/remove/inline)
tableFormat: Table format (simple/grid/none)
headingStyle: Heading style (hash/underline/none)

Claude Desktop Integration

Add to Claude for Desktop configuration file:

{
  "mcpServers": {
    "md-to-text": {
      "command": "node",
      "args": ["./build/index.js"],
      "cwd": "/path/to/md_to_text_mcp"
    }
  }
}

Command Line Options

md-to-text-mcp [OPTIONS]

OPTIONS:
  --mode <mode>         Server mode: 'stdio' or 'http' (default: stdio)
  --port <port>         HTTP server port (default: 3000)
  --host <host>         HTTP server host (default: localhost)
  --cors                Enable CORS for HTTP mode
  --no-cors             Disable CORS for HTTP mode
  --help, -h            Show help message

EXAMPLES:
  md-to-text-mcp                              # stdio mode
  md-to-text-mcp --mode http --port 3000      # HTTP mode
  md-to-text-mcp --mode http --host 0.0.0.0   # Allow external access

Environment Variables

Variable	Description	Default
`MCP_MODE`	Server mode (stdio/http)	stdio
`MCP_PORT`	HTTP server port	3000
`MCP_HOST`	HTTP server host	localhost
`MAX_FILE_SIZE`	Max file size (bytes)	10485760 (10MB)
`URL_TIMEOUT`	URL request timeout (ms)	30000 (30s)
`ALLOWED_EXTENSIONS`	Allowed file extensions	.md,.markdown,.txt

Docker Support

# Build image
docker build -t md-to-text-mcp .

# Run HTTP mode
docker run -p 3000:3000 md-to-text-mcp

# Health check
curl http://localhost:3000/health

API Examples

Text Conversion

{
  "name": "convert_text",
  "arguments": {
    "markdown": "# Hello World\n\nThis is **bold** text.",
    "options": {
      "preserveLinks": true,
      "listStyle": "bullets"
    }
  }
}

File Conversion

{
  "name": "convert_file",
  "arguments": {
    "path": "/path/to/document.md",
    "options": {
      "headingStyle": "underline"
    }
  }
}

URL Conversion

{
  "name": "convert_url",
  "arguments": {
    "url": "https://raw.githubusercontent.com/user/repo/main/README.md",
    "options": {
      "codeHandling": "remove"
    }
  }
}

Batch Conversion

{
  "name": "batch_convert",
  "arguments": {
    "directory": "/path/to/docs",
    "recursive": true,
    "options": {
      "tableFormat": "simple"
    }
  }
}

Security

The server includes multiple layers of security:

Path Traversal Protection: Prevents access to system directories
File Size Limits: Default 10MB maximum
URL Validation: Only allows HTTP/HTTPS protocols
Private IP Filtering: Blocks access to internal networks
Content Sanitization: Removes potentially malicious content
Request Timeouts: Prevents long-running operations

Development

Project Structure

src/
├── engine/          # Conversion engine
├── security/        # Security validation
├── tools/           # MCP tool implementations
├── transports/      # Transport protocols
├── types/           # TypeScript type definitions
└── index.ts         # Main entry point

Development Commands

npm run build        # Build project
npm run watch        # Watch mode build
npm run dev:stdio    # Development - stdio
npm run dev:http     # Development - HTTP

Markdown Documentation

Complete Markdown Guide - Comprehensive Markdown syntax tutorial for efficient md to text conversion

Online Tools

MD to Text Converter - Free online Markdown to text conversion tool with real-time processing

License

MIT License

Available Tools

4 tools

batch_convertA

Batch convert markdown files in a directory

ParametersJSON Schema

Name	Required	Description
`options`	No
`pattern`	No	File name pattern (default: *.md)
`directory`	Yes	Directory path
`recursive`	No	Whether to recursively process subdirectories

TDQS

A3.6/5.0

Behavior2/5

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

No annotations are provided, so the description carries the full burden. It only states the action without disclosing whether files are modified in place, what output is returned, or any side effects. This is a significant gap for a conversion tool.

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 a single sentence, front-loaded with the core action and scope, with no wasted words. It is perfectly concise for the information it conveys.

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?

With no annotations or output schema, the description leaves critical context unexplained, such as the output format, whether files are overwritten, and how options affect conversion. Given the tool's complexity (nested options, recursive flag), this is insufficient for an agent to invoke it confidently.

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 schema provides descriptions for most parameters (75% coverage), including directory, pattern, recursive, and nested option properties. The description adds no parameter details, but the schema already covers the essentials, so the baseline 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 'Batch convert markdown files in a directory' clearly uses a specific verb and resource, and the 'batch' and 'directory' modifiers distinguish it from sibling tools like convert_text, convert_file, and convert_url. It unambiguously states what the tool does.

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 phrase 'in a directory' implies this tool is for directory-level batch conversion, providing clear context for when to use it over single-file or URL tools. However, it does not explicitly mention alternatives or when not to use it, stopping short of a full 5.

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

convert_fileB

Convert local markdown file to plain text

ParametersJSON Schema

Name	Required	Description	Default
`path`	Yes	Local file path
`options`	No

TDQS

B3.4/5.0

Behavior2/5

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

With no annotations provided, the description must disclose behavioral traits. It states the conversion direction but does not mention whether it is read-only, how it handles edge cases (e.g., unsupported Markdown elements), or what the return format is. This is minimal for a tool with zero 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 one sentence, front-loaded with the verb, and zero wasted words. It is immediately clear and concise.

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?

Given moderate complexity (nested options), no annotations, and no output schema, the description is minimal but covers the core purpose. However, it lacks context about return values, error behavior, and option implications, though those are partially discoverable from the schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 50% (path is described, options is not). The description adds no parameter semantics or context about the options object. While the schema's individual property descriptions exist, the description fails to compensate for the missing top-level parameter explanation.

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 a specific verb ('Convert') with a specific resource ('local markdown file') and output ('plain text'). It distinguishes from sibling tools by explicitly targeting local files, unlike convert_text or convert_url.

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 use for local markdown file conversion but does not explicitly mention when not to use it or name alternative tools. Sibling tools are listed in context, but the description itself provides no exclusions or alternatives, leaving the agent to infer based on the tool name.

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

convert_textB

Convert markdown text to plain text

ParametersJSON Schema

Name	Required	Description	Default
`options`	No
`markdown`	Yes	Markdown text to convert

TDQS

B3.2/5.0

Behavior2/5

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

No annotations are present, so the description carries the full burden of behavioral disclosure. It simply states the conversion without detailing how formatting, links, code blocks, or options are handled. Only a minimal behavioral statement is given.

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 a single, front-loaded sentence with no unnecessary words or repetition. It is directly informative and earns its place.

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?

The tool has a nested options object and no output schema, indicating some complexity. The description covers only the core function and omits behavioral context, such as how options affect the output or potential limitations. It is too sparse for full contextual completeness.

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 describes the 'markdown' parameter and the sub-properties of 'options'. The description adds no additional parameter meaning. With 50% schema coverage (the top-level 'options' object lacks a description), the description does not compensate, but the schema provides adequate baseline information.

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 (convert), the input (markdown text), and the output (plain text). It distinguishes from sibling tools like convert_file and convert_url by specifying the input type as text rather than file or URL.

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 is provided on when to use this tool versus alternatives. It does not mention sibling tools, prerequisites, or exclusions, so the agent must infer usage from the name and minimal description.

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

convert_urlB

Fetch remote URL markdown content and convert to plain text

ParametersJSON Schema

Name	Required	Description	Default
`url`	Yes	Remote markdown file URL
`options`	No

TDQS

B3.3/5.0

Behavior2/5

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

With no annotations provided, the description carries the full burden. It only states the basic operation and omits behavioral details such as network request implications, failure modes, or output format. The read-only nature is implied but not explicit.

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 a single sentence with no redundant wording, efficiently conveying the core purpose. However, it is under-specified in other dimensions.

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?

The tool has a nested options object and sibling tools, yet the description doesn't address the conversion options, output expectations, or differentiation from siblings. This minimal description is insufficient for an agent to select and use the tool correctly in all contexts.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is at 50%, and the description does not explain how the options parameter affects conversion. It only restates the url concept without adding meaning beyond the schema's own field descriptions.

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: 'Fetch remote URL markdown content and convert to plain text', using a specific verb and resource. It distinguishes from sibling tools like convert_text and convert_file by emphasizing the remote URL source.

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 remote markdown URLs but provides no explicit guidance on when to prefer this over convert_text or convert_file. No alternatives or exclusion criteria are mentioned.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

4 tool updatesv1.0.0Aug 2, 2026
- First observedbatch_convert
- First observedconvert_file
- First observedconvert_text
- First observedconvert_url

Deploy Server

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

TDQS

A3.7/5.0

Scored 2026-08-02 14:25 across 4 tools

Disambiguation5/5

Each tool targets a distinct input source: raw text, local file, URL, and directory batch. No overlap in purpose or behavior.

Naming Consistency4/5

Three tools follow the convert_<source> pattern (convert_text, convert_file, convert_url), but batch_convert inverts the pattern. This is a minor deviation that doesn't hinder understanding.

Tool Count5/5

Four tools cover the core input types for a markdown-to-text conversion server. Each tool has a clear and necessary role, and the count is well-scoped.

Completeness4/5

The tool surface covers all common input methods (text, file, URL, batch) with no obvious gaps for the stated purpose. Minor options like specifying output format are absent but not critical.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

Mdkit A
online.mdkit
Document-to-Markdown MCP server — convert PDF, Office and HTML into LLM-ready Markdown.
Developer Tools RAG Systems Data Platforms
31
PDF to Markdown (pdf2md.dev)
dev.pdf2md
Hosted MCP server: convert PDFs to clean, LLM-ready Markdown with tables, formulas and OCR.
AI & Machine Learning Image & Video Processing
2
hithereiamaliff-mcp-nextcloudOAuth
ai.smithery
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
Cloud Storage File Systems Workplace & Productivity
237
mcp COAuth
com.wix
A Model Context Protocol server for Wix AI tools
Developer Tools Content Management Systems App Automation
216

Related MCP Servers

MCP Docling Server
Documentation Access Text Summarization
zanetworker
A
license
Not graded
quality
D
maintenance
A server that provides document processing capabilities using the Model Context Protocol, allowing conversion of documents to markdown, extraction of tables, and processing of document images.
Updated a year ago (2025-04-05 11:57 UTC)
19
MIT
markdown-to-html
Developer Tools Autonomous Agents
fashionzzZ
A
license
B
quality
D
maintenance
A Model Context Protocol server that converts Markdown content to HTML format.
Updated a year ago (2025-06-03 09:34 UTC)
1
2,040
2
MIT
Markmap MCP Server
Developer Tools Content Management Systems
jinzcdev
A
license
A
quality
A
maintenance
A Model Context Protocol server that converts Markdown text to interactive mind maps with support for rich interactive operations and multi-format exports.
Updated a month ago (2026-08-04 10:36 UTC)
1
695
283
MIT
MCP Fetch
Browser Automation Web Scraping Search
LangGPT
A
license
B
quality
D
maintenance
A Model Context Protocol server that allows LLMs to retrieve and convert web content to markdown without robots.txt restrictions.
Updated 9 months ago (2025-12-28 06:30 UTC)
1
2
MIT

Markdown to Text MCP Server

Features

Quick Start

Installation

Option 1: Clone and Build

Option 2: Use with npx (Recommended)

Basic Usage

Using with npx

Quick Test

From Local Package

Integration with Claude Desktop via npx

Tools

convert_text - Text Conversion

convert_file - File Conversion

convert_url - URL Conversion

batch_convert - Batch Conversion

Conversion Options

Claude Desktop Integration

Command Line Options

Environment Variables

Docker Support

API Examples

Text Conversion

File Conversion

URL Conversion

Batch Conversion

Security

Development

Project Structure

Development Commands

Related Resources

Markdown Documentation

Online Tools

License

Available Tools

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers