Skip to main content
Glama

add_wiki_attachment

Attach a file to a wiki page, identified by 'pageId' or by 'spaceKey' + 'title': pass its bytes as 'contentBase64', or its content as 'text' when the file is text. Re-attaching a filename the page already has replaces its bytes and bumps its version, as the wiki does everywhere else, so retrying this call cannot leave two copies. A file on the person's own disk — a screenshot, a PDF — is better attached by path through the pm-files MCP server than typed out as base64; local_files_setup says how to connect it. An attached file is not on the page until the body references it — the answer hands you the Markdown to add with update_wiki_page. An image may also carry a dark-theme version, attached as the same name with '-dark' before the extension (diagram.svg + diagram-dark.svg); the body still references the plain name. Requires permission to edit the page.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
textNoThe file's content as text, stored as UTF-8 — for a log, CSV or Markdown file you are writing here. Alternative to 'contentBase64'; passing both is refused.
titleNoExact page title, when identifying the page by title.
pageIdNoPage id (as returned by search_wiki).
commentNoShort note about this upload, shown in the page's attachment list.
filenameYesFile name to store, e.g. 'diagram.png'. Any directory part is dropped.
mimeTypeNoContent type to record for the listing, e.g. 'text/csv'. Ignored when the bytes identify themselves, and never used to serve the file.
spaceKeyNoSpace key, when identifying the page by title.
contentBase64NoThe file's bytes, base64-encoded (a 'data:…;base64,…' URL is accepted and unwrapped). Use 'text' instead when the file is text.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.4/5.0
Behavior5/5

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

With no annotations provided, the description carries full behavioral burden and does so thoroughly: re-attaching replaces bytes and bumps version, retries cannot duplicate, the attachment is not on the page until referenced, the response supplies Markdown for update_wiki_page, and dark-theme naming is explained. This is rich, non-obvious behavior disclosure.

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 longer than average but every sentence earns its place: identification, content modes, idempotency, local-file routing, page-reference requirement, dark-theme pairing, and permissions. It is front-loaded with the core action and identifier options before behavioral caveats.

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 complex 8-parameter tool with no annotations and no output schema, the description is complete. It covers how to identify the page, how to supply content, what happens on re-attach, what the response provides, dark-theme conventions, and permissions. Nothing an agent needs to invoke it correctly is missing.

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 description coverage is 100%, so the baseline is 3. The description largely restates what the schema already documents about 'text' vs 'contentBase64', 'filename' directory stripping, and 'mimeType' being ignored when bytes self-identify. It adds no meaningful parameter semantics beyond the schema, which is acceptable given full coverage.

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 opens with a specific verb and resource: "Attach a file to a wiki page," and immediately clarifies page identification via 'pageId' or 'spaceKey' + 'title'. It also distinguishes content delivery modes (base64 vs text), making the tool's scope unmistakable even alongside the sibling add_attachment.

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?

The description gives explicit usage guidance: use 'text' for text files, use 'contentBase64' for bytes, and route local on-disk files to the pm-files MCP server instead. It also notes the permission requirement. It does not explicitly contrast this tool with the sibling add_attachment, but the context is otherwise clear.

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