Taokeh MCP server

Request attachment upload

request_attachment_upload

Get a one-time link to upload a receipt/bill/statement/document that is too large to inline as attachmentBase64 (a real photo or a multi-page PDF — base64 inside a tool call is very costly). Returns an uploadUrl and an attachmentToken: PUT the file's RAW bytes to uploadUrl within the time limit, then pass attachmentToken IN PLACE OF attachmentBase64 to create_expense_draft / create_invoice_draft / create_bill_draft / create_quote_draft / create_receipt_draft / create_contact_draft / create_journal_draft — the file rides that draft and lands on the posted document on approval, exactly as an inline attachment does — or to import_bank_statement, which archives it as the statement's original. CALL THIS FIRST, BEFORE the create/import call: filing bare and adding the file after is the harder path. If you DID already file bare, the repair on the five document lanes (expense, invoice, bill, quote, receipt) is to call the same create tool AGAIN with the IDENTICAL reference + date + amount plus attachmentToken — while the draft is still pending the file is ADOPTED onto it (the result says duplicateAttachment:'added') and no second draft is created; the same repair works on import_bank_statement with the identical account, balances and rows. The link is single-use, expires quickly, and works only for this company. Use this for anything bigger than a few KB; keep attachmentBase64 for tiny files only. If the PUT is blocked (403) from a sandbox such as Claude Cowork, the user's Claude network allowlist is refusing taokeh.my: tell them to add taokeh.my under Settings → Capabilities → Allow network egress and start a new task, and meanwhile send the file inline as attachmentBase64.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "request_attachment_upload"
  }
}

Input Schema

Name	Required	Description	Default
`filename`	No	Optional original filename, e.g. receipt.jpg — travels with the upload and shows on the review card.
`mediaType`	No	Optional hint of the file's MIME type, e.g. 'image/jpeg'. Advisory only — the server determines the real type from the file's own bytes (magic bytes), so a wrong hint changes nothing.

Schema Changelog

Changes observed during successful MCP inspections.

First observedAug 9, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations only say it is a non-read-only, non-destructive, non-idempotent call; the description adds far more: the link is single-use, expires quickly, is company-scoped, requires a raw-bytes PUT, returns uploadUrl plus attachmentToken, and how duplicateAttachment:'added' adoption behaves on retry. It even documents a concrete failure mode (403 from a sandboxed client) with remediation.

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 purpose and the returned artifacts are front-loaded and every sentence carries operational information. However it is delivered as one long run-on block with heavy em-dashes and shouting capitals, making the repair path and the 403 workaround harder to scan than a short enumerated structure would be.

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?

There is no output schema, and the description compensates by naming the two returned values and describing the required follow-up PUT. It also covers the full lifecycle (request, upload, attach, repair-on-retry) that an agent needs to complete this two-step flow, which is unusually complete for a two-parameter tool.

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

Parameters3/5

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

Schema coverage is 100% and both optional parameters (filename, mediaType) are fully documented in the schema, so the baseline is 3. The description adds no detail on these two parameters and instead spends its text on the returned token and downstream flow, which is a schema-independent concern.

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 opens with a specific verb and resource — 'Get a one-time link to upload a receipt/bill/statement/document' — and immediately distinguishes the tool from the inline alternative (attachmentBase64). It also names the exact downstream consumers (create_expense_draft, import_bank_statement, etc.), so the agent can separate it from every sibling create/import tool.

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 gives explicit when-to-use ('anything bigger than a few KB'), an explicit when-not ('keep attachmentBase64 for tiny files only'), a required call ordering ('CALL THIS FIRST, BEFORE the create/import call'), and a fallback repair path for each affected lane. Alternatives and exclusions are both stated, not inferred.

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 tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?