de en es ja ko ru zh

mdmagic-mcp-server

Name: mdmagic-mcp-server
Author: MDMagic-MCP

by MDMagic-MCP

Overview Schema Related Servers Score Discussions

TypeScript

Hybrid

MDMagic MCP Server

Преобразуйте Markdown в DOCX, PDF и HTML, используя собственные шаблоны Word — с вашими фирменными бланками, брендингом и шрифтами. Плюс 15 дизайнерских шаблонов на случай, если у вас нет своих.

npm version MCP Registry Smithery license

MDMagic подключается напрямую к Claude, Cursor, VS Code и любому другому ИИ-ассистенту с поддержкой MCP, предоставляя им прямой доступ к профессиональному конвейеру преобразования документов (Pandoc + Microsoft Graph + Mammoth.js) и, что более важно, к вашим шаблонам. Загрузите свои фирменные бланки, шаблоны договоров, коммерческих предложений или руководства по бренду — всё, что вы уже используете в Microsoft Word, — и ваш ИИ-ассистент сможет конвертировать любой Markdown напрямую в отполированный документ с вашим логотипом, шрифтами, цветами, колонтитулами, нумерацией страниц, водяными знаками и блоками подписей. Результат выглядит так, будто его подготовила ваша команда дизайнеров, а не просто сгенерировал ИИ.

You: "Take this report and turn it into an Executive_Platinum PDF."

Claude: ✅ Done. Here's your secure download link.
        14-page PDF, 2.3 MB, expires in 60 minutes.

Установка

Вам потребуется учетная запись MDMagic (доступен бесплатный тариф) и API-ключ с вашей страницы учетной записи.

Claude Desktop

Добавьте это в ваш claude_desktop_config.json:

{
  "mcpServers": {
    "mdmagic": {
      "command": "npx",
      "args": ["-y", "@mdmagic/mcp-server"],
      "env": {
        "MDMAGIC_API_KEY": "mdmagic-xxxxxxxxxxxxxxxx"
      }
    }
  }
}

Расположение файла конфигурации:

macOS — ~/Library/Application Support/Claude/claude_desktop_config.json
Windows — %APPDATA%\Claude\claude_desktop_config.json
Linux — ~/.config/Claude/claude_desktop_config.json

Перезапустите Claude Desktop. Инструменты MDMagic появятся в списке инструментов.

Cursor

Добавьте в ~/.cursor/mcp.json (или через Settings → MCP):

{
  "mcpServers": {
    "mdmagic": {
      "command": "npx",
      "args": ["-y", "@mdmagic/mcp-server"],
      "env": {
        "MDMAGIC_API_KEY": "mdmagic-xxxxxxxxxxxxxxxx"
      }
    }
  }
}

VS Code (с расширением MCP)

{
  "mcp.servers": {
    "mdmagic": {
      "command": "npx",
      "args": ["-y", "@mdmagic/mcp-server"],
      "env": {
        "MDMAGIC_API_KEY": "mdmagic-xxxxxxxxxxxxxxxx"
      }
    }
  }
}

Хостинг (без установки)

Не хотите устанавливать Node на компьютер? Используйте хостинг-эндпоинт:

{
  "mcpServers": {
    "mdmagic": {
      "url": "https://api.mdmagic.ai/mcp",
      "headers": {
        "x-api-key": "mdmagic-xxxxxxxxxxxxxxxx"
      }
    }
  }
}

Те же инструменты, те же шаблоны, работающие через Streamable HTTP. Полезно для клиентов, которые не запускают локальные процессы.

Related MCP server: AI Group Markdown to Word MCP Server

Что вы можете делать

После подключения попросите своего ИИ-ассистента сделать следующее:

"Преобразуй этот markdown в PDF, используя шаблон Executive_Platinum."
"Какие шаблоны мне доступны?"
"Сколько кредитов будет стоить рендеринг этого отчета на 800 слов в формате DOCX + PDF?"
"Отрендери это в альбомной ориентации, на бумаге формата US Letter, с шаблоном Legal_Burgundy."
"Проверь мой баланс кредитов."

ИИ выберет нужный инструмент и вернет безопасную ссылку для скачивания с ограниченным сроком действия.

Инструменты

