Skip to main content
Glama
Sign In

Convika

by com.convika
OverviewDiscussionsAdmin

Set page URL

set_site_url
Idempotent

Assign a full URL to a Convika landing page, including custom-domain paths such as https://www.example.com/ or https://www.example.com/lp2.

Use this when the user asks to create, move, preview, or publish a page at a specific URL. Prefer this over setup_custom_domain when a path is included.
- A root URL such as https://example.com/lp2 is connected as https://www.example.com/lp2: www.example.com is the site, and example.com redirects to it (301, path kept) once the user adds the records in guidance.rootRedirect (A @ to Convika's IPv4, CNAME www). If example.com already shows another site, Convika connects only www and leaves example.com alone; guidance.rootRedirect says so. If the response has guidance.rootNotServed instead, example.com won't open the page: tell the user to share the www URL.
- If the site is new, Convika creates the custom-domain claim and returns the CNAME routing record plus TXT ownership record.
- If the site is already connected to this workspace, Convika only adds the path route. An active site needs no DNS work. A site still pending verification keeps the CNAME and TXT values from its first setup: the response repeats them, and the TXT value stays the same across calls.
- invalid_hostname means the site can't be used as a custom domain (for example, reserved names such as anything.example.com). Ask the user for a site on a domain they own. It is not a DNS delay and not a Convika-side fault.
- If another workspace has a pending claim, Convika can still start DNS control verification for this workspace; pending claims are not ownership.
- If another workspace actively manages the site, do not take over automatically. Explain the options: ask for an invite, use another domain, or explicitly start DNS control verification and activate handover.
- Path routing is exact: /lp2 and /lp2/ normalize to the same route, but /lp2/thanks is a different route.
- If guidance.existingSite is present, another site shows there now and connecting would replace that whole site. Tell the user before any DNS change, as the text says.
- After this tool succeeds, use create_preview; the preview response can use the assigned URL path.

Input Schema

NameRequiredDescriptionDefault
urlYesThe full URL to assign, for example 'https://www.example.com/' or 'https://www.example.com/lp2'. Query strings and hashes are ignored.
siteIdYesThe ID of the page to assign the URL to
makePrimaryNoWhether this URL should become the page's canonical/primary URL. On a domain not connected yet, it becomes primary once the domain connects (route.mainOnConnect true, isPrimary false until then).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / makePrimary / description
      Previous value: -"Whether this URL should become the page's canonical/primary URL."New value: +"Whether this URL should become the page's canonical/primary URL. On a domain not connected yet, it becomes primary once the domain connects (route.mainOnConnect true, isPrimary false until then)."
  2. Changed2 schema fields changed
    • changedInput schema / properties / makePrimary / description
      Previous value: -"Whether this URL should become the site's canonical/primary URL."New value: +"Whether this URL should become the page's canonical/primary URL."
    • changedInput schema / properties / siteId / description
      Previous value: -"The ID of the site to assign the URL to"New value: +"The ID of the page to assign the URL to"
  3. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations only cover the safety profile (non-read-only, idempotent, non-destructive); the description adds substantial undisclosed behavior: returned CNAME/TXT records for new sites, 301 root redirect semantics, path-level idempotency of already-connected sites, stable TXT values across calls, and multi-workspace claim/handover states. It also discloses a consequence the annotations do not (guidance.existingSite means connecting would replace a whole site) and instructs the agent to warn the user first.

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 first two sentences front-load what the tool does and when to prefer it, and the bullets are each tied to an actionable condition rather than filler. It is long (ten bullets) and a few edge cases (pending claim by another workspace) read as documentation detail rather than selection guidance, costing a point.

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?

There is no output schema, and the description compensates by naming the response fields the agent must branch on (guidance.rootRedirect, guidance.rootNotServed, guidance.existingSite) and the follow-up tool. For a DNS-affecting mutation with cross-workspace edge cases, nothing needed to call or interpret it correctly is missing.

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 all three parameters are already documented, including makePrimary's deferred-primary behavior on unconnected domains. The description goes beyond the schema with route semantics — '/lp2' and '/lp2/' normalize to the same route but '/lp2/thanks' is distinct — which is meaningful invocation-relevant behavior rather than restatement.

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?

Opens with a specific verb+resource: 'Assign a full URL to a Convika landing page, including custom-domain paths', with two concrete URL examples. It also names the sibling it should not be confused with (setup_custom_domain) and the condition that separates them, so the agent can route without opening schemas.

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?

Explicit when-to-use ('when the user asks to create, move, preview, or publish a page at a specific URL'), an explicit alternative with a discriminator ('Prefer this over setup_custom_domain when a path is included'), and a follow-up step ('After this tool succeeds, use create_preview'). Branch-specific guidance is also given for error codes and blocked scenarios.

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

All Convika 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