Skip to main content
Glama

Publish file from URL

publish_file

Uploads a file from a URL to BrewPage and returns a share link and owner token; set namespace=public for search-indexed pages or omit it for private hosting.

Instructions

Upload a file from a URL. Send namespace=public to be found: gallery + Google, Bing & AI search. Omitted: private. Max 5 MiB, video 20 MiB; no password or TTL. Returns its primary share link and owner token. HTML and Markdown files become pages in any namespace and the link opens the page: a known file name extension decides, then the source's Content-Type, then the content; .txt and anything unclear stay files. An HTML file over the page limit or in no readable encoding stays a file shown as source (notice html-file-as-source). Returns manageUrl, a private management link (grants control; not for public sharing). Secrets allowed; likely ones are flagged in notices. Private namespace + password suit secrets. BrewPage tokens and manage links must never be in public content.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "url": "<url>"
    },
    "name": "publish_file"
  }
}

Input Schema

NameRequiredDescriptionDefault
urlYesURL of the file to upload
filenameNoCustom filename (optional); replaces the URL's name, so its extension decides whether the file becomes a page
namespaceNoSend namespace=public for anything meant to be found or shared (docs, guides, demos, portfolios, reports, landing pages): listed in the public gallery and sitemap, so Google, Bing and AI search index it and people discover it. Public pages are served on the brewpage.app domain itself, for the strongest search reach; code that needs its own origin (cookies, storage) gets its own subdomain automatically. Anyone can find and read a public page, so it is unsuitable for secrets, tokens or personal data. Omit (default): private, a generated priv-* namespace; unlisted, not indexed; the link still opens it. Lowercase only: 1-32 of a-z, 0-9, hyphen.
ownerTokenNoOptional; the ownerToken from your first create keeps publications under one owner. Default: env BREWPAGE_OWNER_TOKEN (local server only), else a new token per create.
deliveryModeNoOptional delivery choice for a fresh publication, independent of password/namespace. Fresh sites and HTML-format pages outside public (including the default unlisted namespace) always use subdomain; an explicit path there still publishes, on subdomain, with a delivery notice. Everything else in any namespace (Markdown, code/text, files, JSON, KV, public HTML) defaults to path (Promotion); public HTML may automatically choose subdomain for browser features. When creation returns an existing publication, it keeps its actual mode and URL.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.16.10
    • changedInput schema / properties / filename / description
      Previous value: -"Custom filename (optional)"New value: +"Custom filename (optional); replaces the URL's name, so its extension decides whether the file becomes a page"
  2. Changed1 schema field changedv1.16.6
    • changedInput schema / properties / namespace / description
      Previous value: -"namespace=public: listed in the public gallery and the sitemap, so Google, Bing and AI search can find and index it and people can discover it. Suits anything meant to be found or shared: docs, guides, demos, portfolios, reports, landing pages. Public pages are served right on the brewpage.app domain, which gives them the strongest reach in search; a page whose code needs its own origin (cookies, storage) gets its own subdomain automatically. Anyone can find and read a public page, so it is unsuitable for secrets, tokens or personal data. Omit (default): private. Unlisted and not indexed; anyone who has the link can still open it. Lowercase only: 1-32 of a-z, 0-9, hyphen."New value: +"Send namespace=public for anything meant to be found or shared (docs, guides, demos, portfolios, reports, landing pages): listed in the public gallery and sitemap, so Google, Bing and AI search index it and people discover it. Public pages are served on the brewpage.app domain itself, for the strongest search reach; code that needs its own origin (cookies, storage) gets its own subdomain automatically. Anyone can find and read a public page, so it is unsuitable for secrets, tokens or personal data. Omit (default): private, a generated priv-* namespace; unlisted, not indexed; the link still opens it. Lowercase only: 1-32 of a-z, 0-9, hyphen."
  3. Changed1 schema field changedv1.16.3
    • changedInput schema / properties / ownerToken / description
      Previous value: -"Optional. Default: BREWPAGE_OWNER_TOKEN, else a new token per create."New value: +"Optional; the ownerToken from your first create keeps publications under one owner. Default: env BREWPAGE_OWNER_TOKEN (local server only), else a new token per create."
  4. Changed2 schema fields changedv1.15.0
    • changedInput schema / $schema
      Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
    • removedInput schema / additionalProperties
      Removed value: -false
  5. Changed1 schema field changedv1.14.5
    • changedInput schema / properties / namespace / description
      Previous value: -"namespace=public: listed in the public gallery and the sitemap, so Google, Bing and AI search can find and index it and people can discover it. Use it for anything meant to be found or shared: docs, guides, demos, portfolios, reports, landing pages. Public pages are served right on the brewpage.app domain, which gives them the strongest reach in search; a page whose code needs its own origin (cookies, storage) gets its own subdomain automatically. Anyone can find and read a public page: never put secrets, tokens or personal data there. Omit (default): private. Unlisted and not indexed; anyone who has the link can still open it. Lowercase only: 1-32 of a-z, 0-9, hyphen."New value: +"namespace=public: listed in the public gallery and the sitemap, so Google, Bing and AI search can find and index it and people can discover it. Suits anything meant to be found or shared: docs, guides, demos, portfolios, reports, landing pages. Public pages are served right on the brewpage.app domain, which gives them the strongest reach in search; a page whose code needs its own origin (cookies, storage) gets its own subdomain automatically. Anyone can find and read a public page, so it is unsuitable for secrets, tokens or personal data. Omit (default): private. Unlisted and not indexed; anyone who has the link can still open it. Lowercase only: 1-32 of a-z, 0-9, hyphen."
  6. Changed1 schema field changedv1.14.2
    • changedInput schema / properties / namespace / description
      Previous value: -"Optional. Omit to generate an unlisted namespace: anyone with its unpassworded link can read it, but it is excluded from gallery/search. Pass a custom namespace to group unlisted content, or pass `public` ONLY when the user explicitly wants gallery/search eligibility. Password-protected content stays excluded; unlisted, protected or otherwise ineligible native responses carry noindex; eligible public HTML, sites and files may permit indexing. Lowercase only: 1-32 of a-z, 0-9, hyphen."New value: +"namespace=public: listed in the public gallery and the sitemap, so Google, Bing and AI search can find and index it and people can discover it. Use it for anything meant to be found or shared: docs, guides, demos, portfolios, reports, landing pages. Public pages are served right on the brewpage.app domain, which gives them the strongest reach in search; a page whose code needs its own origin (cookies, storage) gets its own subdomain automatically. Anyone can find and read a public page: never put secrets, tokens or personal data there. Omit (default): private. Unlisted and not indexed; anyone who has the link can still open it. Lowercase only: 1-32 of a-z, 0-9, hyphen."
  7. Changed2 schema fields changedv1.13.0
    • changedInput schema / properties / namespace / description
      Previous value: -"Optional. Omit to generate an unlisted namespace: anyone with its unpassworded link can read it, but it is excluded from gallery/search. Pass a custom namespace to group unlisted content, or pass `public` ONLY when the user explicitly wants gallery/search eligibility. Password-protected content stays excluded; unlisted, protected or otherwise ineligible native responses carry noindex; eligible public HTML, sites and files may permit indexing."New value: +"Optional. Omit to generate an unlisted namespace: anyone with its unpassworded link can read it, but it is excluded from gallery/search. Pass a custom namespace to group unlisted content, or pass `public` ONLY when the user explicitly wants gallery/search eligibility. Password-protected content stays excluded; unlisted, protected or otherwise ineligible native responses carry noindex; eligible public HTML, sites and files may permit indexing. Lowercase only: 1-32 of a-z, 0-9, hyphen."
    • addedInput schema / properties / ownerToken
      Added value: +{
      +  "description": "Optional. Default: BREWPAGE_OWNER_TOKEN, else a new token per create.",
      +  "type": "string"
      +}
  8. First observedv0.1.0

TDQS

A3.8/5.0
Behavior3/5

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

Annotations only say the operation writes and is not destructive, so the description carries most of the load, and it does add real context: 5 MiB / 20 MiB video caps, no password or TTL support, returned share link, ownerToken and manageUrl, and the html-file-as-source fallback. It stops short of stating failure modes for size or fetch errors and doesn't explain deliveryMode or the private-namespace subdomain default, which the schema alone covers.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The action and namespace rule are front-loaded, then limits, then return values, then the page-conversion rules and security caveats — a coherent progression from what it does to what comes back. Dense, but every sentence carries operational information; nothing is padding.

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?

No output schema exists, and the description compensates by naming the three returned artifacts (share link, owner token, manageUrl) and flagging that manageUrl grants control. Limits, namespace semantics, and page-vs-file behavior are covered; the deliveryMode parameter and sibling alternatives are the remaining gaps.

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 100%, so the baseline is 3. The description restates the namespace public/private split and that a filename extension decides page conversion, both of which the schema already documents, and it never mentions deliveryMode or ownerToken as inputs, so it adds little beyond the structured data.

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?

A specific verb and resource: 'Upload a file from a URL', and the title reinforces that the result is published. It partly distinguishes itself from siblings by describing how HTML/Markdown inputs become pages, but never states when to prefer publish_html or publish_site instead, so an agent could conflate this with those tools.

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?

Explicit conditional guidance: namespace=public for anything meant to be found or shared (docs, guides, demos, portfolios), omit for unlisted private, and private namespace plus password for secrets. What's missing is sibling routing — nothing says when to reach for publish_html/publish_json/publish_kv in place of this tool.

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