Skip to main content
Glama

Create upload link

create_upload_link

Get a link where the USER uploads documents (Word, PDF, Excel, PowerPoint, anything) to keep with a database. Use this whenever a file should be stored in Azquo - NEVER base64 a file into a tool call. Give the user the url; they open it in a browser and drop the files. The server keeps each original (downloadable later) and makes a Markdown copy of Word/PDF/Excel/PowerPoint/HTML/text for you to read with read_document. Pass nameId to attach them to a name, typically a Meta info note: each upload adds a short attribute DOCUMENT to it (IMAGE for a png/jpg/gif/webp/bmp picture) - the file itself is never put in the name. The link lasts 30 minutes and takes any number of files. Afterwards call list_documents to see what arrived.

FILES YOU MADE YOURSELF (e.g. a .docx built in your code sandbox): do not make the user download and re-upload them. If your sandbox can reach this server, POST them straight to the link with the returned curlCommand (multipart, one -F files=@... per file); the reply is JSON with each document's id. The link is the only credential - no API key. If the request cannot connect, the sandbox's network access does not include this server: tell the user it can be allowed in Claude.ai's code-execution network settings, and meanwhile give them the url.

Input Schema

NameRequiredDescriptionDefault
noteNoOptional: a line shown on the upload page saying what to upload, e.g. "The signed contract for Acme"
nameIdNoOptional: id of the name (e.g. a Meta info note) to attach the documents to
businessNoOptional. The business this call is for, by name, e.g. "azquo" - it then runs there whatever business the session is in. Worth giving on writes when you work in more than one business: a new MCP session starts in the login's own business. list_businesses shows the names.
databaseYesDatabase the documents belong to

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / business
      Added value: +{
      +  "description": "Optional. The business this call is for, by name, e.g. \"azquo\" - it then runs there whatever business the session is in. Worth giving on writes when you work in more than one business: a new MCP session starts in the login's own business. list_businesses shows the names.",
      +  "type": "string"
      +}
  2. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations only declare the mutation/read hints; the description adds materially more: the link lasts 30 minutes, accepts any number of files, the server keeps the original plus a Markdown copy readable via read_document, the link itself is the only credential (no API key), and the sandbox network-access failure mode. This covers expiration, auth model, and side effects beyond what annotations provide.

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, then the self-made-files branch and fallback. It is dense and long for a 4-param tool, with a few clauses that could be tightened, but nearly every sentence carries operational value (credential model, expiry, network caveat) so little is padding.

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 compensates by describing what the link returns (curlCommand), what the JSON reply contains (document ids), and the follow-up step (list_documents). Combined with the expiration and credential details, an agent has everything needed to call and act on this tool.

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 schema documents all four params, giving a baseline of 3. The description goes further by explaining the effect of nameId (each upload appends a short DOCUMENT <id>/IMAGE <id> attribute and never stores the file in the name), which is semantics the schema does not convey. It does not elaborate on note or business beyond the schema wording.

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?

States a specific verb+resource: it produces a link where the USER uploads documents into Azquo. It also names the alternate flows (import_file/import_from_url are implied avoided routes) and immediately clarifies the return artifact (a link the user opens in a browser). An agent can distinguish this from sibling import tools without reading 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 'Use this whenever a file should be stored in Azquo - NEVER base64 a file into a tool call', plus a dedicated branch for self-made files (POST via curlCommand instead of re-upload) and a follow-up instruction (call list_documents afterwards). Both when-to-use cases and the exclusion (never base64) are stated.

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