Skip to main content
Glama
Sign In
brewpage-mcp

brewpage-mcp

by kochetkov-ma
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Update JSON document

update_json
Destructive

Update an existing BrewPage JSON document by ID with a new JSON object, array, or encoded string; an owner token is required.

Instructions

Update an existing BrewPage JSON document. Requires owner token. Accepts a JSON object, array, or a JSON-encoded string. Old publications (made before 5 October 2026) are read-only: 409 OLD_PUBLICATION_READ_ONLY with createUrl to publish anew. 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": {
      "namespace": "<namespace>",
      "id": "<id>",
      "json": "<json>"
    },
    "name": "update_json"
  }
}

Input Schema

NameRequiredDescriptionDefault
idYesDocument ID
jsonYesNew JSON document (object, array, or JSON-encoded string)
namespaceYesDocument namespace
ownerTokenNoOwner token from create. Default: env BREWPAGE_OWNER_TOKEN (local server only).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.16.3
    • changedInput schema / properties / ownerToken / description
      Previous value: -"Owner token from create. Default: BREWPAGE_OWNER_TOKEN."New value: +"Owner token from create. Default: env BREWPAGE_OWNER_TOKEN (local server only)."
  2. Changed3 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
    • 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"
+  }
+]
  3. Changed2 schema fields changedv1.13.0
    • changedInput schema / properties / ownerToken / description
      Previous value: -"Owner token received when the document was created"New value: +"Owner token from create. Default: BREWPAGE_OWNER_TOKEN."
    • changedInput schema / required
      Previous value: -[
-  "namespace",
-  "id",
-  "json",
-  "ownerToken"
-]New value: +[
+  "namespace",
+  "id",
+  "json"
+]
  4. First observedv0.1.0

TDQS

A4/5.0
Behavior4/5

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

Annotations already flag this as destructive, and the description adds real value beyond them: the owner-token requirement, the specific 409 OLD_PUBLICATION_READ_ONLY failure for pre-2026-10-05 publications, and a security warning about leaking tokens into public content. It doesn't state whether the supplied JSON replaces the entire document or merges, which matters for a destructive update.

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?

Four short sentences, front-loaded with the core action and followed by prerequisites, failure mode, and a safety caveat. No filler and each sentence carries distinct information.

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?

For a destructive mutation with no output schema, the description covers the token requirement, a specific error code with remedy, and a content-security constraint. The main omission is replacement-vs-merge semantics and any note on response/confirmation behavior.

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 all four parameters are already documented, including the ownerToken env default. The description's note about accepting an object, array, or JSON-encoded string restates the schema's anyOf rather than adding new semantics, so the baseline of 3 applies.

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?

States a specific verb and resource ('Update an existing BrewPage JSON document'), and the word 'existing' implicitly separates it from publish_json and get_json. It never names a sibling explicitly, so differentiation relies on inference rather than a direct statement.

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?

Gives a clear precondition ('Requires owner token') and a concrete fallback path for the read-only case ('createUrl to publish anew'), which effectively points the agent to the publish flow. It still doesn't explicitly say when to prefer this over publish_json or how it interacts with republish_site-style flows.

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

Deploy Server

Other Tools