Skip to main content
Glama

Taokeh MCP server

Get document PDF link

get_document_pdf
Read-only

Get a shareable link to the ACTUAL PDF of one invoice, quote or credit note — so you can hand the user (or their customer) the real document, e.g. "here's your invoice". Identify the document by its docId (from search_documents) OR its printed docNumber (e.g. the invoice number) — give one; if a number matches several documents I'll list them so you can pick the id. Returns a short-lived signed URL (works for ~15 minutes, for anyone who has it — so share it deliberately), the document number, and when it expires. Covers invoices, quotes and credit notes (they share one document layout). A CANCELLED document still has a PDF, stamped: a voided quote or a voided CREDIT NOTE comes back with a large diagonal VOID across every page, so it can be handed over as the record of what was cancelled but never passed off as live — say so when you share it, and never quote its amount as money owed or credited. On a voided credit or debit note the PDF also states it in WORDS, not only the watermark (2026-09-14): its header box reads Status VOID with no payment term or due date, the total is labelled what it WAS ('Total credited' / 'Total charged') in a muted bar rather than the usual Grand Total, and a line beneath reads 'Nothing is credited now — this credit note was voided on '. So the document says the thing you must say; quote THAT, not the figure. search_documents finds a voided credit note too and reports its status as "Credit note (VOID)"; read that before you describe the document. (A voided INVOICE is the exception — voiding one removes it from the books entirely, so there is no link left to give and search_documents will not find it either.) LANGUAGE: the PDF's printed words (Bill to, due date, column headings, totals) follow the company's Document language setting — the same setting covers the company's invoice, quote, delivery order, credit and debit note and purchase order PDFs — — English unless the owner chose Bahasa Malaysia on Settings → Preferences — so a voided note's sentence may read in Malay; names and descriptions always print as typed. It is not the app language, and you cannot change it per link. This does not email anyone — it hands YOU a link to pass on.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
docIdNoThe document id (from search_documents). Give this or docNumber.
docTypeYesWhich document: 'invoice', 'quote' or 'credit_note'.
docNumberNoThe printed document number (e.g. the invoice/quote reference). Give this or docId; resolved case-insensitively and must match exactly one document.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.5/5.0
Behavior5/5

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

Annotations only declare readOnlyHint and openWorldHint; the description adds substantial behavior the agent could not otherwise know: the URL is signed, short-lived (~15 min), and shareable by anyone holding it. It discloses that voided documents still produce stamped PDFs (diagonal VOID, 'Status VOID' header, 'Total credited/charged' labels, an explicit sentence in the PDF), that voided invoices have no link at all, and that printed language follows a company setting. This far exceeds the annotation bar.

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

Conciseness3/5

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

Purpose is front-loaded and no section is entirely off-topic, but the mass is disproportionate: the voided-document behavior is restated across several long clauses, there is a dangling dated parenthetical ('2026-09-14') and a doubled em-dash typo. The same facts could be conveyed in roughly a third of the words.

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?

No output schema exists, and the description compensates by naming the return payload (signed URL, document number, expiry) and covers the real edge cases: ambiguous numbers, voided invoices being unfindable, voided credit notes still resolving, and the language setting. Nothing needed to call this correctly is missing.

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%, so the baseline is 3. The description matches and slightly extends the schema: docId comes 'from search_documents', docNumber is the printed number, and it adds the ambiguity behavior — 'if a number matches several documents I'll list them so you can pick the id' — which the schema does not state. DocType is implicit in the description's enumeration of invoice/quote/credit note.

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?

Opens with a specific verb+resource+scope: 'Get a shareable link to the ACTUAL PDF of one invoice, quote or credit note.' It distinguishes itself from search_documents (the identifier source) and states exactly what it does not do ('This does not email anyone — it hands YOU a link'). An agent can pick it apart from siblings immediately.

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?

Gives clear context for use — hand the real document to a user or their customer — and two explicit identification paths (docId from search_documents or docNumber). It also routes the agent to search_documents to read a document's VOID status before describing it. It does not contrast against other link/attachment siblings (get_attachment, request_attachment_upload), so it stops short of full alternatives coverage.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources