Skip to main content
Glama
Sign In

brewpage-mcp

by io.github.kochetkov-ma
OverviewDiscussionsAdmin

Rename page or site

set_title

Rename an HTML page or site: the title shown in the gallery, profile, search and link cards. Works when the publication's owner token is in a BrewPage profile (free sign-in at https://account.brewpage.app). The new title stays when you republish. Link unchanged.

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": {
      "type": "<type>",
      "namespace": "<namespace>",
      "id": "<id>"
    },
    "name": "set_title"
  }
}

Input Schema

NameRequiredDescriptionDefault
idYesPublication ID
typeYesPublication type
titleNoNew title, 1-200 characters, one line. Empty string: back to the title from the content. Omit: show the current title.
namespaceYesPublication namespace
ownerTokenNoOwner token from create. Default: env BREWPAGE_OWNER_TOKEN (local server only).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A3.9/5.0
Behavior4/5

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

Annotations only declare readOnlyHint=false and destructiveHint=false; the description adds real behavioral context beyond them — the new title persists through republish, the link is unaffected, and an owner token from a signed-in profile is required. It stops short of describing failure modes (invalid token, title too long) or whether nested pages are retitled.

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 scope limit, then auth, then persistence. Sentences are terse and each carries information, though the telegraphic fragments ("Link unchanged.") and the inline sign-in URL make it feel clipped rather than polished.

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 mutation tool with full schema coverage and no output schema, the description covers effect, scope, persistence and auth prerequisites. Missing only edge-case behavior (unauthorized owner, title collisions, whether the empty-string reset is destructive), which is a modest gap rather than a blocking one.

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% and the schema already documents id, type, namespace, ownerToken and the important title semantics (1-200 chars, empty string resets, omit to read current). The description adds no parameter-level meaning beyond that, 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 ("Rename an HTML page or site") and clarifies which title is affected — the one shown in gallery, profile, search and link cards — plus the negative scope "Link unchanged." That implicitly separates it from content/URL-mutating siblings like update_html or update_hosting, but no sibling is named explicitly.

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 concrete precondition for use: the publication's owner token must belong to a BrewPage profile, with a sign-in URL supplied. It does not state when to prefer this over update_html/update_json or what to do on auth failure, so alternatives are left implicit.

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
Claude Code, inside the Godot 4 editorFlockbay puts an AI agent in the real Godot 4 editor: it writes GDScript, runs your game and fixes what breaks. Free, or bring your own Claude Code or Codex.flockbay.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources