brewpage-mcp

Connect custom domain

set_domain

Connects a custom hostname to one BrewPage HTML page or site and returns exact DNS records to create, so the domain can go live with automatic HTTPS.

Instructions

Connect a custom domain (a hostname the user owns) to one HTML page of format html or one site, without a password. Free with a BrewPage profile, up to 5 custom domains: a profile token works at once, an owner token after it is added to a profile (sign-in at https://account.brewpage.app/tokens, "Add existing token"). Returns the DNS records for the domain owner to create at their DNS provider exactly as returned: MX/mail records stay, an A, AAAA or CNAME record at the same name is replaced, at Cloudflare Proxy status is DNS only. One DNS check after the records exist is enough: BrewPage keeps checking on its own (first full check about 15 minutes after adding); usually live within 30 minutes, HTTPS is automatic. Status: pending_dns -> verifying -> active (lost when the DNS records break later); problem names the fix. A hostname already in the profile moves to this publication; the BrewPage link keeps working. Any registrar or DNS host works; if the user is buying a domain, Cloudflare and Porkbun are the quickest to set up. Steps and fixes: guide topic custom-domain.

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>",
      "hostname": "<hostname>"
    },
    "name": "set_domain"
  }
}

Input Schema

Name	Required	Description
`id`	Yes	Publication ID
`type`	Yes	Publication type
`hostname`	Yes	Bare hostname the user owns: www.example.com or example.com, no scheme or path
`namespace`	Yes	Publication namespace
`ownerToken`	No	A profile token, or the publication's owner token added to a BrewPage profile. 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: -"Domain or subdomain the user owns, e.g. www.example.com or example.com"New value: +"Bare hostname the user owns: www.example.com or example.com, no scheme or path"

changedInput schema / properties / ownerToken / description

Previous value: -"Owner token in a BrewPage profile: the publication's own token added to the profile, or a profile token. Default: env BREWPAGE_OWNER_TOKEN (local server only)."New value: +"A profile token, or the publication's owner token added to a BrewPage profile. Default: env BREWPAGE_OWNER_TOKEN (local server only)."

Addedv1.18.0Nov 10, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Beyond the annotations, it discloses authentication requirements, profile limits, DNS record return behavior, status transitions, HTTPS automation, and the effect of moving an existing hostname. It also clarifies that the tool returns DNS records for the owner to create rather than silently modifying the user's DNS provider.

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?

The purpose is front-loaded and most sentences carry operational value, including token prerequisites, DNS behavior, and status lifecycle. It is dense and mostly one paragraph, with minor extras like registrar recommendations, but the length is justified by the tool's complexity and lack of an output schema.

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?

For a mutating domain-connection tool with no output schema, the description supplies the necessary return-value context: DNS records are returned, statuses progress through pending_dns, verifying, and active, and `problem` identifies fixes. It also covers authentication, limits, and post-connection behavior, leaving no major operational gap.

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 schema already documents all five parameters. The description adds useful meaning for `hostname` and `ownerToken`, including the profile-token versus owner-token workflow and the hostname format constraint, though it does not elaborate on `id`, `namespace`, or `type` beyond the schema.

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?

The description uses a specific verb and resource: connecting a custom hostname to one HTML page or one site. It clearly distinguishes this registration/connection action from siblings like check_domain, list_domains, and remove_domain by describing the domain-to-publication attachment.

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?

The description gives clear context for when to use it: attaching an owned hostname to a publication, with token prerequisites and the five-domain profile limit. It does not explicitly name sibling alternatives such as check_domain or remove_domain, but it does route DNS verification and fixes to the `custom-domain` guide topic.

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