Skip to main content
Glama

Document to Markdown

talonic_to_markdown

Retrieve full text of any document as markdown using OCR. Ideal for summarization, translation, or general text extraction.

Instructions

Get the OCR-converted markdown text of a document.

USE WHEN: the user wants the full text — 'what does it say', summarise, or translate a document. NOT FOR: specific structured fields (use talonic_extract with a schema). BY NAME: if the user names a file, call talonic_search first to get its document_id, then call this. ARGS: prefer document_id (a workspace doc — one cheap call). Otherwise file_url, or file_data+filename for small local files — provide exactly one. A file input ingests the document first and consumes credits; document_id does not. RETURNS: document_id and markdown (the full text).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
document_idNoThe Talonic document id whose markdown you want. Get this from a previous talonic_extract or talonic_search response.
file_dataNoBase64-encoded file bytes. Recommended path when the agent already has the file in memory (e.g., the user attached a PDF to the conversation). Pair with `filename` so MIME type can be inferred.
filenameNoOriginal filename including extension, e.g. 'invoice.pdf'. Used to infer MIME type when uploading via `file_data`. Required when `file_data` is provided.
file_pathNoLocal path to a document file. Only works if the MCP server has read access to that path. In sandboxed chat clients (Claude Desktop, Cowork) use `file_data` instead.
file_urlNoURL to a document file. The Talonic API fetches it server-side.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
document_idYesID of the document the markdown was extracted from.
markdownYesOCR-converted markdown text content of the document.
costNoPer-call cost and post-call balance from the underlying extract step, parsed from the X-Talonic-* response headers. `null` when the document was already ingested (document_id path) and no extract call ran. Not always present on legacy clients.
Behavior5/5

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

Beyond annotations (readOnlyHint=false, destructiveHint=false, openWorldHint=true), description adds that file inputs ingest and consume credits while document_id does not, and different input methods have different costs.

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?

Well-structured with sections, front-loaded with main purpose. Every sentence adds value. No redundancy.

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?

Given output schema exists, description covers return values (document_id and markdown). Addresses complex input choices and usage scenarios. Complete for tool complexity.

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

Parameters4/5

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

Schema coverage is 100% with good descriptions. Description adds hierarchy: prefer document_id, then file_url, then file_data+filename for small local files. Provides selection guidance beyond schema.

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?

Description clearly states it gets OCR-converted markdown text of a document. Uses verb 'Get' and specifies resource. Distinguishes from sibling talonic_extract for structured fields.

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?

Explicit sections: USE WHEN for full text/summarize/translate, NOT FOR structured fields, BY NAME instructs to first call talonic_search. Provides clear decision rules.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/talonicdev/talonic-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server