Markdown Logic Express

convert_markdown

Read-only

Convert the complete supplied Markdown into PDF, DOCX, HTML or EPUB anonymously. No URL fetch, project access, account or OAuth grant. Limits: 128 KiB UTF-8 Markdown, 512 KiB request, 2 MiB file. Returns an embedded base64 file, not a hosted download. Existing renderer formatting/image limits apply; DOCX uses image placeholders.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "markdown": "<markdown>",
      "format": "<format>"
    },
    "name": "convert_markdown"
  }
}

Input Schema

Name	Required	Description
`format`	Yes
`images`	No	Optional relative-path keys and embedded PNG/JPEG/GIF data URLs. No remote URLs. Existing decode/pixel budgets may replace an image with its alt text.
`options`	No
`filename`	No
`markdown`	Yes	Full source, at most 131072 UTF-8 bytes. Never truncate to meet limits.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 14, 2026

TDQS

A4.4/5.0

Behavior5/5

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

Annotations already declare readOnlyHint=true, openWorldHint=false, destructiveHint=false, and the description goes well beyond them: explicit size ceilings (128 KiB Markdown, 512 KiB request, 2 MiB file), the return shape ('embedded base64 file, not a hosted download'), DOCX image-placeholder behavior, and alt-text substitution when image budgets are exceeded. These are exactly the operational facts an agent cannot infer from the annotations.

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

Conciseness5/5

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

Five short sentences, front-loaded with the verb and target formats, then constraints, then return semantics. No filler; each clause carries a distinct operational fact an agent needs before calling.

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?

With no output schema, the description correctly picks up the burden by explaining that the response is an embedded base64 file rather than a download link, and it covers limits and format-specific caveats. It falls short only on the `options` parameter family, whose rendering controls are never mentioned in prose.

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

Parameters3/5

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

Schema coverage is only 40%, and the description compensates for part of that by restating the 128 KiB Markdown ceiling and constraining images to embedded data URLs with alt-text fallback. However, it says nothing about the twelve-property `options` object (font, theme, margins, pageSize, titlePage, watermark, tableOfContents, etc.) or `filename`, leaving the richest parameter surface to bare enum names.

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 names a specific verb (Convert) and resource (supplied Markdown) and enumerates the four target formats (PDF, DOCX, HTML, EPUB), so the agent knows exactly what the tool produces. It also distinguishes the input mode by stating 'complete supplied Markdown' rather than a URL or project reference.

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

Usage Guidelines4/5

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

It clearly frames the context of use: anonymous, no URL fetch, no project access, no account or OAuth grant, which tells the agent it must pass inline content rather than a reference. It does not name alternative tools or explicitly exclude scenarios, but the preconditions are unambiguous.

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

All Markdown Logic Express tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?