de en es ja ko ru zh

mdmagic-mcp-server

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

by MDMagic-MCP

Overview Schema Source Related Servers Discussions Admin

TypeScript

Hybrid

MDMagic MCP 服务器

使用您自己的 Word 模板（信头、品牌标识、字体）将 Markdown 转换为 DOCX、PDF 和 HTML。 此外，还提供 15 款设计师精心制作的模板，供您在没有自定义模板时使用。

npm version MCP Registry Smithery license

MDMagic 可直接接入 Claude、Cursor、VS Code 以及任何兼容 MCP 的 AI 助手，使它们能够直接访问专业的文档转换流水线（Pandoc + Microsoft Graph + Mammoth.js），更重要的是，能够访问您的模板。上传您现有的信头、信纸、品牌指南、合同草稿或提案模板——任何您已经在 Microsoft Word 中使用的内容——您的 AI 助手即可将任何 Markdown 直接转换为带有您的徽标、字体、颜色、页脚、页码、水印和签名块的精美文档。输出效果看起来就像是由您的设计团队制作的，而不是通用的 AI 导出文件。

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（或通过设置 → 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

您可以做什么

连接后，您可以向 AI 助手询问如下内容：

“使用 Executive_Platinum 模板将此 markdown 转换为 PDF。”
“我有哪些可用模板？”
“将这份 800 字的报告渲染为 DOCX + PDF 需要多少积分？”
“使用 Legal_Burgundy 模板，以横向、US Letter 纸张大小渲染此内容。”
“检查我的积分余额。”

AI 会选择正确的工具并返回一个安全的、有时效性的下载链接。

工具

工具	功能
`convert_document`	将 Markdown 转换为 DOCX / PDF / HTML / 三者全部。返回一个安全的过期 URL。
`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`	为描述的目的推荐最佳内置模板（“Q4 董事会资料” → Executive_Platinum）。
`show_default_settings`	您的默认纸张大小、方向和模板偏好。

`convert_document` — 输入选项

提供源文件的三种方式：

content — 原始 markdown 字符串（最常用）
filePath — .md 文件的绝对路径（非常适合 IDE 工作流）
fileContent — base64 编码的 markdown（用于二进制安全传输）

此外：

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`	(必需)	您在 mdmagic.ai/account 的个人 API 密钥
`MDMAGIC_BASE_URL`	`https://api.mdmagic.ai`	仅在本地开发或测试环境覆盖
`REQUEST_TIMEOUT`	`30000`	请求超时时间（毫秒）
`MCP_TRANSPORT`	`stdio`	`stdio`（默认）或用于自托管 Streamable HTTP 的 `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 秒内删除。输出文件在下载后或 60 分钟后（以先到者为准）从 MDMagic 服务器删除。
随机文件名。 源文件使用 UUID，从不使用可识别用户身份的名称。
安全下载 URL。 每次转换返回一个带有会话 ID 和下载令牌的一次性 URL。没有公共文件目录。
API 密钥隔离。 每个用户使用自己的密钥进行身份验证。没有共享凭据。

故障排除

MDMAGIC_API_KEY environment variable is required 在您的客户端配置中设置环境变量（JSON 中的 env 块）。不要在 shell 中设置——npx 看不到它。

Invalid API key format 密钥必须匹配 mdmagic- 后跟 16 位数字。请从您的账户页面准确复制。

Failed to connect to MDMagic API 在浏览器中检查 https://api.mdmagic.ai/health。如果它正常，则问题出在本地网络或防火墙。确认运行 MCP 的机器可以访问 MDMAGIC_BASE_URL（默认 https://api.mdmagic.ai）。

工具未出现在 Claude Desktop 中 编辑 claude_desktop_config.json 后，请完全退出并重新启动 Claude Desktop——仅关闭窗口是不够的。

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 Inspector (npm run inspector) 会启动一个 Web UI，用于逐个测试服务器工具——在添加新工具或调试参数验证时非常有用。

使用 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.

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

Deploy Server

Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.comAd

TDQS

A4.6/5.0

Scored 2026-05-09 23:50 across 10 tools

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

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 docs and web pages to clean Markdown: PDF, DOCX, XLSX, EPUB, scans, URLs. Batch of 10.
Browser Automation Documentation Access Web Scraping
51

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 10 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 6 months ago (2026-04-24 05:56 UTC)
4
80 npm
14
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 a year ago (2025-10-24 13:05 UTC)
3
1
MIT

MDMagic MCP 服务器

安装

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

Related MCP Connectors

Related MCP Servers

`convert_document` — 输入选项