Skip to main content
Glama

RelayLink

Save a document from text

attachment_create_text
Idempotent

Save text as a private document the user can attach to a briefing: a .md or .txt filename and up to 131,072 bytes of UTF-8 per call (bytes, not characters). For longer text, decide partCount before sending anything — up to 8 parts of at most 131,072 bytes each covers the full 1,048,576-byte cap — split at line breaks, never inside a word, and send every part with the same idempotencyKey, filename and partCount, part numbered from 1. The parts are joined exactly as sent, in part order, with nothing added between them, so keep the line break at the end of every part but the last; the part count cannot change once a part is saved. Text mostly in a script other than Latin, or in emoji, goes in parts of half that size: some clients escape those characters, and a part that grows past the request limit on the way never arrives. Saves privately and shares nothing by itself — draft_package's attachmentVersionIds is what attaches it to a briefing, and the user's own approval at confirm_send is what sends it. Pass the same idempotencyKey on a retry to avoid saving twice.

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": {
      "filename": "<filename>",
      "text": "<text>"
    },
    "name": "attachment_create_text"
  }
}

Input Schema

NameRequiredDescriptionDefault
partNoThis part's number, from 1 to partCount. Omit for a single-call document.
textYesThis part's text, in the user's own words where they gave them.
titleNoA short title for the document. Defaults to the filename.
filenameYesThe filename, ending .md or .txt.
partCountNoHow many parts this document is split into. Omit, or pass 1, for a single call.
idempotencyKeyNoA key of your own choosing; the same key with the same content returns the same document instead of saving again. Required once partCount is more than 1.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.9/5.0
Behavior5/5

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

Annotations already declare idempotentHint=true and destructiveHint=false, but the description goes well beyond them: it explains the 1,048,576-byte overall cap, the 8-part maximum, immutability of partCount once a part is saved, exact concatenation semantics with no separator injected, the non-Latin/emoji half-size hazard from client-side escaping, and what idempotencyKey actually does on retry. These are non-obvious failure modes an agent could not recover from by reading the schema alone.

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-loaded with the primary constraint and ordered by decision sequence: single call, then splitting, then attachment, then retry. It is dense but nearly every sentence carries a constraint that would cause a failed save if dropped; only the closing idempotency sentence mildly overlaps the earlier parts discussion.

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?

No output schema exists, and the description covers what the agent needs: the saved document is private, inert until referenced by draft_package, and a repeated idempotencyKey returns the same document instead of duplicating. Combined with the explicit part-splitting protocol, nothing required for a correct first invocation is 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?

Schema coverage is 100%, so the baseline is 3, but the description adds genuine meaning the schema lacks: limits are measured in UTF-8 bytes rather than characters, parts are numbered from 1, and every part must carry the same idempotencyKey, filename and partCount. The requirement that idempotencyKey becomes mandatory once partCount exceeds 1 is stated operationally, not just declared.

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?

Opens with a specific verb and resource: save text as a private document, constrained to .md or .txt. It immediately distinguishes itself from file-based siblings (attachment_upload_link, attachment_manage) by saying it starts from text the user supplies.

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 states the single-call limit, tells the agent to decide partCount before sending anything for longer text, and explicitly names draft_package's attachmentVersionIds as the mechanism that attaches the document and confirm_send as the delivery step. The exclusion ('shares nothing by itself') is stated up front rather than left to inference.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources