Skip to main content
Glama

AgentDomains

set_forward

Forward (HTTP-redirect) a subdomain to another URL. Claims the label first if you do not own it yet, in which case an email may be required exactly as for claim_domain. Defaults to a 302 temporary redirect that preserves the request path and query. HTTPS at the edge is handled for you. A forward TAKES OVER the hostname: any A/AAAA/CNAME record on the label itself is deleted as part of this call and returned in 'replaced_records' — report those to the user, since the name no longer points where it did. Records on a sub-label (www.myapp.makes.fyi) and TXT records are untouched. If the forward fails to come up the replaced records are restored, with new ids.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
cloakNoKeep the AgentDomains hostname in the address bar and load the target inside a frame. Discouraged — breaks many sites.
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.
targetYesDestination URL, including scheme (e.g. https://example.com/docs).
permanentNoUse a 301 permanent redirect instead of the default 302 temporary one.
preserve_pathNoAppend the incoming path and query to the target. Defaults to true; set false to always land on the target root.

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 behavioral burden and does so thoroughly: takeover semantics, deleted A/AAAA/CNAME records, returned replaced_records, untouched sub-label/TXT records, failure restoration with new ids, and default 302 behavior. These details are exactly what an agent needs to safely invoke a mutating call.

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 action, then layers necessary caveats and failure behavior without wasted prose. Every sentence contributes operational detail for a complex mutation.

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, no output schema, and seven parameters, the description is complete enough to call the tool correctly. It covers prerequisites, defaults, destructive side effects, recovery behavior, and the important detail to report replaced records to the user.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3, but the description adds meaning beyond the schema by tying email to the claim flow and stating the default redirect type and path/query preservation. The added value is real though not exhaustive across every parameter.

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?

States a specific verb and resource: HTTP-redirect a subdomain to another URL. It clearly differentiates from sibling tools by describing the takeover of DNS records and the relationship to claim_domain, so an agent can identify the operation without opening the schema.

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

Usage Guidelines4/5

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

Provides strong context for when the tool applies, including that it claims the label if not owned and may require email like claim_domain. It also explains defaults and edge behavior. It does not explicitly name alternatives such as set_proxy or add_dns_record for non-forwarding use cases, so it falls short of a full when/when-not rubric.

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.