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.

Schema Changelog

Changes observed during successful MCP inspections.

  1. 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"
+}
  2. First observed

TDQS

A4.9/5.0
Behavior5/5

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

Annotations are all false, so the description carries the full burden. It discloses that the image is REQUIRED or the draft is refused, that approval is by the owner, that truncated base64 is rejected via attachmentBytes, that bad type/oversize files are rejected with nothing filed, and that attachmentToken and attachmentBase64 are mutually exclusive. No contradiction with 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?

The description is long but front-loaded with the core purpose and workflow. Some redundancy (e.g., honesty warning appears in both description and schema) slightly bloats it, but the density of operational guidance justifies the length for a 16-parameter tool.

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-param write tool with no output schema and minimal annotations, the description covers the full invocation workflow: reading the card, field extraction, honesty rules, attachment paths, partyKind/partyName, and post-call reporting. Nothing essential for correct invocation appears to be missing.

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?

Even with 100% schema coverage, the description adds critical meaning: the image is required despite not being in the schema's 'required' list, the token/base64 exclusivity, and why attachmentBytes should accompany base64. It also clarifies partyName and needsReview semantics beyond their schema entries.

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 a specific verb ('File a pending CONTACT draft') and resource ('from a business card YOU have read'), and explicitly distinguishes itself from adding to the address book. It names the draft role and the sibling domain (create_*_draft, update_contact_draft) implicitly via the workflow, making its purpose unambiguous.

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?

Provides explicit when-to-use ('after reading a card image yourself'), what not to do ('does NOT add anyone to the address book'), and alternative routing for large photos/PDFs via request_attachment_upload → PUT → attachmentToken instead of inline base64. Also instructs to report fields back to the user so misreads are caught before approval.

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