mdmagic-mcp-server
Server Details
Use your own Word templates to convert Markdown → DOCX/PDF/HTML from any MCP-compatible AI.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
- Repository
- MDMagic-MCP/mdmagic-mcp-server
- GitHub Stars
- 0
- Server Listing
- mdmagic-mcp-server
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4.6/5 across 10 of 10 tools scored.
Each tool serves a distinct purpose: credit checking, conversion, cost estimation, template details, three levels of template listings, recommendation, default settings, and markdown validation. There is no overlap or ambiguity between them.
All tool names follow a consistent verb_noun pattern in snake_case (e.g., check_credit_balance, list_all_templates, validate_markdown). No mixing of conventions or vague verbs.
With 10 tools, the server is well-scoped for its purpose of MDMagic conversion and credit management. Each tool contributes to a complete workflow without being superfluous or sparse.
The toolset covers the core conversion lifecycle: credit checking, estimation, validation, conversion, and template discovery. Minor gaps exist (no tool for purchasing credits or uploading custom templates), but these are likely handled outside the MCP scope.
Available Tools
10 toolscheck_credit_balanceARead-onlyIdempotentInspect
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
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint, idempotentHint, and destructiveHint. The description adds value by detailing the return values (subscription credits, purchased credits, plan name, plan status), which is 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, starting with the main purpose in one sentence, then a bullet list of proactive use cases. No redundant information. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple no-parameter, read-only tool without an output schema, the description is complete. It explains what the tool returns and when to use it, covering all necessary context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, so schema coverage is 100%. The baseline is 4 since the description doesn't need to add parameter information. No issues.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it checks the user's MDMagic credit balance, specifying what is included: subscription credits, purchased credits, plan name, and plan status. This verb+resource combination is distinct from sibling tools like estimate_conversion_cost.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly lists proactive use cases: when user asks about credits, after conversion (with a note that convert_document also returns balance), and before large document conversion. It provides clear guidance on when to call.
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.
CRITICAL — newlines in
content: markdown is line-sensitive. Headings (#, ##), tables (| ... |), lists (-, 1.), and code fences (```) ONLY work when each starts on its own line. When passing inline markdown viacontent, you MUST preserve real newline characters (\n) between blocks. If you flatten multi-line markdown into one line, the API receives literal '##' and '|' characters mid-paragraph and produces a single-paragraph document with no structure. Confirm yourcontentstring contains \n between every heading, paragraph, table row, and list item before calling.
| Name | Required | Description | Default |
|---|---|---|---|
| content | No | Raw markdown text content (alternative to filePath or fileContent). MUST preserve real newlines (\n) between every block: heading, paragraph, table row, list item, code fence. Markdown is line-sensitive — a single-line blob with embedded '##' or '|' renders as literal text, not as a heading or table. If your source markdown has 30 lines, the string you pass here also has 30 lines separated by \n. | |
| 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. | |
| filePath | No | Path to markdown file (VS Code integration, alternative to content or fileContent) | |
| pageSize | No | Page size for the document (default: A4) | |
| fileContent | No | Base64 encoded file content (alternative to content or filePath) | |
| orientation | No | Page orientation (default: Portrait) | |
| outputFormat | Yes | Output format. 'docx', 'pdf', or 'html' return that single file; 'all' returns a ZIP with DOCX+PDF+HTML. | |
| 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. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate non-read-only and non-destructive. Description adds that conversion consumes credits (creditsUsed, balanceAfter), outputs downloadable files, and emphasizes newline sensitivity. It also surfaces response fields, providing full 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured with numbered points, front-loading the core purpose. While lengthy, each sentence provides essential guidance for correct usage. Slightly verbose but justified by the complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, but description lists the response fields (downloadUrl, creditsUsed, balanceAfter, fileName, expiresAt) and instructs to surface them. Covers error handling for missing templates and parameter behavior, making it very complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but description adds significant value: for content it warns about newline preservation, for fileName it explains derivation from attached file, for templateName it instructs to call list_all_templates. It also elaborates on outputFormat enum values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Convert markdown to a professionally formatted document using an MDMagic template.' It uses specific verb+resource+template, distinguishing it from sibling tools like validate_markdown or recommend_template.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use guidance: ask user for format if ambiguous, handle 'template not found' by calling list_all_templates, avoid fallback to code execution, and specify newline preservation. Also includes what not to do.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
estimate_conversion_costARead-onlyIdempotentInspect
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.
| Name | Required | Description | Default |
|---|---|---|---|
| content | Yes | Markdown content to estimate credit cost for | |
| pageSize | No | Page size for the document | |
| orientation | No | Page orientation | |
| outputFormat | Yes | Output format(s): docx (DOCX only), pdf (DOCX+PDF), html (DOCX+HTML), all/all-formats (DOCX+PDF+HTML) | |
| templateName | Yes | Template ID or name (UUID for custom templates, name for system templates) |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds details about what the tool returns (word count, page calculation, credit breakdown) and implies no side effects. Consistent 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is 4 sentences, front-loaded with the core purpose, followed by return details and usage guidance. Every sentence adds value, no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 5 parameters (3 required) all documented in schema, and no output schema, the description compensates by explaining the return values. Usage context with sibling tool convert_document is clear. Could mention optional parameter defaults, but not critical.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for all 5 parameters. The tool description does not add additional meaning or defaults for parameters, only mentions output structure. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Estimate credit cost for a conversion BEFORE running it', specifying the action (estimate), resource (credit cost for conversion), and temporal aspect (before running). It distinguishes from convert_document by indicating this is a pre-run estimation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Use this when the user asks 'how much will this cost?' or when you suspect a conversion might exceed their balance', and contrasts with convert_document which refuses if credits insufficient. Provides clear when-to-use and why it's friendlier.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_template_detailsARead-onlyIdempotentInspect
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.
| Name | Required | Description | Default |
|---|---|---|---|
| templateName | Yes | Template ID or name (e.g. Executive_Platinum, or a UUID for custom templates) |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint, so the description adds context that all templates support the full 5x2 matrix, which is a behavioral trait. 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the purpose. Every sentence adds value: the first states the function, the second gives usage context and the matrix details. No fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with one parameter and no output schema, the description covers purpose, usage, and expected data (the matrix). It is complete enough, though it does not specify the return format (likely a list of variants), which might require inference.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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. The description adds no additional parameter details beyond 'Template ID or name and examples' already in the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool shows available variants (page sizes and orientations) for a specific template, with specific examples of the matrix (A3, A4, etc.). It distinguishes itself from sibling tools like convert_document and list_all_templates by focusing on template variant availability.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage examples ('does this template come in Legal Landscape?') and indicates it should be used before convert_document. While it doesn't explicitly mention when not to use it, the context signals and sibling tool list make the scope clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_all_templatesARead-onlyIdempotentInspect
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').
| Name | Required | Description | Default |
|---|---|---|---|
| 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). | |
| includeDetails | No | Include template details like available page sizes and orientations (default: false) |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. The description adds behavioral context: output includes name, description, type, category; category filter only affects built-in templates; custom templates always included. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise yet thorough: one sentence for core function, bulleted list for usage guidance, and a summary of return format. Every sentence serves a purpose with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema, the description adequately explains the return structure (name, description, type, category), categories and their counts. It also accounts for siblings and provides sufficient context for an agent to decide when to use this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, baseline 3. The description adds value beyond the schema by explaining how to use the category filter with examples ('for legal documents' → 'Professional') and clarifying that custom templates are always included regardless of filter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'list', the resource 'MDMagic templates', and explicitly specifies scope: 'all 15 built-in ... plus any custom templates'. It distinguishes from sibling tools like list_builtin_templates and list_custom_templates by covering both.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit proactive calling scenarios in bullet points, such as when the user mentions a template, asks for available templates, or when a previous convert_document fails. It also gives guidance on using the category filter to narrow recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_builtin_templatesARead-onlyIdempotentInspect
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).
| Name | Required | Description | Default |
|---|---|---|---|
| category | No | Optional filter — return only templates in this category. | |
| includeDetails | No | Include template details like available page sizes and orientations (default: false) |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the agent knows it's safe. The description adds that there are exactly 15 templates, they are grouped by category with counts, which are behavioral traits not covered by annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: two sentences plus a compact category list. It is front-loaded with the main purpose and usage guidance, with no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple listing nature with full annotations and schema coverage, the description covers purpose, usage, and category details. It does not describe the output format, but no output schema is provided. Still, the description is largely complete for decision-making.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with both parameters described. The description adds value by listing the available categories with counts, enriching the 'category' parameter's meaning beyond the enum list. For 'includeDetails', the description does not repeat schema details but the schema already suffices.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists built-in MDMagic templates grouped by category, and distinguishes it from the sibling tool list_all_templates by excluding user uploads. The verb 'List' and specific resource 'built-in MDMagic templates' are precise.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells when to use this tool ('when the user asks specifically about MDMagic's bundled templates') and contrasts it with list_all_templates, providing clear guidance on alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_custom_templatesARead-onlyIdempotentInspect
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.
| Name | Required | Description | Default |
|---|---|---|---|
| includeDetails | No | Include template details like available page sizes and orientations (default: false) |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the description adds context beyond those: it limits the scope to custom-uploaded Word templates and mentions the UUID reference constraint. 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short, focused sentences with no extraneous information. Every sentence provides essential information: purpose, usage context, and an important usage detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with one optional parameter, rich annotations, and no output schema, the description covers all necessary context: what it lists, when to use it, and a key UUID note. Minor omission: could mention that no parameters are required, but inferable from schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (only parameter includeDetails has a description in schema). The description does not add additional semantic value beyond the schema, but the baseline of 3 is appropriate since schema already explains the parameter adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it lists only the user's custom-uploaded Word templates, using a specific verb ('list') and resource ('custom-uploaded Word templates'). It differentiates from sibling tools like list_all_templates and list_builtin_templates by the scope 'user's custom-uploaded'. Examples of user queries reinforce the purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use guidance with example queries ('show me my templates', 'do I have a letterhead?') and distinguishes from siblings implicitly. Also adds a critical usage note that custom templates are referenced by UUID, not name, when calling convert_document.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
recommend_templateARead-onlyIdempotentInspect
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'.
| Name | Required | Description | Default |
|---|---|---|---|
| topN | No | How many recommendations to return (1-5, default 3) | |
| purpose | Yes | Free-text description of the document's purpose. Examples: 'Q4 board pack for investors', 'restaurant menu', 'developer API documentation', 'wedding invitation'. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds behavioral details beyond annotations: returns ranked recommendations with rationale, and prevents failures in convert_document. No contradiction with annotations (readOnlyHint, idempotentHint, destructiveHint).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with two paragraphs: first explains usage, second explains rationale. Could be slightly more concise, but front-loaded with key info.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With only 2 parameters, good annotations, and no output schema, the description covers purpose, usage, rationale, and expected output (ranked recommendations) thoroughly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description mentions the purpose parameter implicitly but adds little new beyond what the schema provides. The 'Why this exists' part provides context but not parameter-level detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Suggest the best built-in template(s) for a described purpose.' Distinguishes from siblings like convert_document and list_all_templates by focusing on purpose-to-template mapping.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Use this when the user describes WHAT the document is without naming a template.' Also explains why it exists (to avoid guessing non-existent templates), providing clear when-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
show_default_settingsARead-onlyIdempotentInspect
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.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare it as read-only, idempotent, and non-destructive. The description adds context that it retrieves preferences set on the account page, which is useful behavioral detail beyond what annotations provide. 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with zero waste. The description is front-loaded with the core purpose, followed by usage guidance. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless read-only tool without an output schema, the description sufficiently explains what data is returned (paper size and orientation) and where the settings originate. No gaps exist given the simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, and schema coverage is 100%. Baseline is 4. Description doesn't need to add parameter info, and it doesn't, which is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it shows the user's default paper size and orientation preferences. The action is specific (show defaults) and the resource (user's account settings) is distinct from sibling tools like convert_document or list_templates.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use guidance: call when the user hasn't specified pageSize/orientation to honor defaults instead of using A4/Portrait blindly. Clearly distinguishes from the alternative of hardcoding defaults, though doesn't name a specific sibling tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
validate_markdownARead-onlyIdempotentInspect
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.
| Name | Required | Description | Default |
|---|---|---|---|
| content | Yes | Markdown content to validate | |
| filename | No | Optional filename label for the response (defaults to 'content.md') |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds context by specifying what issues it catches and the return format (green/amber/red status plus features), without contradicting annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively concise, front-loading the purpose and organized into clear sections. Minor redundancy could be trimmed, but overall it efficiently conveys key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's scope, the description covers purpose, usage guidelines, detected issues, and return values. It is sufficiently complete for an AI agent to understand when and how to use the tool, though it could mention limitations or unsupported features.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with clear descriptions for both parameters. The description does not add significant extra meaning beyond the schema, so baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool validates markdown before conversion, catching specific issues like malformed tables and unclosed code fences. It distinguishes itself from sibling tools like convert_document by focusing on pre-flight checks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly lists scenarios for proactive use: before converting long documents, when previous conversion failed, or when the AI generated the markdown. Also implies the alternative is convert_document, providing clear when-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!
Your Connectors
Sign in to create a connector for this server.