configure_custom_domainUse this when you need to manage a custom domain for an existing app, including adding a hostname, verifying DNS, or deleting it.
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | Lifecycle action to perform for this custom domain | |
| app_id | Yes | Target app id | |
| domain | Yes | Hostname to add, verify, or delete | |
| dns_mode | No | Required only when action is add |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructive intent, and the description adds valuable context by listing the lifecycle actions (add, verify, delete) and limiting scope to existing apps. It does not contradict the annotations and provides reasonable behavioral context beyond what the schema or annotations alone offer.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single concise sentence that front-loads usage guidance and lists the core operations. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with four parameters, no output schema, and destructive potential, the description covers the essential purpose, scope, and actions. Combined with the parameter schema and annotations, an agent has enough information to select and invoke it correctly. Minor additional details (e.g., dns_mode requirement) are left to the schema, which is acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so descriptions exist for all parameters. The tool description adds meaning by explaining that 'domain' is a hostname and clarifying the 'action' values (add, verify, delete). This exceeds the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool manages a custom domain for an existing app and enumerates the specific actions (add hostname, verify DNS, delete). The verb 'manage' is broad, but the list of operations makes the purpose specific and distinguishes it from sibling tools like get_custom_domain_instructions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use this when you need to manage a custom domain for an existing app', providing clear usage context. It does not mention alternatives or exclusions, but the sibling list shows get_custom_domain_instructions is for instructions, so the context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Most tools have distinct purposes, but the 5 secrets-related tools (create_secret_entry, delete_app_secrets, get_secret_entry_status, list_app_secrets, set_app_secrets) are numerous and could cause confusion. Similarly, deploy_app and apply_app_version both involve deployment but with different contexts. Overall, descriptions help differentiate, but some overlap remains.
The majority of tools follow verb_noun pattern (e.g., deploy_app, get_apps). However, the src_ prefix tools (src_glob, src_grep, src_read) deviate by using a noun prefix instead of a verb, creating a slight inconsistency. Otherwise, naming is clear and predictable.
With 21 tools, the server covers deployment, domain management, secrets, source inspection, and asset upload without being overly large. The count is well-scoped for a deployment platform, each tool serving a necessary role.
Core workflows (deploy, status, secrets, source inspection) are well-covered. However, there are minor gaps: no tool to list available templates or manage app metadata beyond deployment. The surface is mostly complete but could benefit from a few additional administrative tools.