Инструмент	Что он делает
`convert_document`	Преобразование Markdown → DOCX / PDF / HTML / все три. Возвращает безопасную ссылку с истекающим сроком действия.
`validate_markdown`	Предварительная проверка перед конвертацией. Находит некорректные таблицы, незакрытые блоки кода и другие синтаксические ошибки, которые могут привести к некорректному выводу.
`estimate_conversion_cost`	Предварительная оценка стоимости на основе количества слов, страниц, формата и типа шаблона.
`check_credit_balance`	Текущий баланс кредитов (подписка + купленные пакеты), статус плана.
`list_all_templates`	Полный каталог шаблонов: 15 встроенных шаблонов (сгруппированных по категориям) + ваши пользовательские загрузки.
`list_builtin_templates`	Только встроенные шаблоны: Бизнес (5), Творческие (6), Профессиональные (2), Технические (2).
`list_custom_templates`	Только ваши загруженные пользовательские шаблоны.
`get_template_details`	Показать доступные варианты (размеры страниц × ориентации) для конкретного шаблона.
`recommend_template`	Рекомендовать лучший встроенный шаблон для описанной цели ("отчет для совета директоров за 4 квартал" → Executive_Platinum).
`show_default_settings`	Ваши настройки по умолчанию: размер страницы, ориентация и предпочтения шаблонов.

`convert_document` — параметры ввода

Три способа предоставить исходный код:

content — необработанная строка markdown (наиболее часто используется)
filePath — абсолютный путь к файлу .md (отлично подходит для рабочих процессов в IDE)
fileContent — markdown в кодировке base64 (для безопасной передачи бинарных данных)

Плюс:

templateName — например, Executive_Platinum, Legal_Burgundy или UUID пользовательского шаблона
outputFormat — docx, pdf, html, all или all-formats
pageSize — A4, A3, US_Letter, US_Legal, Executive
orientation — Portrait или Landscape

Конфигурация

Переменная	По умолчанию	Примечания
`MDMAGIC_API_KEY`	(обязательно)	Ваш личный API-ключ с mdmagic.ai/account
`MDMAGIC_BASE_URL`	`https://api.mdmagic.ai`	Переопределяйте только для локальной разработки или тестирования
`REQUEST_TIMEOUT`	`30000`	Тайм-аут запроса в мс
`MCP_TRANSPORT`	`stdio`	`stdio` (по умолчанию) или `http` для самохостинга Streamable HTTP
`MCP_HTTP_PORT`	`3001`	Порт для режима HTTP-транспорта
`MCP_HTTP_HOST`	`127.0.0.1`	Адрес привязки для режима HTTP-транспорта

Большинству пользователей нужно будет установить только MDMAGIC_API_KEY.

Ценообразование

Конвертации стоят кредитов, рассчитываемых на основе количества страниц и формата вывода:

DOCX: 1 кредит за страницу (база)
PDF: +1 кредит за страницу
HTML: +1 кредит за страницу
Пользовательские шаблоны: +1 кредит за страницу

Отчет на 5 страниц, преобразованный в DOCX + PDF + HTML с использованием пользовательского шаблона = 5 × (1 + 1 + 1 + 1) = 20 кредитов.

Инструмент estimate_conversion_cost возвращает точные цифры до того, как вы что-либо потратите. MCP также отказывается работать, если ваш баланс слишком низкий — никаких неожиданных счетов.

Кредиты бесплатного тарифа обновляются ежемесячно. Платные планы и пополнение кредитов доступны на mdmagic.ai.

Конфиденциальность

Никакого постоянного хранения. Документы проходят через Microsoft Graph API для рендеринга PDF и удаляются в течение 5–10 секунд. Выходные файлы удаляются с серверов MDMagic после скачивания или через 60 минут, в зависимости от того, что наступит раньше.
Случайные имена файлов. Исходные файлы используют UUID, никогда не используются имена, идентифицирующие пользователя.
Безопасные URL для скачивания. Каждая конвертация возвращает одноразовый URL с ID сессии и токеном скачивания. Никаких публичных директорий с файлами.
Изоляция API-ключей. Каждый пользователь аутентифицируется своим собственным ключом. Никаких общих учетных данных.

Устранение неполадок

