brewpage-mcp

Remove custom domain

remove_domain

Destructive

Removes a custom domain from a BrewPage publication and frees the slot immediately; the BrewPage link keeps working, while DNS records remain until the domain owner deletes them.

Instructions

Remove a custom domain from the profile: it stops showing the publication and its slot is free at once. The BrewPage link keeps working. Addressed by publication (type, namespace, id; a profile token or an owner token added to the profile) or by hostname (an admin profile token). DNS records at the DNS provider stay until the domain owner deletes them.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "remove_domain"
  }
}

Input Schema

Name	Required	Description
`id`	No	Publication ID
`type`	No	Publication type; with namespace and id, instead of hostname
`hostname`	No	Custom domain as a bare hostname, e.g. www.example.com; instead of type, namespace and id
`namespace`	No	Publication namespace
`ownerToken`	No	By publication: a profile token or an owner token added to the profile. By hostname: an admin profile token. Default: env BREWPAGE_OWNER_TOKEN (local server only).

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedv1.22.0Nov 14, 2026

changedInput schema / properties / hostname / description

Previous value: -"Custom domain, e.g. www.example.com; instead of type, namespace and id"New value: +"Custom domain as a bare hostname, e.g. www.example.com; instead of type, namespace and id"

changedInput schema / properties / ownerToken / description

Previous value: -"By publication: an owner token in the profile. By hostname: an admin token of the profile. Default: env BREWPAGE_OWNER_TOKEN (local server only)."New value: +"By publication: a profile token or an owner token added to the profile. By hostname: an admin profile token. Default: env BREWPAGE_OWNER_TOKEN (local server only)."

Addedv1.18.0Nov 10, 2026

TDQS

A4.2/5.0

Behavior5/5

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

Beyond the destructiveHint annotation, it discloses the concrete consequences: the domain stops showing the publication immediately, the slot is freed at once, the BrewPage link keeps working, and DNS records remain at the provider until the owner deletes them. Those are non-obvious effects and a clear statement of what is not destroyed.

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?

Three compact sentences, front-loaded with the action and its effect, then addressing modes, then the DNS caveat. Slightly dense parenthetical phrasing ("a profile token or an owner token added to the profile") but almost no wasted words.

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, unannotated-on-return tool with no output schema, the description covers consequences, auth requirements per addressing mode, and the DNS aftermath. It omits reversibility (that set_domain can re-add the domain), a minor gap given the annotations already flag destructiveness.

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 adds meaning by framing the parameters as two mutually exclusive addressing schemes and attaching the correct token type to each. That clarifies how type/namespace/id relate to hostname in a way the schema only hints at.

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 description opens with a specific verb+resource ("Remove a custom domain from the profile") and immediately states the effect on the publication. It does not explicitly name a sibling such as set_domain or check_domain, so the differentiation is inferable rather than stated.

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?

It spells out the two valid addressing modes — by publication (type, namespace, id plus profile/owner token) or by hostname (admin profile token) — which is real guidance about how to invoke it. It stops short of saying when to choose this over set_domain or check_domain, so no explicit exclusions or alternatives are given.

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