Skip to main content
Glama

Typebar (formerly SuperDocs)

by app.superdocs
OverviewDiscussionsAdmin

upload_document_base64

Parses the file into structured HTML where every paragraph, heading, table, row, and cell has a unique chunk ID, enabling the AI to make targeted structural edits via chat ("remove row 3 of the pricing table" works). Tables, borders, shading, alternating row colors, fonts, and inline styling are preserved on edit and export. Also works for AI-generated content: if you've drafted an outline or partial document in your context, upload it here as the working doc, then use chat to fill in the rest. This is also the reliable way to REPLACE a session's document with exact content you already hold — the upload is a verbatim load, so it can never come back paraphrased or placeholder-shaped the way asking chat to re-type it can. When you pass a session_id the response is compact by default (metadata only — pass return_html=true for the full parsed HTML); the document is loaded into the session and you edit it via chat. For files >100KB, prefer request_upload_url (pre-signed URL flow) to avoid token bloat from base64 through the agent context. Supported formats: .pdf, .docx, .txt, .rtf, .md, .html, .htm, .tex (plus .zip LaTeX project archives). Max 50 MB validated; note the hosted transport layer caps any REQUEST BODY at ~32 MB and rejects larger ones at the gateway with an HTML (not JSON) error — base64 inflates content ~33%, so inline uploads are reliable up to ~20 MB of file bytes; beyond that use request_upload_url (pre-signed flow, up to 100 MB).

Input Schema

NameRequiredDescriptionDefault
filenameYesOriginal filename with extension (e.g. 'contract.pdf'). Used for file type detection.
session_idNoSession ID. Auto-generated if not provided.
file_base64YesBase64-encoded file content.
return_htmlNoWith a session_id: false (default) returns compact metadata only (chunks_count, version_id, page_setup) — the document is loaded into the session and you edit it via chat, keeping your context small; true returns the full parsed HTML inline. Ignored on the convert-only path (no session_id), which always returns the converted html.
authorizationNo

Schema Changelog

Changes observed during successful MCP inspections.

No schema history has been recorded yet.

TDQS

A4.8/5.0
Behavior5/5

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

With no annotations, the description carries the full burden and does so richly: it discloses compact-by-default responses when session_id is passed, the verbatim (never paraphrased) load semantics, the 50 MB validation cap, the ~32 MB transport body cap with a non-JSON HTML error at the gateway, and the ~33% base64 inflation. It also explains the convert-only path behavior.

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 core purpose is front-loaded in the first sentence, and each later clause adds distinct value (editing, seeding, verbatim replace, size limits). It is dense and slightly repetitive on size thresholds, but no sentence is pure filler.

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 5-parameter tool lacking an output schema and annotations, the description supplies everything needed: response shape (compact metadata vs full HTML), session behavior, supported formats, and layered size limits with the correct fallback. Nothing required to call it correctly is missing.

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 80%, so baseline is 3, but the description meaningfully adds to it: it explains that return_html is only meaningful with session_id and ignored otherwise, and that session_id loads the doc for chat-based editing. It does not add much on filename/base64/authorization, hence not a 5.

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 opening sentence states a specific verb and resource (parses an uploaded file into structured HTML with unique chunk IDs) and immediately contrasts with alternatives like request_upload_url and the chat-editing workflow. An agent can distinguish this from sibling upload tools (upload_attachment_base64, upload_image_base64, upload_template_base64) without opening any schema.

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 are given: use request_upload_url for files >100KB or beyond ~20 MB inline, use chat to make targeted edits once loaded, use this tool to verbatim-replace a session document, and use it to seed AI-drafted content. Conditions and alternatives are named, not left to inference.

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

All Typebar (formerly SuperDocs) toolsInspect
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.

Resources