mdmagic
Server Details
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.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
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 has a clearly distinct purpose: credit management, conversion, cost estimation, template exploration, settings, and validation. There is no overlap in functionality.
All tools use a consistent verb_noun pattern with underscores (e.g., check_credit_balance, convert_document, list_all_templates). Minor variations like 'get' vs 'list' are still under the same convention.
Ten tools is well-scoped for a document conversion service, covering credit checking, conversion, estimation, template listing/details/recommendations, settings, and validation without excess.
The tool set covers the core workflow: credit management, conversion with cost estimation, template exploration, validation, and settings. Minor gaps like template management (upload/delete) are not present but are handled externally.
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 declare readOnlyHint, idempotentHint, and destructiveHint, so the description does not need to restate. However, it adds value by detailing what specific information is returned (subscription credits, purchased credits, plan name, status), which goes beyond the 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?
The description is concise with two short paragraphs. The first paragraph states the purpose, and the second provides usage guidelines. Every sentence adds value with no redundancy. Front-loaded with the core function.
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 tool is simple with no parameters and no output schema, yet the description fully covers its purpose, the data it returns, and when to use it. It also mentions that convert_document returns balance after conversion, providing useful context. Complete for the tool's complexity.
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 zero parameters, so the baseline score is 4. The description does not need to add parameter semantics, and it correctly focuses on the tool's function. Schema coverage is 100% by default.
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 specifies the verb 'Check' and the resource 'MDMagic credit balance', listing the components returned (subscription credits, purchased credits, plan name, plan status). It differentiates from sibling tools like convert_document which also returns balance but in a different context.
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 call this tool proactively: when the user asks about credits, after a conversion (noting that convert_document also returns it), and before large conversions. It also advises caution for large documents, giving clear usage context.
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?
The description discloses critical behaviors: newline sensitivity affecting markdown parsing, filename derivation, structured response fields with user action items, and page size/orientation defaults. Annotations are minimal (readOnlyHint=false, openWorldHint=true), so the description carries the burden and does so fully.
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 long but well-structured with numbered guidance. It front-loads the core purpose, and each section adds necessary context for the complex conversion task. A slight reduction in redundancy (e.g., the newline explanation) could make it more concise, but it remains effective.
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 complexity (8 parameters, no output schema), the description covers response structure, error handling, defaults, and constraints. It lacks mention of synchronous vs. async behavior, but overall it is comprehensive enough for most scenarios.
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 the description adds significant meaning beyond basic schema descriptions. For example, it explains the criticality of newlines in 'content', provides context for 'fileName' fallback, clarifies 'outputFormat' options, and instructs to use list_all_templates for 'templateName'.
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: 'Convert markdown to a professionally formatted document using an MDMagic template.' It specifies the verb (convert), the resource (markdown to document), and distinguishes from siblings like list_all_templates or validate_markdown by focusing on 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?
Provides explicit when-to-use guidance: ask for format if ambiguous, use list_all_templates on template errors, and avoid fallback to code execution. These instructions help an AI agent make correct decisions and avoid common pitfalls.
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 provide readOnlyHint, idempotentHint, and destructiveHint. The description adds valuable behavioral context: what the tool returns (word count, page calculation, credit breakdown by format and template type) and the business rule (300 words/page). 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?
Two sentences: first states purpose and return values, second provides usage guidance. No wasted words; information is front-loaded and efficient.
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 no output schema, the description explains return values in detail. It covers purpose, usage conditions, and behavioral aspects (friendliness over refusal). The tool's complexity is well-addressed with 5 parameters and 3 required.
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 additional meaning beyond the schema's property descriptions. The only extra context is implicit in the overall description, but each parameter's semantics are already clear from the 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 the tool estimates credit cost before conversion and lists what it returns (word count, page calculation, credit breakdown). It distinguishes itself from the sibling 'convert_document' by noting that estimating first is friendlier if credits are insufficient.
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 use: when the user asks 'how much will this cost?' or when you suspect a conversion might exceed their balance. Also explains why it's preferable (friendlier than a refusal from convert_document).
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, openWorldHint, idempotentHint, and destructiveHint. The description adds behavioral context: all MDMagic templates support a full 5×2 matrix of sizes and orientations, which is valuable 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?
Three well-structured sentences: purpose, the matrix details, and usage guidance. No wasted words, front-loaded with essential 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 simplicity (1 param, no output schema), the description covers all necessary aspects: purpose, behavior, usage context, and complementary annotations. Fully adequate for correct selection and invocation.
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% for the single parameter templateName, with examples in the schema description. The tool description repeats the same examples and adds no new semantic information beyond what the schema provides.
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. It uses specific verb 'Show' and resource 'variants for a specific template', and distinguishes from sibling tools like list_all_templates which list templates themselves.
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 guides when to use: '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.' This provides clear context and differentiates from related tools.
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 indicate readOnly, idempotent, non-destructive. Description adds that custom templates are always included regardless of category filter, and that it returns name, description, type, category. 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?
Well-structured and front-loaded with purpose. Use cases are listed clearly. Slightly verbose but each 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?
Covers purpose, return fields, categories, and proactive usage scenarios. Without an output schema, the description adequately explains what to expect. Complete for a list templates 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. Description adds usage context for the category filter with concrete examples (e.g., 'for legal documents' → 'Professional'), enhancing understanding 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?
Clearly states it lists all 15 built-in templates plus custom uploads, with specific verbs and resource. Distinguishes from sibling tools like list_builtin_templates and list_custom_templates by including 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?
Provides explicit proactive use cases (verify before convert, when asked, after error, when describing look). Does not explicitly mention alternatives like get_template_details, but gives clear context for use.
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 provide readOnlyHint, openWorldHint, idempotentHint, destructiveHint=false. The description adds grouping behavior and category counts, which goes 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 plus a compact list of categories and counts. Front-loaded with purpose, every sentence provides 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?
Despite no output schema, the description fully informs what the tool returns: grouped list of templates with counts per category. Differentiates from siblings and covers 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?
Schema coverage is 100% with descriptions for both parameters. The description reinforces the category filter and implies details inclusion, but doesn't add new meaning 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 the tool lists exactly 15 built-in MDMagic templates grouped by category, and distinguishes itself from list_all_templates by specifying it excludes custom uploads.
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 this tool: when the user asks about MDMagic's bundled templates, not personal ones. Also directly compares to sibling list_all_templates.
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, idempotentHint, and destructiveHint=false. The description adds context that the tool lists Word templates and that custom templates are referenced by UUID, 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?
Two sentences with no wasted words. Purpose and usage are front-loaded, making it easy for an AI agent to quickly understand the tool.
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 output schema, the description is nearly complete for a simple list operation. It explains context (UUID reference) but does not describe the return format. Still, given low complexity and rich annotations, it 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 description coverage is 100%, and the description does not add extra meaning beyond what the schema already provides for the includeDetails parameter. Baseline 3 applies.
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 only the user's custom-uploaded Word templates', specifying the verb and resource. It distinguishes this tool from siblings like list_all_templates and list_builtin_templates by focusing on 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 provides usage scenarios ('when the user asks about their own templates') with example queries. Also mentions that custom templates are referenced by UUID when calling convert_document, aiding tool selection.
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?
Annotations already indicate read-only, idempotent, non-destructive behavior. Description adds that the tool returns 'ranked recommendations with rationale' and explains the purpose-to-template mapping, providing context 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?
Description is well-structured with a main sentence followed by a contextual paragraph. Every sentence adds value; there is no redundancy. Slightly longer than minimal but justified by the contextual explanation.
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 (2 parameters, no output schema), the description adequately explains the tool's role and return format. It covers when to use and the rationale, making it complete enough for effective use.
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% and descriptions for both parameters are provided in the schema. The tool description does not add additional parameter semantics beyond what the schema already contains, 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?
Description clearly states the tool's function ('Suggest the best built-in template(s) for a described purpose'), specifies the verb and resource, and distinguishes it from sibling tools like list_all_templates or list_builtin_templates by emphasizing 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?
Description explicitly tells when to use the tool ('when the user describes WHAT the document is... without naming a template'), why it exists (to avoid non-existent template guesses), and contrasts with convert_document by mentioning that this tool ensures templates exist.
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 readOnlyHint, openWorldHint, idempotentHint, destructiveHint=false. Description adds context that defaults come from account page, but does not need to restate safety. Adds moderate value 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 purpose, no wasted words. 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 no output schema, description sufficiently states what is returned (default preferences). Could mention output format briefly, but overall complete for a no-parameter read 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?
No parameters exist, so schema coverage is 100%. Baseline is 4; description adds meaning about what the output contains (defaults) but no parameter details needed.
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). It distinguishes from sibling tools which cover credit, conversion, templates, etc.
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 advises to use when the user hasn't specified pageSize/orientation explicitly, and to honor defaults instead of using A4/Portrait blindly. Provides clear when-to-use and guidance.
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, destructiveHint=false, so the description does not need to repeat safety info. However, it adds useful behavioral context: the result includes a green/amber/red status, detected features, and a human-readable message, which helps the agent understand the call's output 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 well-structured: a one-sentence purpose, then a bullet list of detected issues, followed by clear usage guidelines in a separate section. Every sentence adds value without 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?
The description explains return values (status, features, message) despite no output schema, which is good. It lists example features (tables, code blocks, etc.) and covers usage scenarios. Minor improvement would be to explicitly state the response format, but overall it is sufficiently complete for a validation 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 description coverage is 100%, with both parameters already documented. The description does not add new meaning to the parameters beyond what the schema provides. 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's purpose as 'Pre-flight markdown validation BEFORE conversion' and enumerates what it catches (malformed tables, unclosed code fences, etc.) and returns (status, features, message). This fully distinguishes it from the sibling conversion tool.
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 provides three scenarios for proactive use: long documents, after previous broken conversion, or when self-generating markdown. This gives clear when-to-use guidance and implies when not to use (short/simple documents) by contrasting with the credit cost of conversion.
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!