agent4.io

set_custom_domain

Bind the client's own domain to this tenant's chat pages: https://chat.client.com/ serves the tenant's branded page (or a specific agent's chat), the address bar keeps the client's domain, and the TLS certificate is issued automatically.

**Have the client configure DNS first**: add a CNAME at their DNS provider pointing to the
`cname_target` in the response (`endpoint.agent4.io`). Key points:
- **Subdomains only** (`chat.client.com`). An apex domain (`client.com`) cannot carry a CNAME —
  have the client use a subdomain, or a DNS provider with CNAME flattening (Cloudflare etc.).
- **Cloudflare users must set the record to DNS only (grey cloud)**. With the proxy on (orange
  cloud) the name resolves to Cloudflare's addresses, verification fails, and `last_error`
  says so.
- Verification is **asynchronous**: checked once immediately on binding; if DNS hasn't
  propagated it stays `pending` and is re-checked every 10 minutes (calling this tool again
  also re-triggers). `status` = `active` means live; the certificate is issued on first visit.
- **One** domain per tenant; changing the domain re-runs verification, changing only
  `agent_alias` does not.
- Requires a plan that includes custom domains (403 = upgrade needed).

`agent_alias` empty → the domain lands on the tenant's branded page (listing available
agents); set to an agent's public alias → lands directly on that agent's chat page.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`domain`	Yes
`agent_alias`	No

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

AddedJul 30, 2026

TDQS

A5/5.0

Behavior5/5

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

With no annotations, the description fully discloses behavioral traits: async verification with immediate check and re-checks every 10 minutes, status lifecycle (pending vs active), certificate issuance on first visit, one-domain-per-tenant constraint, and that changing agent_alias does not re-run verification. It also explains error semantics (403 = upgrade needed) and Cloudflare failure modes. This far exceeds the minimum disclosure burden.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Although long, the description is efficiently structured with bold key points and bullet-like paragraphs. Every sentence provides actionable information: prerequisites, DNS specifics, verification mechanics, constraints, and error conditions. It is appropriately sized for the tool's complexity and front-loads the core purpose before diving into nuances.

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?

Given the tool's high complexity (DNS setup, async verification, edge cases) and minimal schema annotations, the description covers all critical aspects: prerequisites, verification flow, status meanings, Cloudflare caveat, one-domain rule, agent_alias behavior, and plan limitation. It also mentions response fields (cname_target, status, last_error) providing context without needing to detail return structure.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 0% description coverage (no parameter descriptions), so the tool description must compensate fully. It does: 'domain' is explained as a subdomain-only restriction with examples, and 'agent_alias' is thoroughly described with empty vs set behavior (landing on tenant page vs specific agent chat). The description adds rich semantic meaning beyond raw schema names.

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 opens with a specific verb+resource combination: 'Bind the client's own domain to this tenant's chat pages'. It clearly distinguishes this tool from siblings by focusing on custom domain binding, an action not covered by other tools like set_pwa_branding or tenant_info. The purpose is unambiguous and detailed.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides explicit when-to-use and prerequisites: DNS CNAME must be configured first, subdomains only, special Cloudflare DNS-only requirement, plan restriction (403), and async verification behavior. It even explains when not to call or what alternative actions trigger verification (calling again re-triggers). This is exemplary usage guidance.

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

All agent4.io tools Inspect

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

Need Help?