brewpage-mcp

Set KV value

set_kv

Destructive

Set or update a key-value pair in an existing BrewPage KV store with an owner token, so agents can store or change hosted data.

Instructions

Set or update a key in an existing BrewPage KV store. Requires owner token. The key name hosting is reserved. 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>",
      "key": "<key>",
      "value": "<value>"
    },
    "name": "set_kv"
  }
}

Input Schema

Name	Required	Description
`id`	Yes	KV store ID
`key`	Yes	Key to set
`value`	Yes	Value to assign to the key
`namespace`	Yes	KV store namespace
`ownerToken`	No	Owner token from create. Default: env BREWPAGE_OWNER_TOKEN (local server only).

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv1.16.3Oct 30, 2026

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

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

Changed2 schema fields changedv1.13.0Oct 25, 2026

changedInput schema / properties / ownerToken / description

Previous value: -"Owner token received when the KV store was created"New value: +"Owner token from create. Default: BREWPAGE_OWNER_TOKEN."

changedInput schema / required

Previous value: -[
-  "namespace",
-  "id",
-  "key",
-  "value",
-  "ownerToken"
-]New value: +[
+  "namespace",
+  "id",
+  "key",
+  "value"
+]

First observedv0.1.0Oct 23, 2026

TDQS

A4.5/5.0

Behavior5/5

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

Goes well beyond the annotations (readOnlyHint=false, destructiveHint=true) by disclosing the owner-token requirement, the reserved key name, and a specific failure mode with status/code pair (409 OLD_PUBLICATION_READ_ONLY) plus the createUrl remediation. It also flags a security constraint about not putting tokens or manage links in public content.

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?

Four sentences, front-loaded with the core action and preconditions, with no filler. The closing note about tokens and manage links is broadly applicable security guidance rather than set_kv-specific, so it is not quite a perfectly economical definition.

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 5-parameter destructive write with no output schema, the description covers auth, reserved keys, and error behavior. It stops short of saying what a successful call returns or confirming overwrite semantics for an existing key, which would matter for a mutation 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 baseline is 3, but the description adds real semantics for the `key` parameter by declaring `hosting` a reserved namespace, and reinforces the `ownerToken` parameter with its source. It adds no format or type detail for string `value` beyond the schema, keeping it short of 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?

States a specific verb plus resource ('Set or update a key in an existing BrewPage KV store') and the word 'existing' implicitly distinguishes it from publish_kv, which creates a store. An agent can tell it apart from get_kv/set_kv siblings without opening the schema.

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 clear preconditions: requires an owner token, must target an existing store, and `hosting` is reserved. It does not explicitly route the agent to siblings (e.g. 'use publish_kv first to create the store' or 'use get_kv to read'), so the exclusion guidance is implied by 'existing' rather than stated.

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