goldseam

Mail My Bio

mail_my_bio

The bio builder: mail the person, as a Word (.docx) document that Word, Google Docs and Pages open, the resume, CV, profile or portfolio written from their Selfie. resume: one or two pages for an application (a summary, experience, education and training, and skills). cv: the full record (education, work, training, service, projects and life experiences). profile: a short profile to share with an advisor, an employer or online (a headline, an about paragraph and strengths). portfolio: the written portfolio and summary to share with others (a summary in plain words, the statements by grouping with what each came from and its supporting evidence, then the interests and possibilities explored). Write it from show_me_my_selfie's answer and the person's own words, mark proposed statements as proposed, and show it in the chat for them to review and change first. Call this only on the person's own yes, to the address they type in the chat, with their words asking for it as person_consent. The document is the title, then the sections in order; with selfie_coding true it adds a closing Selfie coding section read from the package (each statement not set aside under its KSA grouping, with its KSA Dictionary connection and its affirmation, proposed ones marked proposed); every document closes with the Selfie's distinctions (the person's own words and affirmations; supporting evidence supports, it does not verify; no third-party verification; nothing in it is a qualification or a score). It is sent through GoldSeam's one mail service: GoldSeam keeps no copy of the document, and the service's mail log records the address, the kind and the document's size, never the document. The first time an address is used, the service emails it a confirmation link first and this answers status waiting_for_confirmation; nothing is mailed to that address until the person opens the link, then call again with the same document. Over a daily limit it answers needs_attention mail_refused with the reason. With no mail setting on the server it answers needs_attention mail_not_configured and sends nothing: give the person the document in the chat.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "package": "<package>"
    },
    "name": "mail_my_bio"
  }
}

Input Schema

Name	Required	Description
`kind`	No
`email`	No	The address the person typed in the chat
`title`	No	The name or headline the person gave; the document's title
`package`	Yes	The package the last GoldSeam Selfie answer returned (goldribbon_package_v1 with its selfie_interview part). Keep it for the person and send it back whole; GoldSeam keeps no copy.
`sections`	No	The document as the person approved it in the chat, in order
`selfie_coding`	No	Add the person's Selfie coding (the KSA groupings and KSA Dictionary connections) as a closing section, when they asked for it
`person_consent`	No	The person's own words asking for it to be mailed

Output Schema

Name	Required	Description
`limits`	No	What this answer could not do, each { code, statement }
`status`	No	What happened, or needs_attention with a problem
`package`	No	The person's package with the interview; absent when the call could not use it
`problem`	No	When status is needs_attention: code, statement, what_to_do
`contract`	Yes
`document`	No	What was mailed: kind, filename, bytes, sha256
`statement`	Yes
`next_actions`	No

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 4, 2026

TDQS

A4.5/5.0

Behavior5/5

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

Goes well beyond the annotations (readOnly=false, destructive=false, openWorld=true) with real operational detail: GoldSeam keeps no copy, the mail log records only address/kind/size, first use of an address triggers a confirmation link returning waiting_for_confirmation, rate limiting returns needs_attention mail_refused, and missing configuration returns mail_not_configured with nothing sent. It also discloses what the generated document contains, section by section, including the mandatory closing distinctions paragraph.

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?

Front-loaded with purpose and the consent rule, which is correct ordering, but the body is three enormous run-on sentences carrying nested parentheticals and repeated framing ("the bio builder," "the document is," "every document closes with"). Almost every clause carries information, yet the density and lack of paragraph or list structure make it hard to scan for the one rule an agent needs at a given moment.

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 seven-parameter, nested-object, open-world send tool this covers what an agent needs: consent precondition, source package, review step, document composition, all three non-success statuses, and the no-mail fallback. Return values are covered by the output schema and the status codes named in the description.

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 already 86%, so the baseline is 3, and the description earns above that by giving meaning the schema does not: what each kind contains (resume = one to two pages; cv = full record; portfolio = statements with evidence), what selfie_coding adds, and that email must be the address typed in chat. It is dense prose rather than per-parameter, and some mapping must be inferred from context.

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?

Names a specific verb and artifact: "mail the person, as a Word (.docx) document ... the resume, CV, profile or portfolio written from their Selfie." It then defines each of the four document kinds separately, which lets an agent tell resume from cv from profile from portfolio without opening the schema, and it pins the source material to show_me_my_selfie's answer.

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 a hard precondition: "Call this only on the person's own yes, to the address they type in the chat, with their words asking for it as person_consent," plus the review-first step. It also names the fallback when mailing is unavailable ("give the person the document in the chat") and tells the agent to call again after confirmation. It stops short of contrasting itself with sibling tools that produce or show document content.

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

All goldseam 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.