Convert Markdown into boardroom-grade DOCX, PDF, and HTML using your own custom Word templates — or any of MDMagic's 15 designer-built ones across Business, Creative, Professional, and Technical. Ten tools cover conversion, template recommendations, cost estimation, and markdown validation.
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.
Average 4.5/5 across 10 of 10 tools scored.
Each tool targets a distinct function: credit management, conversion, estimation, template listing/details/recommendation, validation, and settings. Even the three list tools are clearly differentiated by scope (all, built-in, custom). No ambiguity.
All tools follow a consistent verb_noun snake_case pattern (e.g., check_credit_balance, list_all_templates, validate_markdown). No mixing of styles or vague verbs.
With 10 tools, the surface is well-scoped for a document conversion server. Each tool addresses a necessary step in the conversion workflow without being overengineered or sparse.
The tool set covers the full lifecycle: credit checks, cost estimation, markdown validation, template discovery (all/built-in/custom), details, recommendations, conversion, and default settings. No obvious gaps for the intended use case.
check_credit_balanceACheck 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 | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly=true, idempotent, not destructive. Description adds detail about returned fields (subscription vs purchased credits) and proactive call scenarios. 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?
Description is well-structured with purpose first, then usage guidance. Each sentence adds value. Could be slightly more concise, but it's efficient for the given 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 zero-parameter read-only tool with comprehensive annotations, the description is complete. It includes return contents, proactive call scenarios, and links to sibling behavior.
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, so baseline 4. 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.
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 the components (subscription credits, purchased credits, plan name, status). It is distinct from sibling tools like convert_document and 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?
Explicitly specifies when to call (user asks about credits, after conversion, before large conversion) and acknowledges that convert_document also returns balance. Slight room for improvement on when not to call.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
convert_documentAInspectConvert 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 via content, 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 your content string 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. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide minimal behavioral info (readOnlyHint=false, destructiveHint=false). The description adds critical behavioral traits: output format specifics, filename derivation behavior, error recovery strategy, newline sensitivity, and response fields. 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with numbered sections, clear headings, and concise guidance. Every sentence adds value—there is no redundancy or fluff. It is appropriately detailed for the tool's complexity without being verbose.
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 8 parameters, 3 enums, no output schema, and the complexity of the tool, the description covers all necessary aspects: output format options, filename handling, error recovery, page size and orientation defaults, newline requirements, and response field disclosure. It is comprehensive and leaves no critical gap.
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?
The input schema has 100% description coverage, but the description significantly enhances understanding: for 'content' it emphasizes the need for real newlines and provides a concrete example; for 'fileName' it explains how to derive it from attached files; for 'templateName' it instructs to call list_all_templates first. This goes well beyond the schema descriptions.
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 includes a specific verb (convert), resource (markdown), and context (MDMagic template), effectively distinguishing from sibling tools like validate_markdown or list_all_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?
The description provides explicit guidance on when to ask the user for output format (if ambiguous), how to handle 'template not found' errors (call list_all_templates), and when to provide fileName. It also advises against falling back to code execution, offering clear alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
estimate_conversion_costAEstimate 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) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint (true) and destructiveHint (false); description adds that it returns word count and credit breakdown, but does not deeply disclose behavior beyond what annotations convey.
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 purpose and output, followed by usage guidance; every word contributes 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?
Though no output schema, the description explains return structure (word count, page calc, credit breakdown) and use case context; could be enhanced with explicit return type format but is sufficient.
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 the description does not add new parameter-level meaning beyond the schema descriptions; 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 estimates credit cost before conversion, returns word count, page calculation, and credit breakdown, and distinguishes itself from convert_document by noting it runs before conversion.
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 tells when to use: when user asks about cost or when balance might be exceeded, and contrasts with convert_document's refusal behavior, providing clear alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_template_detailsAShow 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) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, so the description adds value by explaining that all templates support a full 5x2 matrix of sizes and orientations. This provides concrete behavioral detail beyond the annotations 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences long, front-loaded with the core purpose, and each sentence contributes meaningful information without verbosity. The examples and sibling reference are efficient and helpful.
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?
Despite lacking an output schema, the description fully explains what the tool returns (the matrix of page sizes and orientations) and notes that all templates support the matrix. This is complete for a simple read-only information 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?
The input schema already provides 100% description coverage for the 'templateName' parameter (ID or name). The description does not add further semantic detail about the parameter; it focuses on the tool's output. Baseline 3 is appropriate given high schema coverage.
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 states the tool shows 'available variants (page sizes and orientations) for a specific template,' using specific verbs and resources. This clearly distinguishes it from sibling tools like 'list_all_templates' which list templates rather than variants for a single 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?
The description gives explicit usage context: 'when the user asks does this template come in Legal Landscape?' and positions it as a prerequisite for 'convert_document.' This provides clear guidance on when to use the tool and its relationship to a sibling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_all_templatesAList 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) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, idempotent, and non-destructive behavior. The description adds valuable behavioral context: returns specific fields (name, description, type, category), mentions that custom templates are always included, gives category breakdown, and explains category filter scope. 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?
The description is concise and well-structured: a single sentence for core purpose, a bulleted list for usage scenarios, and a sentence explaining return fields and category usage. No unnecessary 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?
The description covers what the tool does, when to use it, and what it returns. Given the simplicity of the tool (2 optional params, no output schema, strong annotations), it is nearly complete. Minor omission is explicit mention of return format (likely an array), 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 description coverage is 100% with both parameters well-described. The description reinforces usage of the optional category filter for recommendations and reiterates that custom templates are always included. This adds slight context beyond the schema but doesn't introduce new parameter details.
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 'List all 15 built-in MDMagic templates plus any custom templates the user has uploaded.' It specifies the action (list), the resource (templates), and distinguishes from sibling tools like list_builtin_templates and list_custom_templates by being the combined version. The title from annotations reinforces this.
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 four proactive call scenarios: when user mentions a template by name, asks what's available, when convert_document fails, or when user describes a look. It also suggests using the category filter to narrow recommendations. This provides clear guidance on when to use this tool versus alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_builtin_templatesAList 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) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the description doesn't need to. It adds context about grouping and count (15), which is useful beyond 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two efficient sentences, front-loaded with purpose and usage guidance. Every sentence adds value. No wasted words.
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 simplicity, good annotations, and comprehensive schema, the description provides all necessary context: purpose, when to use, category info, and distinction from sibling. No output schema needed.
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 restates categories available (already in enum) but doesn't add new parameter-level details. It does not degrade or improve beyond schema.
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 'List the 15 built-in MDMagic templates, grouped by category' and distinguishes it from 'list_all_templates' by specifying it excludes user uploads. The verb and resource are specific.
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 instructs to use when the user asks about 'MDMagic's bundled templates rather than their personal ones' and contrasts with the sibling tool 'list_all_templates'. Provides contextual help.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_custom_templatesAList 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) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint false. The description adds valuable context about UUID referencing but does not elaborate on other behaviors like rate limits or auth needs. Still, it adds meaningful insight 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?
Two sentences, front-loaded with the core purpose, no unnecessary words. Every sentence earns its place by providing distinct 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?
Given the tool's simplicity (one optional parameter, no output schema), the description is complete. It covers purpose, usage context, and a behavioral pointer. No missing elements.
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 the includeDetails parameter fully described. The description does not add any additional meaning to the parameter beyond what the schema provides, 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 it lists 'only the user's custom-uploaded Word templates', providing a specific verb and resource. It distinguishes from siblings like list_all_templates and list_builtin_templates by narrowing to custom 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?
Explicitly states when to use: 'when the user asks about their own templates' with example queries. Also provides a key tip about UUID referencing when calling convert_document, helping the agent avoid misuse.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
recommend_templateASuggest 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'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, indicating safe read-only behavior. The description adds value by explaining the output format: 'Returns ranked recommendations with rationale.' It does not contradict annotations and provides additional behavioral context about the mapping from purpose to real template names.
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, with two short paragraphs that are front-loaded with the core purpose. The second paragraph adds rationale without being verbose. It efficiently communicates usage and motivation.
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 no output schema, the description adequately covers what it does, when to use, and the nature of the output. It does not cover edge cases like ambiguous purposes, but overall it is sufficient for an agent to correctly select and invoke 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%, so baseline is 3. The description does not add new parameter semantics beyond the schema; it only provides usage examples for the 'purpose' parameter, which are already present in the schema. No additional depth for 'topN' beyond schema description.
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's purpose: 'Suggest the best built-in template(s) for a described purpose.' It provides concrete examples (Q4 board pack, API reference) and distinguishes itself from sibling tools like list_all_templates by specifying the use case of mapping a described purpose to template names.
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 states when to use: 'Use this when the user describes WHAT the document is... without naming a template.' It also explains why it exists (to avoid guessing template names) and implicitly indicates when not to use (when user names a template directly), providing clear guidance on alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
show_default_settingsAShow 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 | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false. The description adds value by explaining that the preferences come from the account page, but does not detail the response format or side effects. With strong annotations, this is sufficient.
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 two sentences, concise and front-loaded. Every sentence adds value: the first states what it shows and where from, the second explains when to use it. No wasted words.
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 zero parameters, no output schema, and comprehensive annotations, the description is complete. It tells the agent the purpose, use case, and why it's important, without needing further information.
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 the description need not explain them. It correctly omits any parameter information, as schema coverage is 100%.
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 the user's default paper size and orientation preferences, specifying the source (account page) and the context. This distinguishes it from other tools like list_all_templates or convert_document.
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 states when to use the tool: when the user hasn't specified pageSize/orientation explicitly, to honor defaults instead of blindly using A4/Portrait. This provides clear guidance and an alternative approach.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
validate_markdownAPre-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') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover safety (readOnlyHint, idempotentHint, destructiveHint false). The description adds behavioral context such as return status (green/amber/red) and specific issues caught, which is helpful 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 front-loaded with purpose and well-structured with bullet points for usage and return format, though slightly verbose. 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?
Given two parameters with full schema coverage, no output schema but return format detailed, and annotations provided, the description is complete. It clearly differentiates from sibling 'convert_document' and covers required 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?
Schema description coverage is 100%, and the description does not add significant detail beyond the schema's parameter descriptions. Baseline 3 applies as per scoring guidelines.
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, using a specific verb 'validate' and resource 'markdown', and distinguishes from sibling 'convert_document' by emphasizing it's a pre-flight check.
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 when to call proactively (long documents, previous conversion failures, self-generated markdown) and implies it's a cheap alternative to a doomed conversion, providing clear context for usage.
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.
No comments yet. Be the first to start the discussion!
