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

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

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A3.6/5.0

Disambiguation4/5

Tools are mostly distinct by domain and action. A few pairs like add_knowledge_file vs add_knowledge_text or build_knowledge_index vs patch_knowledge_index could cause confusion, but descriptions clearly differentiate them.

Naming Consistency4/5

The vast majority follow a consistent verb_noun snake_case pattern (create_*, list_*, get_*, update_*). A few outliers like tenant_info, usage_stats, and page_context_stats are noun-first, deviating slightly from the otherwise uniform scheme.

Tool Count1/5

With 50 tools, this is a very large surface that exceeds typical well-scoped server sizes. Even for a broad platform management API, the sheer number makes it heavy and potentially overwhelming, matching the '50+' extreme mismatch category.

Completeness2/5

The server covers creation, reading, updating, and listing for most resources but lacks any delete operations (no delete_agent, delete_knowledge_base, delete_skill, delete_share, delete_storyline, delete_page_context). This is a significant gap in lifecycle coverage that will force agents to work around missing functionality.

Resources

Need Help?