Configure the site

Configure the brand's site as a whole: inspect Homepage + Pages + Posts together, flip it public or private, update its identity, and connect a custom domain. These are the site-level settings that sit above individual pages.

When to use

Use these tools to control what the site contains, whether it is reachable, and where it lives. set_site_public (or update_site_settings with isPublic) is the master switch. Published surfaces aren't visible until the site itself is public. Read the unified state with get_site_status before making claims; publicUrl is the authoritative live address when non-null, while prospectiveUrl is where the site will live once published.

Typical sequence

1. get_site_status: read composition, per-surface publish state, design version, and hosting.
2. set_site_public (or update_site_settings with isPublic: true): turn the whole site on. This requires a username.
3. For a dedicated domain, use update_site_settings with customDomain, then verify_custom_domain.
4. For a path on an existing site, use configure_subpath_hosting, install the returned snippet, then call verify_subpath_hosting.
5. Use set_primary_hosting_mode when the verified destination is not already primary.

Tools

get_site_status

Read the whole site in one call. A site is Homepage + Pages + Posts; composition says which surfaces are included, and isPublic is the master visibility gate. mode is primary when Homepage is included and companion when Pendium supplements another site. The response also reports each surface's publish/live state, the active design-manifest row and schema versions, and hosting mode. publicUrl is the canonical address only when the site has a reachable live Home; otherwise it is null. prospectiveUrl is the same serving-host-aware address for narrating where the site will live after publication — never describe it as live.

Homepage generation compatibility fields remain in the response: activeDesign and currentRun retain their designId values so clients can correlate background jobs. currentRun is generating, awaiting_approval, failed, or null.

Authentication: Required. The agent must belong to the authenticated account.

Type: Read-only.

Returns success, syntheticId, mode, composition, isPublic, isLive, surfaces, designManifest, hostingMode, subpath, publicUrl, prospectiveUrl, and the compatibility homepage fields.

set_site_public

The master switch for the brand's whole site. When public, the site and its published pages and feed posts are crawlable and reachable at /{username}; when private, the entire site is hidden regardless of any individual page's published status. Making the site public is the foundational crawlability step — published pages aren't visible until the site itself is on. The change is reflected immediately in the Site manager and invalidates the public site surfaces so their serving state follows the new master setting. Synchronous, no LLM call.

Authentication: Required. The agent must belong to the authenticated account (owner, admin, or a group-shared member).

Type: Write — non-destructive.

Returns success, the syntheticId, and the resolved isPublic state.

get_site_settings

Read the brand's site configuration: username, publicUrl, prospectiveUrl, isPublic, Posts visibility, custom-domain state, hosting mode, subpath state, and basic site metadata. publicUrl is custom-domain and subpath aware and is non-null only when a live Home is reachable. prospectiveUrl is the configured address to narrate as “will be at … once published,” never as live. Use these fields rather than assembling a URL from hosting details. Call this before changing site or hosting settings.

Authentication: Required. The agent must belong to the authenticated account (owner, admin, or a group-shared member).

Type: Read-only.

Returns success, the syntheticId, brandName, username, isLive, publicUrl, prospectiveUrl, isPublic, feedHidden, customDomain, customDomainVerified, hostingMode, subpath, title, tagline, description, and siteExists. subpath is either null or an object with host, pathPrefix, and verifiedAt.

update_site_settings

Apply a patch to the brand's site configuration. Pass at least one field. Routes through the same logic the in-app Site setup uses, so cache invalidation, IndexNow re-submission, and event logging behave identically. Call get_site_settings first so the patch you send isn't a no-op.

Special cases:

• isPublic: true requires the agent to have a username. If it's missing, this returns an error — call get_site_settings first.
• customDomain: <string> registers a custom domain and returns the DNS records the user must add at their registrar, then call verify_custom_domain. The record type depends on the domain: a subdomain (agents.acme.com) gets a CNAME, and a root domain (acme.com) gets one or more A records with the name @, because DNS forbids a CNAME at a zone root. Any ownership TXT challenge is included alongside. Read the type on each returned record rather than assuming a CNAME. Custom domains are available on the Starter and Pro plans.
• customDomain: null disconnects the current custom domain; the site stays reachable on the Pendium subdomain.

Authentication: Required. Most settings (visibility, feed-hidden, title/tagline/description) are available to any member with access (owner, admin, or group-shared). Connecting or disconnecting a custom domain (the customDomain field) is restricted to the agent's owner or a platform admin — an account-level hosting op. An account in read-only mode can't do this — the call returns a read-only error.

Type: Write — non-destructive.

At least one field beyond syntheticId must be provided. Returns success, the syntheticId, a changed map of which fields were applied, and — when a custom domain was set — a customDomain object with the dnsRecords to add. Each record carries a type (A, CNAME, or TXT), a name, and a value; relay them to the user as given.

verify_custom_domain

Re-check DNS for the brand's custom domain. Verification runs in two phases — domain ownership (TXT), then a live lookup of the record that routes traffic. That second check follows the domain: a subdomain is verified by its CNAME, a root domain by its A records. Returns verified: true once both pass (and flips customDomainVerified in the DB); returns verified: false with the still-pending DNS records when one or both haven't propagated yet. Use after the user reports adding the DNS records from update_site_settings.

A root domain has two extra conditions that a subdomain doesn't: every A record on the root must be one of the published targets, and the root must have no AAAA record. A leftover record of either kind keeps sending some visitors to the customer's previous host, so verification refuses until it's gone. When that's the blocker the reason names the offending record — pass it through instead of telling the user to wait for propagation.

Authentication: Required. Custom-domain management is restricted to the agent's owner or a platform admin — group-shared members can read and manage other feed settings but cannot advance the hosting state.

Type: Write — non-destructive.

Returns success, the syntheticId, and verified. When verified is false, the response includes reason, the still-pending dnsRecords, and — for a subdomain — the cnameTarget currently resolving. Returns an error if no custom domain is configured — call get_site_settings first if unsure.

configure_subpath_hosting

Configure the brand's site under a path on its own domain, such as example.com/agents. The tool records the host, path prefix, and provider, then returns a provider-specific snippet with installation steps. It does not verify the proxy or make it primary.

Authentication: Required. The agent must belong to the authenticated account. Accounts in read-only mode cannot change hosting settings.

Type: Write — non-destructive.

Returns the saved host, path prefix, provider, whether a token was minted, and a snippet object with body, filename, language, steps, and the provider dashboard URL when one exists. Install the snippet before calling verify_subpath_hosting.

verify_subpath_hosting

Probe the configured subpath and confirm it forwards to the correct Pendium site. The response distinguishes an unreachable endpoint, a bot challenge, and a wrong-token mismatch. A successful verification may make the subpath primary when the site still uses the Pendium-hosted default.

Authentication: Required. The agent must belong to the authenticated account. Accounts in read-only mode cannot record verification.

Type: Write — non-destructive.

Returns verified, the verification timestamp on success, and whether the subpath was promoted. If challenge is true, ask the user to confirm the path loads in a browser and AI crawlers can reach it. The user may then attest to that result with set_primary_hosting_mode. Never use that path for a token mismatch.

set_primary_hosting_mode

Change the site's primary destination. This changes canonical URLs and how other verified destinations redirect.

Authentication: Required. The agent must belong to the authenticated account. Accounts in read-only mode cannot change hosting settings.

Type: Write — non-destructive.

The attestation path rechecks the proxy and refuses a token mismatch. After the change, call get_site_status; use publicUrl as live only when non-null, otherwise describe prospectiveUrl as the address after publication.