Skip to main content
Glama

mdmagic-mcp-server

by io.github.MDMagic-MCP

get_template_details

Read-onlyIdempotent

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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
templateNameYesTemplate ID or name (e.g. Executive_Platinum, or a UUID for custom templates)

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. Changed1 schema field changed
    • changedOutput schema / (root)
      Previous value: -{
-  "properties": {
-    "orientations": {
-      "description": "Supported orientations",
-      "items": {
-        "type": "string"
-      },
-      "type": "array"
-    },
-    "pageSizes": {
-      "description": "Supported page sizes",
-      "items": {
-        "type": "string"
-      },
-      "type": "array"
-    },
-    "template": {
-      "properties": {
-        "category": {
-          "description": "Category label (built-in templates only)",
-          "type": [
-            "string",
-            "null"
-          ]
-        },
-        "description": {
-          "description": "Short description of the template's intended use",
-          "type": "string"
-        },
-        "id": {
-          "description": "Template ID — pass this as templateName to convert_document",
-          "type": "string"
-        },
-        "name": {
-          "description": "Human-readable template name",
-          "type": "string"
-        },
-        "type": {
-          "description": "Source of the template",
-          "enum": [
-            "built-in",
-            "custom"
-          ],
-          "type": "string"
-        }
-      },
-      "required": [
-        "id",
-        "name",
-        "type"
-      ],
-      "type": "object"
-    }
-  },
-  "required": [
-    "template",
-    "pageSizes",
-    "orientations"
-  ],
-  "type": "object"
-}New value: +null
  2. First observed

TDQS

A4.4/5.0
Behavior4/5

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

The description adds behavioral context beyond the annotations by stating that all MDMagic templates support the full 5×2 matrix, which is a useful invariant for the agent to know. It also frames the tool as a confirmation step before conversion. The annotations already declare the tool read-only, idempotent, and non-destructive, so the added context about the uniform variant matrix is valuable but not exhaustive.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

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

The description is three sentences, front-loaded with the core purpose. The second and third sentences add specific usage context and a mention of the variant matrix without redundancy. Every sentence contributes meaning, making it concise and well-structured.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with one parameter, no output schema, and rich annotations, the description is complete. It explains the tool's purpose, when to use it, and the underlying variant matrix. It does not describe the exact return format, but for a simple lookup tool this is not a critical gap given the annotations and the 'Show' verb imply a listing.

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

Parameters3/5

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

The input schema covers 100% of the single parameter, including an example (Executive_Platinum or a UUID). The description does not add parameter-specific details, but the schema is sufficiently descriptive. Per the scoring guideline, high schema coverage yields a baseline of 3, which is appropriate here.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb and resource: 'Show available variants (page sizes and orientations) for a specific template.' It clearly distinguishes itself from siblings by focusing on template variant details rather than listing templates, converting documents, or checking balances. The mention of confirming variants before convert_document runs further clarifies its unique role.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It provides explicit usage triggers: 'Use this when the user asks "does this template come in Legal Landscape?" or "what sizes are available?"' and positions it as a pre-conversion confirmation step. This gives clear when-to-use guidance and implicitly differentiates from convert_document and list_all_templates, which are siblings.

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

All mdmagic-mcp-server toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.5/5.0
Disambiguation5/5

Each tool has a clearly distinct purpose: credit balance vs cost estimation, template listing scoped to all/built-in/custom, and conversion vs validation. The three list tools are explicitly named by scope, eliminating ambiguity.

Naming Consistency5/5

All tool names follow the same verb_noun snake_case pattern (check_, convert_, estimate_, get_, list_, recommend_, show_, validate_), making the API predictable and easy to navigate.

Tool Count5/5

10 tools is well within the ideal 3-15 range for a document conversion service. Each tool addresses a necessary step in the workflow (template selection, validation, cost estimation, conversion, credit monitoring) without redundancy.

Completeness4/5

The core lifecycle (pre-flight validation, cost estimation, conversion, balance checking, template discovery) is fully covered. Minor gaps exist—no template upload or settings update—but these are likely handled outside the MCP server, so the surface is complete for its intended agent workflows.

Resources