MDMAGIC_API_KEY environment variable is required Установите переменную окружения в конфигурации вашего клиента (блок env в JSON). Не помещайте ее в оболочку (shell) — npx ее не увидит.

Invalid API key format Ключи должны соответствовать формату mdmagic-, за которым следуют ровно 16 цифр. Скопируйте его аккуратно со страницы вашей учетной записи.

Failed to connect to MDMagic API Проверьте https://api.mdmagic.ai/health в браузере. Если он работает, проблема в локальной сети или брандмауэре. Убедитесь, что MDMAGIC_BASE_URL (по умолчанию https://api.mdmagic.ai) доступен с машины, на которой запущен MCP.

Инструменты не появляются в Claude Desktop Полностью завершите работу и перезапустите Claude Desktop после редактирования claude_desktop_config.json — простого закрытия окна недостаточно.

Insufficient credits Используйте check_credit_balance для подтверждения баланса, estimate_conversion_cost для предварительного просмотра затрат или пополните счет на mdmagic.ai/account.

Локальная разработка

git clone https://github.com/MDMagic-MCP/mdmagic-mcp-server.git
cd mdmagic-mcp-server
npm install

# Set your API key (use http://localhost:3000 if running the API locally)
cp .env.example .env
# edit .env

# Build and inspect
npm run build
npm run inspector

Инспектор MCP (npm run inspector) запускает веб-интерфейс для проверки сервера инструмент за инструментом — полезно при добавлении новых инструментов или отладке проверки аргументов.

Запускайте тесты с помощью npm test.

Ссылки

MDMagic — mdmagic.ai
Получить API-ключ — mdmagic.ai/account
Проблемы — github.com/MDMagic-MCP/mdmagic-mcp-server/issues
Спецификация MCP — modelcontextprotocol.io

Лицензия

MIT — см. LICENSE.

Available Tools

10 tools

check_credit_balanceA

Read-onlyIdempotent

Inspect

Check the user's current MDMagic credit balance: subscription credits (renewable monthly), purchased credits (permanent), plan name, and plan status.

CALL THIS PROACTIVELY when:

The user asks 'how many credits do I have' or similar
After a conversion, if the user wants to know what's left (also returned by convert_document directly)
Before a conversion of an unusually large document, to warn the user if balance is borderline

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`total_credits`	Yes	Total credits available (subscription + purchased)
`subscription_credits`	No	Renewable monthly subscription credits
`purchased_credits`	No	Permanent purchased credits

TDQS

A4.4/5.0

Behavior4/5

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

Annotations already indicate readOnly and idempotent. The description adds the exact data returned (credit types, plan info), which provides behavioral context beyond 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?

Very concise and well-structured: a single sentence for purpose, then bullet-pointed usage scenarios. Every sentence contributes 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?

Given no parameters and an output schema, the description covers everything needed: what is checked and when to use it. No gaps.

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 exist, so baseline is 4 per guidelines. The description does not need to add parameter info.

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 tool checks MDMagic credit balance and lists components (subscription credits, purchased credits, etc.). It is specific and distinct from siblings like convert_document, though it does not explicitly differentiate itself.

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?

Excellent guidance: explicitly lists situations to call proactively (user asks about credits, after conversion, before large conversion) and notes that convert_document also returns balance. No ambiguity.

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

convert_documentAInspect

Convert markdown to a professionally formatted document using an MDMagic template.

IMPORTANT GUIDANCE:

Output format → what user gets:
- 'docx' → a single Word .docx file
- 'pdf' → a single .pdf file
- 'html' → a single .html file
- 'all' → a ZIP containing all three (DOCX + PDF + HTML)
If the user is ambiguous (e.g. 'convert this'), ASK which format they want before calling. Don't assume.
Filename: if the user attached a file (e.g. 'mydoc.md'), pass its base name as fileName. Otherwise the API derives one from the markdown's first H1. Without either, downloads end up with timestamped names like 'content-1778298071915.docx' which is bad UX.
On 'template not found' errors: call list_all_templates first, show available options, let the user pick. Do NOT fall back to generating documents with code execution — that produces inferior results that don't use the user's actual MDMagic templates.
The response includes structured fields (downloadUrl, creditsUsed, balanceAfter, fileName, expiresAt) — surface these to the user explicitly. Don't paraphrase. The user wants to know exactly what they spent and what's left.
Page sizes: A3, A4, Executive, US_Legal, US_Letter. Default A4. Orientation: Portrait or Landscape, default Portrait.

