Skip to main content
Glama
tashfeenahmed

AgentDomains MCP server

set_forward

Redirect a subdomain to a target URL, preserving the incoming path and query by default. Manage temporary 302 or permanent 301 redirects with automatic HTTPS at the edge.

Instructions

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.

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.
Behavior4/5

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

With no annotations provided, the description carries the behavioral disclosure burden. It discloses the auto-claiming side effect, possible email requirement, default 302 behavior, preserved paths, and that HTTPS is handled automatically. It does not state what happens if the label already has an existing forward, but the provided side effects are far more transparent than most mutation tools in this collection.

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 four compact sentences with the core action front-loaded. Every sentence adds useful context—auto-claiming, email requirements, defaults, and edge handling—without fluff or restatement of the schema.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool complexity, 100% schema coverage, and no output schema, the description provides a sufficient operational picture: the action, the default behavior, the side-effect of claiming labels, and the email exception when claiming. It does not provide a detailed response or overload behavior, but for a setter/forwarder with schema support, it is reasonably complete.

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?

The input schema has 100% parameter coverage, so all seven parameters are already described structurally. The description adds value by stating the default behavior for preserve_path and permanent ('302 temporary redirect that preserves the request path and query'), but it does not add meaning beyond the schema for most parameters.

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 and resource: 'Forward (HTTP-redirect) a subdomain to another URL.' It clearly identifies the operation, differentiates it from the proxying sibling, and explains the auto-claim behavior that clarifies what 'set_forward' actually does.

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

Usage Guidelines3/5

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

The description implies when to use the tool—when you need an HTTP redirect rather than a proxy or DNS change—but does not explicitly name alternatives or state when not to use it. The mention of claim_domain for the email requirement gives useful cross-tool context, but the when-to-use guidance remains implicit rather than explicit.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/tashfeenahmed/AgentDomains-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server