Skip to main content
Glama

Taokeh MCP server

by my.taokeh
OverviewDiscussionsAdmin

File contact draft from a name card

create_contact_draft

File a pending CONTACT draft from a business card YOU have read. Read the card image yourself and pass the fields — personName (required), company, role, phones, emails, address — AND the card image itself, which is REQUIRED: the owner checks your fields against the picture before approving, so a draft without the image cannot be verified and is refused. This does NOT add anyone to the address book: it creates a draft the owner reviews and approves in Taokeh, and only that tap files the contact person (under the company, matched to an existing customer/vendor or created as a new one) with the card image kept on the record. BE HONEST about what you could not read: leave a field EMPTY and say so in notes — never guess a phone digit, an email spelling or a company name. If the photo is blurry, is not a business card, or lists two people, say that in notes and set needsReview. Attach the image with attachmentBase64 + attachmentMediaType (a card photo is usually small enough to inline; send attachmentBytes with it so a truncated base64 is rejected instead of filed), or for a large photo or a PDF use request_attachment_upload → PUT the bytes → pass the returned attachmentToken (never both). Say which side of the book it is with partyKind ('customer' for someone you sell to, 'vendor' for someone you buy from) — default customer — and pass partyName if the user tells you the company is really an existing one under a different spelling. Report the fields back to the user in chat so they can spot a misread before they tap.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
roleNoThe person's job title / role as printed, e.g. 'Sales Manager'.
notesNoA SHORT reviewer note: one or two plain sentences, written in the reviewer's language, flagging what the human should double-check against the image before approving — a phone number you could not read cleanly, two people on one card, uncertainty about which line is the company. The reviewer reads this on a small approval card, so keep it brief and human. Leave it empty when there is nothing to flag.
emailsNoThe email addresses printed on the card (up to 3). Never guess a spelling; leave it out and flag it in notes instead.
phonesNoThe phone numbers printed on the card, as printed (up to 3). Leave out any digit-group you cannot read cleanly and say so in notes — a half-guessed phone number is worse than none.
addressNoThe address printed on the card, as one string.
companyNoThe company name printed on the card. Leave it out if the card does not show one.
partyKindNoWhich side of the book the card belongs to: 'customer' (someone you sell to) or 'vendor' (someone you buy from). Defaults to customer.
partyNameNoThe company to file the contact under, when the user tells you it differs from what is printed on the card (e.g. the card shows a brand but the books use the registered name). Omit to use the company printed on the card — the reviewer can still change it before approving.
personNameYesREQUIRED — the person's name exactly as printed on the card. If the name is genuinely illegible, do NOT guess and do NOT file: tell the user the card is unreadable.
needsReviewNoSet true when something about the card gave you pause — a blurry photo, two people on one card, a field you could not read. It flags the draft for the reviewer.
attachmentBytesNoThe decoded byte size of the ORIGINAL file on disk — send it alongside attachmentBase64 and the server rejects a truncated paste instead of filing a corrupt file.
attachmentTokenNoThe token from request_attachment_upload, AFTER you have PUT the image bytes to its uploadUrl. Use this instead of attachmentBase64 for a large photo or a PDF — it carries the file out-of-band (no base64 in this call). Mutually exclusive with attachmentBase64. The card lands on the created contact on approval, exactly as an inline one does.
attachmentBase64NoThe business-card IMAGE as base64 — REQUIRED (unless you pass attachmentToken). A card photo is normally small enough to inline. A bad type/oversize file is rejected and NOTHING is filed.
attachmentSha256NoThe SHA-256 of the ORIGINAL file as 64 hex chars — optional second check alongside attachmentBase64, so corrupted bytes are rejected instead of filed.
attachmentFilenameNoOptional original filename for the card image, e.g. card.jpg.
attachmentMediaTypeNoThe card image's MIME type, e.g. 'image/jpeg' or 'image/png'. Required when attachmentBase64 is given. It must match the file's bytes — a mismatch is refused and nothing is filed.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / attachmentMediaType / description
      Previous value: -"The card image's MIME type, e.g. 'image/jpeg' or 'image/png'. Required when attachmentBase64 is given."New value: +"The card image's MIME type, e.g. 'image/jpeg' or 'image/png'. Required when attachmentBase64 is given. It must match the file's bytes — a mismatch is refused and nothing is filed."
  2. Changed2 schema fields changed
    • addedInput schema / properties / attachmentBytes
      Added value: +{
+  "description": "The decoded byte size of the ORIGINAL file on disk — send it alongside attachmentBase64 and the server rejects a truncated paste instead of filing a corrupt file.",
+  "exclusiveMinimum": 0,
+  "maximum": 9007199254740991,
+  "type": "integer"
+}
    • addedInput schema / properties / attachmentSha256
      Added value: +{
+  "description": "The SHA-256 of the ORIGINAL file as 64 hex chars — optional second check alongside attachmentBase64, so corrupted bytes are rejected instead of filed.",
+  "type": "string"
+}
  3. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations only declare the safety profile (readOnly=false, destructive=false). The description adds the review/approval flow, that the draft is refused without the image, how truncation and MIME mismatches are rejected, mutual exclusivity of the two attachment paths, and the owner-verification step — substantial context beyond the annotations.

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?

Front-loads the two hard requirements (image required, no address-book write) and is well ordered, but it is a very dense block that repeats some schema guidance (never guess a phone/email, leave empty and flag) rather than purely adding new information.

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 16-parameter, no-output-schema write tool, the description supplies everything an agent needs: the required input, both attachment routes, the refusal conditions, the honesty/notes policy, and the downstream review consequence. Nothing material 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% and the schema already documents most fields, so the baseline is 3; the description earns extra credit by explaining cross-parameter flow the schema cannot (attachmentBytes guards against truncated base64, attachmentToken must be used after the PUT, never both, partyName overrides printed company).

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?

States a specific verb+resource ('File a pending CONTACT draft from a business card') and explicitly distinguishes itself from the address-book mutation it is not ('This does NOT add anyone to the address book'), which separates it from update_contact_draft and the other create_*_draft siblings.

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?

Gives explicit when-to-use conditions (agent has read the card, image mandatory), the two mutually exclusive attach paths (inline base64 vs request_attachment_upload → PUT → attachmentToken), defaulting rules for partyKind, and when to leave fields empty. Nothing is left to 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
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