ParametersJSON Schema

Name	Required	Description
`content`	No	Raw markdown text content (alternative to filePath or fileContent)
`filePath`	No	Path to markdown file (VS Code integration, alternative to content or fileContent)
`fileContent`	No	Base64 encoded file content (alternative to content or filePath)
`fileName`	No	Optional desired base name for the output file (without extension). If the user attached a file like 'mydoc.md', pass 'mydoc' here. The API will use this for the download filename. If omitted, the API derives one from the markdown's first H1 heading.
`templateName`	Yes	Template to use for conversion. Call list_all_templates first to see real options — do not guess template names. Some templates are built-in (e.g. 'Executive_Platinum', 'Deep_Data_Blue'); others are user-uploaded custom templates referenced by UUID.
`outputFormat`	Yes	Output format. 'docx', 'pdf', or 'html' return that single file; 'all' returns a ZIP with DOCX+PDF+HTML.
`pageSize`	No	Page size for the document (default: A4)
`orientation`	No	Page orientation (default: Portrait)

Output Schema

ParametersJSON Schema

Name	Required	Description
`success`	Yes	Whether the conversion succeeded
`downloadUrl`	Yes	Secure expiring download URL (valid for 60 minutes)
`fileName`	Yes	Filename of the downloadable document
`creditsUsed`	No	Credits debited for this conversion
`balanceAfter`	No	Remaining credit balance after this conversion
`expiresAt`	No	ISO 8601 timestamp when the download URL expires
`message`	No	Human-readable status message

TDQS

A4.9/5.0

Behavior5/5

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

Annotations only state readOnlyHint=false, destructiveHint=false, idempotentHint=false, openWorldHint=true. The description adds significant behavioral context: output format behavior, filename derivation logic, error handling procedure, response fields to surface, and default page settings. This goes well beyond what annotations provide.

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 structured with numbered points and clear headings, making it easy to parse. It is front-loaded with the core purpose. While it is relatively long (6 points of guidance), each point is necessary for correct usage, so the length is justified and no information is redundant.

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 complexity (8 parameters, 2 required, multiple output formats, error handling, response fields), the description covers all crucial aspects: input sources, output options, error recovery, response structure, page settings, and defaults. No important aspect is omitted. The description compensates for the missing output schema details by specifying the fields to surface.

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

Parameters5/5

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

The input schema has 100% description coverage, yet the description adds richer context: it explains importance of passing fileName for UX, warns not to guess templateName but to call list_all_templates, clarifies outputFormat values, and documents defaults for pageSize and orientation. This adds meaning 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 starts with a clear, specific verb 'Convert markdown to a professionally formatted document using an MDMagic template', which precisely states the action and resource. It distinguishes itself from sibling tools (like list_all_templates or check_credit_balance) by being the only conversion tool.

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 provides explicit when-to-use and when-not-to-use guidance, e.g., asking users for format if ambiguous, not falling back to code generation on template missing, and instead calling list_all_templates. It includes concrete actions like 'if the user is ambiguous... ASK' and 'on template not found errors: call list_all_templates first'.

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

estimate_conversion_costA

Read-onlyIdempotent

Inspect

Estimate credit cost for a conversion BEFORE running it. Returns word count, page calculation (300 words/page), and a credit breakdown by format and template type. Use this when the user asks 'how much will this cost?' or when you suspect a conversion might exceed their balance — convert_document refuses to run if credits are insufficient, so estimating first is friendlier.

ParametersJSON Schema

Name	Required	Description
`content`	Yes	Markdown content to estimate credit cost for
`templateName`	Yes	Template ID or name (UUID for custom templates, name for system templates)
`outputFormat`	Yes	Output format(s): docx (DOCX only), pdf (DOCX+PDF), html (DOCX+HTML), all/all-formats (DOCX+PDF+HTML)
`pageSize`	No	Page size for the document
`orientation`	No	Page orientation

Output Schema

ParametersJSON Schema

