Skip to main content
Glama

brewpage-mcp

by io.github.kochetkov-ma
OverviewDiscussionsAdmin

Publish KV entry

publish_kv

Publish a key/value entry to BrewPage. Creates a KV store; the entry is addressed by (namespace, id, key). Repository defaults: 1 MiB per value, 1,000 keys per store; the key name hosting is reserved. 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.

Input Schema

NameRequiredDescriptionDefault
keyYesKV key (first part of the (namespace, id, key) addressing tuple)
tagsNoOptional tags for the KV entry
valueYesKV value
ttlDaysNoRequested 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.
passwordNoOptional password to protect the KV store
namespaceNoOmit (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.
ownerTokenNoOptional. Default: BREWPAGE_OWNER_TOKEN, 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 changed
    • 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."
  2. First observed

TDQS

A4.1/5.0
Behavior5/5

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

Goes well past the annotations: repository quotas (1 MiB per value, 1,000 keys per store), the reserved key name `hosting`, that a new owner token is minted or taken from BREWPAGE_OWNER_TOKEN, and that manageUrl is a private control link that must not be shared publicly. That is exactly the behavioral context annotations cannot carry.

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 action and the addressing model, then quotas, then return values, then security notes. Dense but each sentence carries a distinct fact; the two consecutive 'Returns...' sentences could be merged.

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?

With eight parameters and no output schema, the description compensates by describing both return values (share link, owner token, manageUrl) and the safety-relevant properties of each. An agent has enough to call this correctly and handle the result.

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; the description earns more by explaining the (namespace, id, key) addressing tuple, the reserved `hosting` key, and the secrets-oriented use of namespace/password. ttlDays and deliveryMode nuances are left entirely to the schema.

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 ('Publish a key/value entry to BrewPage') and adds that it creates a KV store addressed by (namespace, id, key). It does not distinguish itself from the sibling set_kv, which an agent would need to tell create from update.

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?

Offers option-level guidance ('Private namespace + password suit secrets') and notes secrets are allowed and flagged, which helps configure a call. It never says when to use this versus get_kv/set_kv/delete_resource, so tool selection is left to inference from the names.

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

All brewpage-mcp toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources