Markdown to PDF: headings, bold, code, lists, rules. A4/Letter/Legal. Free 30/hr. MCP + REST.
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 3.9/5 across 6 of 6 tools scored.
All six tools have clearly distinct purposes: converting markdown to different formats, merging/stamping PDFs, and checking recalls. No two tools are easily confused.
Most tools use a verb_noun pattern (generate_pdf, merge_pdfs, watermark_pdf, check_recalls), but markdown_to_docx and markdown_to_html use a different pattern (source_to_target). The inconsistency is minor and still readable.
With 6 tools, the count is reasonable for a document conversion utility. However, the inclusion of check_recalls feels out of place for a server named 'pdf', slightly diluting focus.
The tool set covers markdown-to-PDF and PDF merging/watermarking, but lacks PDF-to-other-format conversion, splitting, or editing. The recall checker is an unrelated gap filler. Core PDF workflows are partially covered.
check_recallsAInspectCheck whether a product, brand, drug, or vehicle has an official US recall or safety alert. Aggregates openFDA (food/drug/device), CPSC (consumer products), and NHTSA (vehicles, incl. VIN decode) into normalized JSON. Deterministic, official sources only — useful as a pre-purchase safety guardrail for shopping agents.
| Name | Required | Description | Default |
|---|---|---|---|
| vin | No | Vehicle VIN | |
| make | No | ||
| year | No | ||
| model | No | ||
| query | No | Product, brand, or drug name |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden and discloses key behaviors: aggregates multiple official sources, returns normalized JSON, is deterministic, and uses official sources only. It omits rate limits and error behavior but is still informative for a read-only tool.
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 pack purpose, sources, output format, and use case without redundancy. The main function is front-loaded, and every clause 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?
The description covers purpose and sources but doesn't explain parameter combinations (e.g., VIN vs query precedence) or the structure of the normalized JSON. Since there is no output schema, these details are missing.
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?
Only 2 of 5 params have schema descriptions (40% coverage), and the description does not fully map product categories to parameters. It mentions VIN decode but not how make/year/model are used together, leaving a gap in parameter understanding.
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 a specific verb ('Check') and resource ('official US recall or safety alert'), enumerating product categories (product, brand, drug, vehicle) and data sources (openFDA, CPSC, NHTSA). It distinguishes itself from the unrelated document-processing sibling tools.
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?
It explicitly positions the tool as a 'pre-purchase safety guardrail for shopping agents,' providing clear usage context. It doesn't state exclusions or alternatives, but none are needed given the sibling tools are unrelated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
generate_pdfAInspectConvert Markdown into a clean, professionally formatted PDF and return a downloadable URL. Supports # / ## / ### headings, bold, code, - bullet lists, 1. numbered lists, and --- rules. Free tier: 30/hour; pass Authorization: Bearer for unlimited (buy a key at https://alpha-systems.net).
| Name | Required | Description | Default |
|---|---|---|---|
| title | No | Document title, rendered as the top heading. | |
| markdown | Yes | Markdown body. | |
| page_size | No | Page size (default A4). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It discloses rate limits, auth requirements, and the specific Markdown elements supported, which is useful. However, it does not mention error handling, what happens with unsupported Markdown, or whether the returned URL is persistent or temporary.
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 only two sentences, front-loading the core purpose in the first sentence and following with supported features and usage limits in the second. Every sentence adds value, with no filler or repetition of schema details.
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 (3 params, no output schema, no annotations), the description is largely complete: it specifies the return value (downloadable URL), usage limit, and supported Markdown subset. It could mention error handling or default behavior for omitted optional params, but the schema already covers defaults (e.g., page_size A4).
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 schema already describes all three parameters (markdown, title, page_size), so baseline is 3. The description adds meaningful detail by enumerating the supported Markdown syntax (headings, bold, code, lists, rules), which clarifies what the markdown parameter accepts and how it will be rendered. This goes beyond the schema's generic 'Markdown body.'
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 a clear verb+resource: 'Convert Markdown into a clean, professionally formatted PDF and return a downloadable URL.' It explicitly contrasts with sibling tools like markdown_to_docx and markdown_to_html by targeting PDF output, making it easy to distinguish.
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 context for usage, including the free tier limit (30/hour) and that passing an Authorization: Bearer key enables unlimited use. It does not explicitly name alternatives or provide when-not-to-use guidance, but the PDF-focused purpose implies when to select it over other markdown converters.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
markdown_to_docxAInspectConvert Markdown into an editable Microsoft Word (.docx) document. Returns a downloadable URL.
| Name | Required | Description | Default |
|---|---|---|---|
| title | No | Document title. | |
| markdown | Yes | Markdown source. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It states the conversion behavior and return of a downloadable URL, which is useful. However, it does not disclose any edge cases, limitations, or operational details, so transparency is partial.
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?
Single sentence, front-loaded with the verb, includes the key outcome and result format—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?
For a simple 2-parameter conversion tool, the description covers the essential purpose (Markdown to Word), the editable nature, and the delivery mechanism (downloadable URL). Lacks explicit usage guidance but is largely complete given the low 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?
Input schema already describes both parameters (title and markdown) with 100% coverage, so the description adds no additional parameter-specific detail. Baseline 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 uses specific verb 'Convert' with source 'Markdown' and target 'editable Microsoft Word (.docx)', clearly distinguishing from sibling tools that output HTML or PDF.
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 clear context that the output is an editable Word document and returns a URL, implying use when a downloadable Word file is needed. However, it doesn't explicitly exclude alternatives or state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
markdown_to_htmlAInspectConvert Markdown into a styled, standalone HTML document. Returns a downloadable URL.
| Name | Required | Description | Default |
|---|---|---|---|
| title | No | Document title. | |
| markdown | Yes | Markdown source. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It honestly reports that the output is a downloadable URL, which is a key behavioral detail. However, it doesn't mention potential side effects, storage/retention behavior, or limitations, which could be relevant. No contradiction with annotations exists (none provided).
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?
A single, front-loaded sentence that efficiently states the purpose and return value with zero superfluous content. Every word contributes meaning.
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 has low complexity (2 parameters, no output schema) and the description covers the essential output ('downloadable URL') and format ('standalone HTML'). It doesn't explain potential limitations or styling details, but for a straightforward converter, this is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with both parameters ('title' and 'markdown') having descriptions. The tool description adds no extra meaning beyond the schema, such as detailing how the title is used in the generated HTML, so it remains at the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Convert' and the resource 'Markdown', with the output specified as 'a styled, standalone HTML document'. This distinguishes it from sibling tools like markdown_to_docx by explicitly naming HTML as the target format.
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?
No guidance is provided on when to use this tool versus alternatives such as generate_pdf or markdown_to_docx. The description implies a use case for standalone HTML, but does not explicitly state selection criteria or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
merge_pdfsAInspectMerge multiple PDFs into a single PDF. Returns a downloadable URL.
| Name | Required | Description | Default |
|---|---|---|---|
| pdfs | Yes | Base64-encoded PDF files (2 to 50). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavior. It only states the output ('downloadable URL') and does not mention safety, whether original files are modified, order of merging, limitations, or error handling. This is minimal behavioral context.
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 a single concise sentence that front-loads the action and outcome. Every word earns its place, with no repetitive or extraneous content.
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 parameter, no output schema), the description covers the basic purpose and result. However, it omits important contextual details such as how the merge order is determined, any file size limits beyond the stated range, and whether any side effects occur. This is sufficient for a basic tool but leaves some gaps.
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 fully describes the single parameter 'pdfs' as 'Base64-encoded PDF files (2 to 50),' which is clear and complete. The description itself adds no additional parameter-level meaning beyond the schema, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool merges multiple PDFs into a single PDF and returns a downloadable URL, which is a specific action and outcome. This unambiguously distinguishes it from sibling tools like watermark_pdf or generate_pdf.
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 implies usage for merging PDFs but does not explicitly state when to use it over alternatives or mention any exclusion criteria. There is no guidance such as 'use watermark_pdf for watermarks,' so the usage context is only implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
watermark_pdfAInspectStamp a diagonal text watermark across every page of a PDF. Returns a downloadable URL.
| Name | Required | Description | Default |
|---|---|---|---|
| Yes | Base64-encoded PDF. | ||
| text | No | Watermark text (default "DRAFT"). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavioral traits. It states that the watermark is applied to every page, the watermark is diagonal text, and it returns a downloadable URL, which implies a non-destructive operation producing a new file. While it does not cover error cases or side effects, the disclosed behavior is adequate for this simple tool.
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 a single sentence that immediately states the action and the output. There is no redundant or filler content; every word adds value, making it highly concise and well-structured.
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?
This is a simple tool with only two parameters and no output schema. The description sufficiently explains the core behavior and explicitly states the return type ('downloadable URL'), which covers the essential context needed for a user to understand and invoke the tool. It does not elaborate on edge cases or error conditions, but these are not critical for basic usage.
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 covers 100% of the parameters with individual descriptions, providing clear semantics for 'pdf' and 'text'. The tool description adds no additional parameter-level meaning, so the baseline score of 3 applies here.
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 function: 'Stamp a diagonal text watermark across every page of a PDF.' The verb 'stamp' and the resource 'PDF' identify the action and target, while the qualifiers 'diagonal text watermark' and 'every page' add specificity. It also mentions the return type, distinguishing it from sibling tools like merge_pdfs.
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 does not explicitly discuss when to use this tool versus alternatives, nor does it name any exclusions. However, the purpose is self-evident from the name and description, so usage is implied rather than explicitly guided. A clear statement about when to choose this over merge_pdfs or generate_pdf would improve this dimension.
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!