Skip to main content
Glama
rtdesignstudio

cemainou

by rtdesignstudio
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Remote

Add Attachment Tool

add_attachment

Attach links or files (HTML, images, PDFs) to a project or task, replace outdated versions in one step, and optionally share deliverables with the client.

Instructions

Attaches to a project a link (Figma, Drive, Behance: pass url and title) or a file (an HTML presentation, an image, a PDF: pass filename, plus text for a text file or base64 for a binary one; up to 10 MB through the conversation). For a file that is already online (a public image, a PDF, a Google Drive file shared with anyone who has the link), pass source_url instead: cemainou downloads it itself, so a large screenshot does not have to travel through the conversation. Colleagues open it from the project page; HTML opens isolated from the app. With client_visible, the project's client sees it too (a deliverable, a final PDF), only when the person asks for that. When a task file changed, pass replaces with its id: the new version takes its place instead of piling up. Only when the person asks or agrees. Never secrets or files with credentials. Limits per file: 10 MB as text or base64, 20 MB with source_url. For a larger file, or any file on this machine when you have a shell, use upload_link: it gives an upload command (curl), up to 20 MB per file, nothing through the conversation.

Input Schema

NameRequiredDescriptionDefault
urlNoFor a link: the address (https://...).
repoNoThe git remotes of the working directory (git remote -v).
roleNoWhat it is, when clear: demo (a live demo or prototype: pinned at the top of the project and on its card), brief, design (mockups), presentation, document, contract (contracts, invoices, papers), source (source files), media (photos, video).
taskNoA task number, to attach it to that task (e.g. a screenshot for a bug) instead of the project.
textNoThe content of a text file (HTML, Markdown, SVG, CSV, TXT).
titleNoWhat it is, e.g. "Presentation for the client". Required for a link; for a file, the name is used if left out.
base64NoThe content of a binary file (PNG, JPG, PDF), base64-encoded.
projectNoProject slug or name, if not this session's.
sessionNoThis session's id, from the cemainou line at the start of the session. The session's project wins over the repo.
filenameNoFor a file: its name with the extension, e.g. "presentation.html" or "logo.png".
replacesNoA task file's id (from start_task: those with can_replace): the new file or link takes its place and the old one is removed, in one step. Use it when a file changed, instead of adding one more. Only files you added, only while the task is open.
source_urlNoInstead of text / base64: a public https link to the file (an image, a PDF, a text file; a Google Drive "share" link works if shared with anyone who has the link). cemainou downloads it, up to 10 MB. filename is optional (else from the link).
client_visibleNotrue: the project's client sees it too (only on a project visible to its client, only when the person asks). Not for task files.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.2/5.0
Behavior3/5

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

No annotations exist, so the description carries the full burden. It discloses size limits (10 MB inline, 20 MB via source_url), that HTML renders isolated from the app, that replaces deletes the old file in one step, and a confidentiality warning — solid coverage. However it never says what is returned (an id? a url?) or what happens on failure, and it is a mutation tool with zero annotation backstop.

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 and mostly purposeful, but the size limits are restated (10 MB in the file sentence, again in the limits sentence, again for upload_link) and 'only when the person asks' appears twice, making the paragraph feel padded and harder to scan than it needs to be.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 13-parameter, all-optional tool with no output schema, the description covers the decision tree well. The one real gap is the return value — an agent doesn't know whether it gets back an id it can later pass to replaces, which matters given replaces is central to the workflow.

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%, so the baseline is 3; the description earns extra by explaining the interactions the schema can't: source_url as a substitute for text/base64, replaces requiring an id from start_task and only working on open tasks, and client_visible not applying to task files.

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 (attaches a link or file to a project) and immediately enumerates the three intake modes: url+title for links, filename+text/base64 for files, source_url for remote files. An agent can tell it apart from upload_link, which is named as the alternative.

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?

Explicit routing rules: which params to use per case (link vs file vs online file), when to use replaces instead of adding, when to set client_visible ('only when the person asks'), when not to use it at all (larger file → upload_link, secrets → never). Both alternatives and exclusions are named.

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

Deploy Server

Other Tools