Skip to main content
Glama

AgentDomains

set_proxy

Serve a backend at this subdomain through the AgentDomains edge, which terminates TLS with its own certificate — this is how you get working HTTPS on an origin that has no certificate of its own (a bare IP-less PaaS host, a tunnel, an internal box). Unlike a forward, the URL stays on your domain and the response is proxied, not redirected. Claims the label first if needed. Like a forward, a proxy TAKES OVER the hostname: A/AAAA/CNAME records on the label itself are deleted and returned in 'replaced_records', while sub-label and TXT records are untouched. A proxy and a forward are mutually exclusive on one label. Caveat: apps that hardcode their own hostname (OAuth callbacks especially) may need your new hostname registered on their side.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
emailNoEmail, if this call also claims a new name on an account without one.
labelYesThe subdomain label, without the domain suffix (e.g. 'myapp' for myapp.makes.fyi).
domainNoWhich domain to act under: 'makes.fyi' (the default) or 'agentdomains.co'. The same label can exist under each, so pass this whenever you are not using the default.
originYesBackend hostname to proxy to, without a scheme (e.g. myapp.fly.dev). Must be a hostname, not an IP.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.7/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 burden and discloses critical side effects: claiming the label, deleting A/AAAA/CNAME records on the label while leaving sub-label and TXT records untouched, returning deleted records in 'replaced_records', and being mutually exclusive with a forward. It also warns about apps that hardcode hostnames (e.g. OAuth callbacks).

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?

The description is front-loaded with the core purpose, then contrasts with a forward, then details side effects and a caveat. Every sentence conveys useful information without redundancy, and the length is justified for a mutation tool with no annotations.

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 no annotations and no output schema, the description still covers what the tool does, when to use it, what it destroys, what it returns ('replaced_records'), and important caveats. It is complete enough for an agent to call correctly.

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 all four parameters. The description adds little parameter-specific meaning beyond what the schema provides—it does not clarify the domain parameter or email semantics beyond existing schema descriptions.

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 action: serve a backend at a subdomain via the AgentDomains edge with TLS termination, and explicitly contrasts it with a forward (proxied vs redirected). It clearly distinguishes the tool from its sibling set_forward.

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 explains when to use this tool (getting working HTTPS for an origin lacking its own certificate) and when not to use it (mutually exclusive with a forward on the same label). It names the alternative forward and the key behavioral difference that should drive selection.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.