Name	Required	Description
`wordCount`	No	Word count of the markdown content
`pageCount`	No	Estimated page count (300 words/page)
`totalCredits`	Yes	Total credits required for this conversion
`breakdown`	No	Human-readable breakdown of how credits are calculated

TDQS

A4.9/5.0

Behavior5/5

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

Annotations already declare readOnly=true, destructive=false, idempotent=true. Description adds context that convert_document refuses if insufficient credits, explaining the behavioral context of the estimate. 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?

Three sentences, each valuable: first states purpose, second lists return values, third gives when-to-use guidance. No 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 5 parameters with full schema descriptions and an output schema (present), the description effectively covers usage context, behavioral traits, and relationship to sibling tool convert_document. Complete for an estimation tool.

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?

Schema has 100% coverage with descriptions for all 5 parameters. The description adds value by explaining that the estimate includes credit breakdown by format and template type, and mentions the 300 words/page calculation, which provides additional insight into how parameters affect the result.

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 estimates credit cost before conversion, specifies return values (word count, page calculation, credit breakdown), and distinguishes itself from convert_document by mentioning it is friendly to use before running the actual conversion.

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?

Explicitly tells when to use: when user asks 'how much will this cost?' or when suspecting insufficient balance. Also contrasts with convert_document that refuses if credits are insufficient, making the estimation alternative clear.

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

get_template_detailsA

Read-onlyIdempotent

Inspect

Show available variants (page sizes and orientations) for a specific template. All MDMagic templates support the full 5×2 matrix: A3, A4, Executive, US_Legal, US_Letter × Portrait/Landscape. Use this when the user asks 'does this template come in Legal Landscape?' or 'what sizes are available?' — confirms the variant before convert_document runs.

ParametersJSON Schema

Name	Required	Description	Default
`templateName`	Yes	Template ID or name (e.g. Executive_Platinum, or a UUID for custom templates)

Output Schema

ParametersJSON Schema

Name	Required	Description
`template`	Yes
`pageSizes`	Yes	Supported page sizes
`orientations`	Yes	Supported orientations

TDQS

A4.2/5.0

Behavior4/5

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

Annotations already declare readOnlyHint, destructiveHint, idempotentHint, openWorldHint. Description adds: all templates support a 5x2 matrix, and it serves as a pre-check for convert_document. This enriches behavioral context 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?

Two sentences, front-loaded with purpose, followed by usage examples. Every sentence is informative and necessary. No wasted words.

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?

Covers purpose, usage, and output context (matrix of sizes). With an output schema present, return details are not needed. Slight gap: no mention of error handling for invalid templates, but overall sufficient for a simple tool.

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% with a clear description of templateName. Description doesn't add new parameter details (e.g., format specifics) beyond schema, which is adequate. Baseline 3 applies as schema already covers the parameter.

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 'Show available variants (page sizes and orientations) for a specific template', specifying verb and resource. It distinguishes from siblings like list_all_templates and explicitly ties to convert_document, making purpose unambiguous.

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?

Provides explicit example queries ('does this template come in Legal Landscape?') and advises using before convert_document. While it lacks explicit alternatives or when-not-to-use, the context is clear and actionable.

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

list_all_templatesA

Read-onlyIdempotent

Inspect

List all 15 built-in MDMagic templates plus any custom templates the user has uploaded.

CALL THIS PROACTIVELY when:

The user mentions a template by name (verify it exists before convert_document)
The user asks 'what templates are available' or similar
A previous convert_document call returned 'template not found'
The user describes the look they want without naming a template (so you can suggest a real one)

Returns: name, description, type (built-in vs custom), and category. Categories are: Business (5 templates), Creative (6), Professional (2), Technical (2). Use the optional category filter to narrow recommendations (e.g. 'for legal documents' → category: 'Professional').

ParametersJSON Schema

Name	Required	Description	Default
`includeDetails`	No	Include template details like available page sizes and orientations (default: false)
`category`	No	Optional filter — return only built-in templates in this category. Custom templates are always included regardless. Categories: Business (executive/financial), Creative (designer/artistic/novelty), Professional (legal), Technical (code/data documentation).

Output Schema

ParametersJSON Schema

Name	Required	Description
`builtinCount`	No	Number of built-in templates returned
`customCount`	No	Number of custom templates returned
`templates`	Yes	All matching templates

TDQS

A4.5/5.0

Behavior4/5

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

Adds value beyond annotations by describing return fields (name, description, type, category) and category counts, plus noting custom templates always included regardless of filter.

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?

Front-loaded with main purpose, uses bullet points for usage scenarios, but could be slightly more concise without losing clarity.

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?

Sufficiently covers what the tool returns and usage patterns, though output schema is not fully utilized for additional structure.

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?

Schema has 100% coverage but description reinforces usage of category filter for narrowing recommendations and adds context about custom templates.

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 specifies it lists 15 built-in MDMagic templates plus custom templates, distinguishing it from siblings like list_builtin_templates and list_custom_templates.

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 when-to-call scenarios: verify template existence, answer 'what templates', handle 'template not found' errors, and suggest templates when user describes look without naming one.

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

list_builtin_templatesA

Read-onlyIdempotent

Inspect

List the 15 built-in MDMagic templates, grouped by category. Same as list_all_templates but excludes the user's custom uploads. Use this when the user asks specifically about MDMagic's bundled templates rather than their personal ones.

Categories available: Business (5), Creative (6), Professional (2), Technical (2).

ParametersJSON Schema

Name	Required	Description	Default
`includeDetails`	No	Include template details like available page sizes and orientations (default: false)
`category`	No	Optional filter — return only templates in this category.

Output Schema

ParametersJSON Schema

Name	Required	Description
`count`	No	Number of templates returned
`templates`	Yes	Matching built-in templates

TDQS

A4.5/5.0

Behavior3/5

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

Annotations already provide readOnlyHint, destructiveHint, idempotentHint, openWorldHint. Description adds category grouping and count details but no additional behavioral caveats.

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 concise sentences with front-loaded purpose and clear structure.

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?

Simple read-only tool with output schema present; description fully covers purpose, usage, and parameter 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?

Schema coverage 100%, description mentions categories and optional filter, adding grouping and count context 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?

Clearly states it lists the 15 built-in MDMagic templates grouped by category, and distinguishes from list_all_templates and list_custom_templates by excluding custom uploads.

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?

Explicitly says to use this when the user asks about bundled templates rather than personal ones, differentiating from sibling tools.

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

list_custom_templatesA

Read-onlyIdempotent

Inspect

List only the user's custom-uploaded Word templates. Use this when the user asks about their own templates ('show me my templates', 'do I have a letterhead?'). Custom templates are referenced by UUID, not name, when calling convert_document.

ParametersJSON Schema

Name	Required	Description	Default
`includeDetails`	No	Include template details like available page sizes and orientations (default: false)

Output Schema

ParametersJSON Schema

Name	Required	Description
`count`	No	Number of custom templates returned
`templates`	Yes	User's custom templates

TDQS

A4.3/5.0

Behavior4/5

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

Annotations already indicate readOnlyHint and idempotentHint; description adds behavioral context that it only lists custom templates and that templates are referenced by UUID. No contradictions 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.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences, front-loaded with purpose, and includes essential usage guidance without any unnecessary 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?

Given the simple tool (1 optional parameter, output schema exists, annotations cover safety), the description is complete: it specifies the scope (custom only), links to a related tool, and the schema and annotations provide full parameter and behavioral details.

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 one parameter (includeDetails) with full description coverage (100%). The tool description does not add extra meaning to this parameter, so baseline score of 3 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?

The description clearly states the verb 'List' and the specific resource 'user's custom-uploaded Word templates'. It distinguishes itself from sibling tools like list_all_templates and list_builtin_templates by focusing on custom templates and mentioning UUID referencing.

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?

Description explicitly provides scenarios for use ('when the user asks about their own templates') and gives guidance on using templates with convert_document via UUID. It does not list when not to use, but the context is clear enough for decision-making.

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

recommend_templateA

Read-onlyIdempotent

Inspect

Suggest the best built-in template(s) for a described purpose. Use this when the user describes WHAT the document is (e.g. 'Q4 board pack', 'API reference', 'wedding invitation', 'legal contract') without naming a template. Returns ranked recommendations with rationale.

Why this exists: AI assistants often guess template names that don't exist. This tool maps purpose → real template names from MDMagic's catalog, so convert_document doesn't fail with 'template not found'.

