Skip to main content
Glama

Metadata MCP Connector

by io.metadata.mcp-server
OverviewDiscussionsAdmin

Set Landing Page Subdomain

set_landing_subdomain
Destructive

Set the subdomain this account's generated landing pages are served from.

USE FOR: "set our landing page domain", "I want our pages on zoom.ad.live", "use acme as our landing subdomain", "our landing pages should be branded".

SET ONCE: this claims a subdomain for an account that has NONE. It cannot change or release one that is already set, and it does not fail loudly when asked to; it returns status "locked" and changes nothing. A change is support's to make.

WHEN TO OFFER IT UNPROMPTED: new accounts start with no subdomain, so their landing pages are served from a long shared service URL. If get_account_details shows landingSubdomain is null and the user is creating or about to create a landing page, offer to set one, since a branded URL is what goes into their ads. Suggest a label derived from their own company domain (acme.com -> "acme") and let them confirm or change it. Do NOT set one without the user agreeing to the specific name.

ARGS:

  • subdomain (required): the label ONLY, never the full hostname. Pass "zoom", not "zoom.ad.live" and not "https://zoom.ad.live". Pass an empty string to release the account's current claim.

RULES THE LABEL MUST MEET: 1-63 characters of a-z, 0-9 and hyphens; no leading or trailing hyphen; not all digits; not a reserved name (www, api, app, mail, cdn, admin and similar). The platform only trims and lowercases what you send; it does NOT rewrite an invalid label into a valid one, so build a valid label yourself before calling: "Zoom Events" is refused, "zoom-events" is accepted. Always report the value the tool returns rather than what you sent, because the two can differ.

SCOPE: acts on the CALLER'S OWN account only. There is no account argument and it cannot be pointed at another account; to set one for a different account, an operator does it from the platform admin screen.

RESPONSE status AND WHAT TO DO NEXT:

  • "set": claimed. Tell the user the stored subdomain.

  • "cleared": the claim was released; pages fall back to the default URL.

  • "unavailable": another account already holds that name. This is NOT an error. Tell the user it is taken, suggest a variant, and call again once they choose.

  • "invalid": the label breaks the rules above. Rewrite it, confirm with the user, call again.

  • "not_permitted": the caller is not an account admin, and nothing was changed. Tell them an admin on their account has to set it, under Settings then Configurations. Do not ask them for a name and do not retry.

  • "locked": the account already has a subdomain and nothing was changed. Tell the user it is already set, name it, and say support changes it. Do NOT retry and do NOT offer to pick a different name.

IMPORTANT: the name is globally unique and first come first served, and once pages are live it is baked into ad URLs already in market, so changing it later breaks them. That is why it is set once and only support can move it.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
subdomainYesThe subdomain label only, without any zone suffix or scheme ("zoom", not "zoom.ad.live"). Empty string releases the current claim.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A5/5.0
Behavior5/5

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

The annotations only indicate destructiveHint=true and readOnlyHint=false, but the description goes far beyond: it states the set-once behavior, silent 'locked' failure mode, no rewriting of invalid labels, global uniqueness, first-come-first-served nature, impact on live ad URLs, and account-scope restrictions. This fully discloses behavioral characteristics and does not contradict the annotations.

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 long but every section earns its place for a destructive, one-time, support-only-change operation. It is front-loaded with the core purpose, then uses clear labeled sections for usage, arguments, rules, response statuses, and consequences. The structure makes the dense information navigable.

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?

With no output schema, the description fully compensates by enumerating every possible response status and the appropriate follow-up action. It also covers permissions, scope, validity rules, edge cases, and downstream business impact. Nothing an agent needs to call this tool correctly is missing.

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

Parameters5/5

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

Although the schema already documents the single subdomain parameter, the description adds substantial meaning: label only with examples, empty string as a release action, required label rules, reserved-name exclusions, lowercasing/trimming behavior, and validation that the agent must perform before calling. This is far beyond the schema's baseline.

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+resource: 'Set the subdomain this account's generated landing pages are served from.' It clearly distinguishes this tool from the many sibling tools by scoping it to landing page subdomains and the caller's own account.

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?

Provides explicit USE FOR phrases, a concrete 'WHEN TO OFFER IT UNPROMPTED' trigger tied to get_account_details returning a null landingSubdomain, and clear when-not-to conditions: do not set without user agreement, do not retry on locked or not_permitted, and changes require support. This leaves no ambiguity about when to invoke the tool.

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

All Metadata MCP Connector toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources