Skip to main content
Glama
Narashiman-K

Suprasūtā Markdown Notes

by Narashiman-K
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

convert_to_markdown

Convert local PDFs, Office files, images, and audio to clean Markdown automatically, saving a .md file beside the original—no upload needed.

Instructions

Convert a document on this machine to clean Markdown. Handles PDF, Word (.docx), Excel (.xlsx/.xls/.xlsm), PowerPoint (.pptx), OpenDocument text and spreadsheets (.odt/.ods), EPUB, CSV/TSV and plain text. Images are read with OCR, and audio is transcribed. Conversion happens locally and the file is not uploaded, except for the image and audio cases noted in ocr_mode. Prefer this over reading a binary file directly.

The Markdown is SAVED AUTOMATICALLY as a .md file beside the original, so the user does not need to ask. Short documents are also returned in full; long ones come back as a preview plus the saved path, to avoid filling the conversation with tens of thousands of words. If you need more of a long document than the preview shows, call this again with return_content "full".

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pathYesAbsolute path to the file to convert.
saveNoSet false to skip writing the .md file. Default true — the file is saved beside the original without needing to be asked for.
save_toNoAbsolute path to write the .md to, overriding the default of beside the original.
ocr_modeNoFor images only. "offline" (default) runs on this machine and uploads nothing. "cloud" sends the image to Google Gemini, which is more accurate and can describe charts, and requires GEMINI_API_KEY.
overwriteNoSet true to replace an existing .md of the same name. Default false, in which case a numbered name is used instead so nothing is destroyed.
return_contentNo"auto" (default) returns the whole document if it is short, otherwise a preview and the saved path. "full" always returns everything — use only when the user genuinely needs the entire text in the conversation, as a long document can be tens of thousands of tokens. "none" saves and reports the path only, which is cheapest when the user just wants the file.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.9/5.0
Behavior5/5

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

With no annotations, the description carries the full behavioral disclosure burden. It reveals local processing, privacy caveats for image/audio OCR modes, automatic saving beside the original, overwrite behavior with numbered fallback, and the short-vs-long return behavior—all beyond what a name alone would imply.

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

Conciseness4/5

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

The description is information-dense but well organized: formats first, then processing behavior, then save and return behavior. It is longer than strictly minimal, but every sentence adds a useful operational detail, so the length is justified.

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

Completeness5/5

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

For a 6-parameter tool with no annotations and no output schema, the description is remarkably complete. It covers supported formats, privacy, save location, overwrite behavior, return modes, and OCR options, leaving no essential operational gap for an agent deciding whether and how to invoke the tool.

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

Parameters5/5

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

Although the schema already documents all parameters at 100% coverage, the description adds meaningful practical context: the default save behavior, privacy implications of ocr_mode, token-cost warnings for return_content 'full', and the auto-preview behavior. This helps an agent choose parameter values based on user intent rather than just type constraints.

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 states a specific action and resource: converting a document to clean Markdown, and enumerates all supported formats. It clearly identifies this as a single-file conversion tool, distinguishing it from convert_folder_to_markdown and list_supported_formats by scope and purpose.

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 explicitly says to prefer this over reading a binary file directly, and gives concrete guidance on when to use return_content values such as 'full' for long documents. It also explains the default save behavior so the agent knows when not to ask the user for confirmation.

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

Deploy Server

Other Tools