brewpage-mcp

Publish JSON document

publish_json

Publish a JSON document to BrewPage and get a shareable link plus owner and management tokens. Use it to host JSON up to 1 MiB with optional tags, password, TTL, and namespace settings.

Instructions

Publish a JSON document to BrewPage (max 1 MiB). Accepts a JSON object, array, or a JSON-encoded string containing any valid JSON, including scalars/null. Returns its primary share link and owner token. 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": {
      "json": "<json>"
    },
    "name": "publish_json"
  }
}

Input Schema

Name	Required	Description
`json`	Yes	JSON document to publish (object, array, or JSON-encoded string)
`tags`	No	Optional tags for the document
`ttlDays`	No	TTL in days: up to 30 days without an account, up to 90 with a free profile (pass an ownerToken held in the profile); a default applies when omitted. Accepts whole days: 15, '15d', '15 days'. The returned expiresAt is the actual expiry.
`password`	No	Optional password to protect the document
`namespace`	No	Omit (default): private. namespace=public: the shared public namespace. JSON and KV are never listed in the gallery or indexed, in any namespace; anyone who has the link can open it. Lowercase only: 1-32 of a-z, 0-9, hyphen.
`ownerToken`	No	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.
`deliveryMode`	No	Optional 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.

Changed1 schema field changedv1.22.0Nov 14, 2026

changedInput schema / properties / ttlDays / description

Previous value: -"Requested TTL: days as a number, or a string such as '2w', '36h' or '1 month' (default 15 days). The server rounds to whole days and clamps to the allowed range (1-30; up to 90 with an owner token in a profile), reporting each adjustment in notices; the returned expiresAt is the actual expiry."New value: +"TTL in days: up to 30 days without an account, up to 90 with a free profile (pass an ownerToken held in the profile); a default applies when omitted. Accepts whole days: 15, '15d', '15 days'. The returned expiresAt is the actual expiry."

Changed2 schema fields changedv1.16.3Oct 30, 2026

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."

changedInput schema / properties / ttlDays / description

Previous value: -"Requested TTL: days as a number, or a string such as '2w', '36h' or '1 month' (default 15 days). The server rounds to whole days and clamps to the allowed range (1-30 by default; owner caps differ), reporting each adjustment in notices; the returned expiresAt is the actual expiry."New value: +"Requested TTL: days as a number, or a string such as '2w', '36h' or '1 month' (default 15 days). The server rounds to whole days and clamps to the allowed range (1-30; up to 90 with an owner token in a profile), reporting each adjustment in notices; the returned expiresAt is the actual expiry."

Changed3 schema fields changedv1.15.0Oct 27, 2026

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
```

changedInput schema / properties / json / anyOf

Previous value: -[
-  {
-    "type": "string"
-  },
-  {
-    "additionalProperties": {},
-    "type": "object"
-  },
-  {
-    "items": {},
-    "type": "array"
-  }
-]New value: +[
+  {
+    "type": "string"
+  },
+  {
+    "additionalProperties": {},
+    "propertyNames": {
+      "type": "string"
+    },
+    "type": "object"
+  },
+  {
+    "items": {},
+    "type": "array"
+  }
+]

Changed1 schema field changedv1.14.5Oct 27, 2026

changedInput schema / properties / ttlDays / description

Previous value: -"Requested TTL: days as a number, or a string such as '2w', '36h' or '1 month' (default 15 days). The server rounds to whole days and clamps to the allowed range (1-30 by default; owner caps differ), reporting each adjustment in notices; use returned expiresAt."New value: +"Requested TTL: days as a number, or a string such as '2w', '36h' or '1 month' (default 15 days). The server rounds to whole days and clamps to the allowed range (1-30 by default; owner caps differ), reporting each adjustment in notices; the returned expiresAt is the actual expiry."

Changed1 schema field changedv1.14.2Oct 26, 2026

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: +"Omit (default): private. namespace=public: the shared public namespace. JSON and KV are never listed in the gallery or indexed, in any namespace; anyone who has the link can open it. Lowercase only: 1-32 of a-z, 0-9, hyphen."

Changed2 schema fields changedv1.13.0Oct 25, 2026

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."

changedInput schema / properties / ownerToken / description

Previous value: -"Existing owner token to group this document under the same owner as previous content"New value: +"Optional. Default: BREWPAGE_OWNER_TOKEN, else a new token per create."

First observedv0.1.0Oct 23, 2026

TDQS

A3.9/5.0

Behavior5/5

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

Annotations only declare readOnlyHint=false and destructiveHint=false; the description goes far beyond by disclosing the 1 MiB ceiling, that a primary share link plus owner token are returned, that manageUrl is a control grant unsuitable for public sharing, that secrets are permitted but flagged in notices, and the hard rule that tokens and manage links must never appear in public content. That is exactly the security and side-effect context an agent needs before calling a non-read-only publish operation.

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 purpose and size limit are front-loaded, and the following sentences each carry distinct load-bearing information (return values, private-link semantics, secrets policy, token-leak warning). It is dense and slightly cluttered by stacking several warnings, but no sentence is redundant filler.

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?

With no output schema, the description responsibly explains what comes back (share link, owner token, manageUrl) and references expiresAt for TTL. For a 7-parameter mutation tool it covers limits, returns, and security policy; only error behavior and what happens to an existing publication on conflict are left unaddressed.

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 schema already explains json, tags, ttlDays, password, namespace, ownerToken, and deliveryMode in detail. The description adds only the 1 MiB limit on the payload and the secrets/namespace/password pairing, which is useful but marginal against an already complete schema. Baseline 3 is appropriate.

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?

The first sentence names a specific verb and resource ('Publish a JSON document to BrewPage') plus a hard constraint (max 1 MiB), and the description distinguishes what this tool produces (share link, owner token, manageUrl) versus other publish operations. It stops short of naming siblings such as update_json or publish_file, so an agent must infer the boundary from the resource type alone.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives situational guidance for configuration ('Private namespace + password suit secrets', 'Secrets allowed'), which steers parameter choices well. However it never states when to use this over update_json or publish_file, nor any exclusions or prerequisites for publication, so the when-to-use decision is only implied by the resource type.

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

Publish JSON document

Instructions

Tool call template

Input Schema

Schema Changelog

TDQS

Other Tools