Skip to main content
Glama

attach_file

Attach any file to a note (saved in the branch's attachments/; a Markdown reference is appended unless link=false). Give ONE of: data base64 (only for small files, up to ~3 MB), url fetched server-side (up to 25 MB), or neither: you get an upload link for the user (one tap, works everywhere) and a signed PUT URL for you. For a file the user gave you in the chat, call it with neither.

Input Schema

NameRequiredDescriptionDefault
urlNo
dataNo
linkNo
nameYesWith extension
pathYesNote or folder
confirmNo
workspaceNoUsually OMIT: the path finds its brain. Pass it only when a reply asks (new or ambiguous branch), with the brain the user named (if unclear ASK): id, 'mine', or owner name/email. A brain where the branch does not exist is refused.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed7 schema fields changed
    • removedInput schema / properties / confirm / description
      Removed value: -"Second step of the direct upload: the bytes are on R2, register them"
    • removedInput schema / properties / data / description
      Removed value: -"Base64 content (a data: URL prefix is fine)"
    • removedInput schema / properties / link / description
      Removed value: -"Append the reference to the note (default true when path is a note)"
    • changedInput schema / properties / name / description
      Previous value: -"File name with extension (accents and spaces are normalized)"New value: +"With extension"
    • changedInput schema / properties / path / description
      Previous value: -"The note (…/nota.md) the file belongs to, or a folder"New value: +"Note or folder"
    • removedInput schema / properties / url / description
      Removed value: -"Public http(s) URL to fetch"
    • changedInput schema / properties / workspace / description
      Previous value: -"Brain to act on: its id, «mio» (yours), or the owner's name/email as shown by search. Usually OMIT it: a path that already lives in one brain is found there, for reads and writes alike. Pass it only when the tool tells you to (a NEW branch, or one that exists in several brains) — with the brain the user named; when they were not explicit ASK THEM. A brain where the branch does not exist is refused even if you name it."New value: +"Usually OMIT: the path finds its brain. Pass it only when a reply asks (new or ambiguous branch), with the brain the user named (if unclear ASK): id, 'mine', or owner name/email. A brain where the branch does not exist is refused."
  2. First observed

TDQS

A3.9/5.0
Behavior4/5

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

Adds substantive context beyond the annotations: storage location, the appended Markdown reference with its `link=false` opt-out, and explicit size ceilings (~3 MB for base64 data, 25 MB for server-side URL fetch). The two-step outcome for the 'neither' path (user upload link + signed PUT URL) is spelled out. Not a 5 because `confirm` and the refusal/error behavior for oversized input go unmentioned.

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 core action and storage consequence, then the parameter decision rule. Dense but every clause carries operational meaning; the nested parentheticals make it slightly 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 7-parameter mutation tool with no output schema, the description covers the storage side effects, size constraints, and the alternate upload flow well. Remaining gaps are `confirm`'s role and the note-vs-folder meaning of `path`, which matter but are secondary.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is only 43%, and the description does compensate for the two most important optional params (`data`, `url`) with size limits and mutual exclusivity, plus `link`. But `confirm` is undocumented in both description and schema, and `path` (note vs folder) and `name` are left entirely to terse schema text.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource ('Attach any file to a note') and immediately adds the side effect (stored under the branch's `attachments/`, Markdown reference appended). It doesn't explicitly contrast with the nearby `append_file`/`write_file` siblings, so an agent must infer the boundary, but the resource and outcome are unambiguous.

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 clear decision rule for the three input modes ('Give ONE of: data ... url ... or neither') plus a concrete triggering case: 'For a file the user gave you in the chat, call it with neither.' What's missing is any exclusion against sibling tools that also write files.

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