ParametersJSON Schema

Name	Required	Description	Default
`purpose`	Yes	Free-text description of the document's purpose. Examples: 'Q4 board pack for investors', 'restaurant menu', 'developer API documentation', 'wedding invitation'.
`topN`	No	How many recommendations to return (1-5, default 3)

Output Schema

ParametersJSON Schema

Name	Required	Description
`purpose`	No	Echoes back the purpose that was matched
`rationale`	No	Why these templates were picked
`recommendations`	Yes	Ranked list of template IDs to pass to convert_document

TDQS

A4.5/5.0

Behavior4/5

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

Annotations already declare the tool as read-only and idempotent. The description adds value by stating that it 'returns ranked recommendations with rationale', which is behavioral context not covered by annotations. 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?

The description is concise and front-loaded, with the first sentence stating the core action. Two paragraphs: one for usage and one for rationale. Every sentence adds value without redundancy.

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 description is complete for a two-parameter tool with existing output schema. It explains the input, output (ranked recommendations with rationale), and the problem it solves, linking to the sibling tool convert_document.

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 detailed descriptions for both parameters (purpose and topN). The tool description does not add further explanation beyond the schema, so baseline score of 3 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?

The description clearly states the tool's purpose: 'Suggest the best built-in template(s) for a described purpose.' It uses the specific verb 'suggest' and resource 'built-in templates', and explicitly distinguishes from sibling tools like list_all_templates by noting that this tool maps purpose to real template names to avoid conversion failures.

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 states when to use this tool: 'when the user describes WHAT the document is (e.g. ...) without naming a template.' It also explains why it exists (to prevent AI assistants from guessing non-existent templates) and implicitly indicates not to use when a template name is already known.

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

show_default_settingsA

Read-onlyIdempotent

Inspect

Show the user's default paper size and orientation preferences (set on their account page). Useful when the user hasn't specified pageSize/orientation explicitly — call this to honor their defaults instead of using A4/Portrait blindly.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`default_page_size`	Yes	User's preferred page size
`default_orientation`	Yes	User's preferred page orientation

TDQS

A4.7/5.0

Behavior4/5

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

Annotations already provide readOnlyHint, destructiveHint, idempotentHint, and openWorldHint. The description adds context about reading account page preferences, which aligns with annotations and gives slightly more insight into the data source.

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 only two sentences, front-loading the purpose and immediately following with usage guidance. Every word adds value with no redundancy.

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 has no parameters and has an output schema, the description sufficiently covers purpose and usage. No additional details are necessary for correct invocation.

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 exist, and schema coverage is 100%. The description does not need to elaborate on parameters; baseline score of 4 for zero-parameter tools 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 shows default paper size and orientation preferences from the user's account page, using specific verb 'show' and resource 'defaults'. It distinguishes from sibling tools by focusing on a specific setting retrieval.

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 advises when to use this tool (when user hasn't specified pageSize/orientation) and contrasts with a default behavior (A4/Portrait), providing clear context for appropriate invocation.

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

validate_markdownA

Read-onlyIdempotent

Inspect

Pre-flight markdown validation BEFORE conversion. Catches malformed tables (mismatched pipes), unclosed code fences, broken task lists, and unsupported syntax. Returns a green/amber/red status plus the detected markdown features.

CALL THIS PROACTIVELY when:

The user is about to convert a long document (>5 pages) — validating first is cheap; running a doomed conversion costs credits
The user reports a previous conversion produced broken output
You generated the markdown yourself and want to verify it's clean before spending credits

Returns: status (green=safe, amber=minor issues, red=will likely break), detected features (tables, code blocks, task lists, math), and a human-readable message.

ParametersJSON Schema

Name	Required	Description	Default
`content`	Yes	Markdown content to validate
`filename`	No	Optional filename label for the response (defaults to 'content.md')

Output Schema

ParametersJSON Schema

Name	Required	Description
`filename`	No	Filename label echoed back
`status`	Yes	Validation verdict
`message`	Yes	Human-readable explanation of any issues
`inputFormat`	No	Detected markdown flavour (e.g. gfm, commonmark)
`additionalPandocFlags`	No	Pandoc flags that will be applied
`detectedFeatures`	No	Map of markdown features found in the content

TDQS

A4.6/5.0

Behavior5/5

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

Beyond annotations (readOnly, idempotent), the description reveals that validation is cheap, returns a green/amber/red status plus detected features, and helps avoid costly conversion failures. No contradictions 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.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with a clear opening, bulleted usage guidelines, and a return summary. It is appropriately sized but could be slightly more concise without losing 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?

For a simple validation tool with full schema coverage and an output schema, the description covers purpose, when to use, what it detects, and what it returns. No missing critical 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 coverage is 100%, so the description adds minimal extra meaning to parameters. It does not elaborate on the content or filename beyond what the schema already specifies, but the return value description compensates slightly.

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 'Pre-flight markdown validation BEFORE conversion' and lists specific issues caught (malformed tables, unclosed code fences, etc.). It distinguishes itself from sibling tools like convert_document, which performs the actual conversion.

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 provides three scenarios when to call the tool proactively: before converting a long document, after broken output, and when verifying self-generated markdown. It contrasts with the cost of a failed conversion, offering clear guidance.

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. Dates show when Glama detected each change.

10 tool updatesv0.1.0May 9, 2026
- First observedcheck_credit_balance
- First observedconvert_document
- First observedestimate_conversion_cost
- First observedget_template_details
- First observedlist_all_templates
- First observedlist_builtin_templates
- First observedlist_custom_templates
- First observedrecommend_template
- First observedshow_default_settings
- First observedvalidate_markdown

Install Server

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

TDQS

A4.6/5.0

Disambiguation5/5

Each tool has a distinct and non-overlapping purpose—balance checking, conversion, cost estimation, template listing/details, recommendations, defaults, and validation. No two tools could be confused.

Naming Consistency5/5

All tools use a consistent verb_noun snake_case pattern (e.g., list_all_templates, validate_markdown), making the set predictable and easy to navigate.

Tool Count5/5

With 10 tools, the count is well-scoped for a document conversion service. Each tool addresses a necessary step in the user workflow without unnecessary bloat.

Completeness5/5

The tool surface covers the full lifecycle: template discovery, defaults retrieval, markdown validation, cost estimation, credit checking, conversion, and post-conversion feedback. No obvious gaps for the stated purpose.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

Need Help?

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

netcafe-docflow A
com.ainetcafe
Markdown in, any format out. PDFs merged, split, watermarked. Runs on our own doc engines.
Developer Tools Documentation Access
1311
UnmarkdownOAuth
io.github.UnMarkdown
The document publishing layer for AI tools. Convert markdown to 6 destinations, 62 templates.
Developer Tools Content Management Systems App Automation
21
mcpOAuth
com.mdtidy
Clean, repair, and convert AI-generated Markdown to HTML/PDF/DOCX/PNG; save and share documents.
Content Management Systems Developer Tools
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

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 Group Markdown to Word MCP
Developer Tools Workplace & Productivity Content Management Systems
jackdark425
A
license
A
quality
C
maintenance
Converts Markdown documents to professional Word documents with advanced formatting capabilities including mathematical formulas, custom styling, tables, images, headers/footers, and watermarks.
Updated 4 months ago (2026-04-24 05:56 UTC)
4
98
13
MIT
mcp-server-docx
Workplace & Productivity Developer Tools
jamesmehorter
F
license
B
quality
C
maintenance
Enables creating professional Word documents from markdown or structured content with fast, customized formatting via natural language.
Updated a year ago (2025-10-18 14:56 UTC)
7
1
-
mcp-md-pdf
Workplace & Productivity Developer Tools
sham-devs
A
license
A
quality
D
maintenance
Converts Markdown files to Word (.docx) and PDF documents. Supports .dotx templates for branded styling and batch conversion.
Updated 10 months ago (2025-10-24 13:05 UTC)
3
1
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/MDMagic-MCP/mdmagic-mcp-server'

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

MDMagic MCP Server

Установка

Claude Desktop

Cursor

VS Code (с расширением MCP)

Хостинг (без установки)

Что вы можете делать

Инструменты

convert_document — параметры ввода

Конфигурация

Ценообразование

Конфиденциальность

Устранение неполадок

Локальная разработка

Ссылки

Лицензия

Available Tools

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API

`convert_document` — параметры ввода