Skip to main content
Glama

add_domain

Serve a deployed app at your own domain via the node's embedded proxy at the root path, using internal CA by default or requesting a public ACME certificate; point DNS to this machine first.

Instructions

Serve a deployed app at a domain YOU own, from this node's own proxy (P26).

    Unlike ``share_service`` (Nerdit's domain, over the cloud tunnel), this
    is the node's embedded Caddy answering ``https://<domain>/`` directly —
    in either proxy mode, at the ROOT, so a frontend needs no ``/<app>/``
    base path. The one thing the daemon cannot do for you: point the
    domain's DNS (A/AAAA/CNAME) at this machine. By default the domain is
    served with the node's internal CA, so a client must run
    ``nerdit trust`` once. ``acme=True`` requests a public ACME
    certificate; it needs an ADMIN token (403 ``domain.acme_forbidden``,
    ``reason: acme_admin_only`` — the node has one ACME account whose rate
    limits every domain on it shares) and 409 ``domain.acme_disabled``
    unless the daemon has ``[proxy.acme].enabled``.

    Refusals:
    422 ``domain.invalid`` — the name broke exactly one grammar rule and the
    message names it (``empty``, ``whitespace``, ``not_bare``,
    ``has_port``, ``wildcard``, ``ip_literal``, ``idn``, ``single_label``,
    ``grammar``, ``reserved``); 409 ``domain.taken`` (one domain, one
    service — never silently re-pointed); 422 ``domain.kind_unsupported``
    (models and databases are not routed).

    Returns ``{domain, url, state, cert_state, created}``; ``state`` is
    ``ready`` | ``withheld`` (``withheld`` = the proxy is off, the app is
    not routed yet, or its ``[deploy].edge_auth`` secret does not resolve —
    the row is stored either way and answers once it is). ``cert_state`` is
    the orthogonal certificate fact: ``internal`` (this node's CA) |
    ``disabled`` (``acme`` asked for, ``[proxy.acme]`` off) | ``pending``
    (issuing, or failing — check ``doctor``) | ``issued`` | ``expired``.
    The URL then appears in ``get_service`` / ``list_routes`` under
    ``public_urls`` (kind ``domain``).
    

Input Schema

NameRequiredDescriptionDefault
acmeNoTri-state certificate policy. ``true`` = request a public ACME certificate; ``false`` = serve with this node's internal CA; omit (the default ``null``) = keep the row's stored value, ``false`` on a new domain — so a re-run never downgrades an issued certificate.
nameYesName (or row id) of an existing deployed app — only kind 'service' can be exposed: ``share_service``/``add_domain`` refuse a model or database with 422 ``*.kind_unsupported``, while the remove tools just find nothing to undo.
domainYesBare lowercase DNS name of at least two labels: no scheme, path, port, wildcard, IP literal or IDN/punycode. Case and one trailing dot are folded server-side, so ``App.Example.COM.`` and ``app.example.com`` are one resource. A name at or under this node's own hostname, ``base_domain`` or ``extra_hostnames`` is reserved.
idempotency_keyNoCaller-chosen key: a retry with the same key replays the first result instead of acting twice. Omit and a fresh key is minted per call, so each call acts.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.6/5.0
Behavior5/5

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

With no annotations, the description carries the full behavioral burden and does so extensively: it explains the internal-CA trust requirement, ACME admin-token gating, disabled ACME errors, refusal codes, idempotency implications, row storage on `withheld`, and the orthogonal `cert_state` values. This is unusually complete for a mutation/deployment tool.

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 main purpose and sibling distinction are front-loaded, and the structure is readable. It is long and enumerates several error codes and return states that could be trimmed, but most of that detail is useful because there are no annotations and no 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?

The description is complete for a complex proxy/certificate operation: it covers prerequisites, auth requirements, refusal modes, return shape, URL visibility in sibling tools, and certificate state transitions. With no output schema and no annotations, this level of detail is appropriate.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema already documents `name`, `domain`, `acme`, and `idempotency_key` in detail. The prose reinforces domain grammar, ACME authorization, and service-only exposure, but adds little parameter syntax or meaning beyond what is already present in 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 states a specific verb and resource: serve a deployed app at a domain owned by the caller, through this node's own proxy. It explicitly distinguishes this from `share_service`, so the agent can tell which sibling to choose before opening either schema.

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?

It clearly frames the alternative: `share_service` uses Nerdit's domain over the cloud tunnel, whereas this tool serves at the root via the node's embedded Caddy. It also states the key prerequisite the daemon cannot fulfill: DNS A/AAAA/CNAME must already point at this machine.

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