Skip to main content
Glama

Taokeh MCP server

by my.taokeh
OverviewAdmin

Get original document link

get_attachment
Read-only

Get a short-lived link to the ORIGINAL DOCUMENT filed against something in the books — the receipt behind a posted expense, or the receipt/sales note/supplier bill/bank-in slip/name card riding a PENDING draft. Use it to CHECK a document is on file, or to re-read one you filed earlier. Find what to ask for first: search_expenses reports hasAttachment and an attachments list (with an attachmentId) on every posted expense it returns, and each create_*_draft / revise_draft result reports whether an original rides that draft. Give owner plus the id of the thing that owns it — for a posted expense that is the expenseId from search_expenses, plus the attachmentId when the entry carries more than one file; for a draft it is the draftId. Returns a signed URL (about 15 minutes, works for anyone holding it — so treat it as you would the document itself), the filename, the media type and the size in bytes; the bytes themselves are NEVER inlined here, because a base64 blob in a tool result costs about one token per character. Download it and read it yourself: Taokeh does not read, OCR or interpret the file for you — your own AI does that, on your own subscription. Read-only; it changes nothing, emails nobody, and no link it hands out can reach another company. An APPROVED draft honestly reports no original: on approval the file moves onto the posted document, so ask for it there instead.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
idYesThe owner's id — the expenseId from search_expenses for 'expense', otherwise the draftId a create_*_draft or revise_draft call returned.
ownerYesWhat the original hangs off: 'expense' = a POSTED paid expense (use the expenseId from search_expenses); 'expense_draft' / 'invoice_draft' / 'bill_draft' / 'quote_draft' / 'receipt_draft' / 'payment_draft' / 'contact_draft' = a PENDING draft (use its draftId); 'shoebox' = a photo someone in the business sent in from their phone and nobody has read yet (use the id from shoebox_items).
attachmentIdNoWhich file, when a posted expense carries more than one — the `attachmentId` from that expense's `attachments` list in search_expenses. Omit for a draft (a draft carries at most one original), and omit for an expense with exactly one file.

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. Changed2 schema fields changed
    • changedInput schema / properties / owner / description
      Previous value: -"What the original hangs off: 'expense' = a POSTED paid expense (use the expenseId from search_expenses); 'expense_draft' / 'invoice_draft' / 'bill_draft' / 'quote_draft' / 'receipt_draft' / 'contact_draft' = a PENDING draft (use its draftId); 'shoebox' = a photo someone in the business sent in from their phone and nobody has read yet (use the id from shoebox_items)."New value: +"What the original hangs off: 'expense' = a POSTED paid expense (use the expenseId from search_expenses); 'expense_draft' / 'invoice_draft' / 'bill_draft' / 'quote_draft' / 'receipt_draft' / 'payment_draft' / 'contact_draft' = a PENDING draft (use its draftId); 'shoebox' = a photo someone in the business sent in from their phone and nobody has read yet (use the id from shoebox_items)."
    • changedInput schema / properties / owner / enum
      Previous value: -[
-  "expense",
-  "invoice",
-  "credit_note",
-  "bill",
-  "quote",
-  "expense_draft",
-  "invoice_draft",
-  "bill_draft",
-  "quote_draft",
-  "receipt_draft",
-  "contact_draft",
-  "journal_draft",
-  "shoebox"
-]New value: +[
+  "expense",
+  "invoice",
+  "credit_note",
+  "bill",
+  "quote",
+  "expense_draft",
+  "invoice_draft",
+  "bill_draft",
+  "quote_draft",
+  "receipt_draft",
+  "payment_draft",
+  "contact_draft",
+  "journal_draft",
+  "shoebox"
+]
  2. Changed2 schema fields changed
    • changedInput schema / properties / owner / description
      Previous value: -"What the original hangs off: 'expense' = a POSTED paid expense (use the expenseId from search_expenses); 'expense_draft' / 'invoice_draft' / 'bill_draft' / 'quote_draft' / 'receipt_draft' / 'contact_draft' = a PENDING draft (use its draftId)."New value: +"What the original hangs off: 'expense' = a POSTED paid expense (use the expenseId from search_expenses); 'expense_draft' / 'invoice_draft' / 'bill_draft' / 'quote_draft' / 'receipt_draft' / 'contact_draft' = a PENDING draft (use its draftId); 'shoebox' = a photo someone in the business sent in from their phone and nobody has read yet (use the id from shoebox_items)."
    • changedInput schema / properties / owner / enum
      Previous value: -[
-  "expense",
-  "invoice",
-  "credit_note",
-  "bill",
-  "quote",
-  "expense_draft",
-  "invoice_draft",
-  "bill_draft",
-  "quote_draft",
-  "receipt_draft",
-  "contact_draft",
-  "journal_draft"
-]New value: +[
+  "expense",
+  "invoice",
+  "credit_note",
+  "bill",
+  "quote",
+  "expense_draft",
+  "invoice_draft",
+  "bill_draft",
+  "quote_draft",
+  "receipt_draft",
+  "contact_draft",
+  "journal_draft",
+  "shoebox"
+]
  3. Changed1 schema field changed
    • changedInput schema / properties / owner / enum
      Previous value: -[
-  "expense",
-  "invoice",
-  "credit_note",
-  "bill",
-  "quote",
-  "expense_draft",
-  "invoice_draft",
-  "bill_draft",
-  "quote_draft",
-  "receipt_draft",
-  "contact_draft"
-]New value: +[
+  "expense",
+  "invoice",
+  "credit_note",
+  "bill",
+  "quote",
+  "expense_draft",
+  "invoice_draft",
+  "bill_draft",
+  "quote_draft",
+  "receipt_draft",
+  "contact_draft",
+  "journal_draft"
+]
  4. First observed

TDQS

A4.9/5.0
Behavior5/5

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

Beyond the readOnlyHint annotation, the description discloses the signed URL expiry and sharing properties, that bytes are never inlined (with token-cost rationale), that Taokeh does not OCR or interpret the file, and that the operation has no side effects. It also confirms there is no contradiction with the annotation.

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 core purpose and usage are front-loaded, and each sentence carries real information. The description is somewhat long for a simple read-only link tool, with a few rhetorical embellishments, but the length is justified by the many owner varieties and edge cases.

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?

With no output schema, the description fully covers the return contract (signed URL, filename, media type, size, no inline bytes), security posture, owner/draft edge cases, and read-only behavior. An agent has all information needed to call it correctly and interpret the result.

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 schema coverage is 100%, the description adds crucial semantic detail: how to obtain the owner/id values from prior tool results, when attachmentId must be supplied, and when it must be omitted. This goes well beyond the schema's enum and type descriptions.

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 the tool gets a short-lived link to the ORIGINAL DOCUMENT filed against an expense or draft, which is a precise verb+resource. It also clarifies what counts as a document in each state, distinguishing the lookup target from other operations like get_document_pdf.

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 when to use it ('CHECK a document is on file, or re-read one you filed earlier'), where to find the required ids (search_expenses and create_*_draft/revise_draft results), and when not to ('An APPROVED draft honestly reports no original... ask for it there instead'). This is clear routing guidance with no reliance on inference.

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

All Taokeh MCP server toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources