dForms

Update a workspace link page

update_link_page

DestructiveIdempotent

Change a workspace link page: the default one unless page_id names another. page replaces the whole content: a field left out is no longer set. The page sent is usually what get_link_page returned, with only the requested change. Fields: enabled, name, bio, logo (absent: the brand kit logo; null: none; else an http(s) URL), items (ordered, at most 30: {type:"form", formId} or {type:"link", label, url}), socials (instagram, x, youtube, tiktok, and whatsapp with its country code) and colors (primaryColor, background, foreground as hex; absent: the brand kit's). WhatsApp is stored as digits and get_link_page returns it with its + again, so send it back as read. Fonts come from the workspace brand kit: change them with update_brand_kit. With page_id, name, slug (the old address keeps redirecting) and make_default can change too. With enabled false, public_url answers 404. Without page_id, page: null deletes the default page when it is the only one; delete other pages with delete_link_page. Destructive: it deletes or replaces data, so it is best confirmed with the user first, naming exactly what will change. After an error or a timeout, a read shows whether the change went through, so a blind retry is not needed. Any member can use it.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "update_link_page"
  }
}

Input Schema

Name	Required	Description
`name`	No	An internal name to tell pages apart ("Expo 2026"). Visitors never see it.
`page`	No	The whole page content, as get_link_page returned it with your changes. Without page_id, null deletes the default page (only when it is the workspace's only page). With page_id, absent keeps the content as it is.
`slug`	No	A new address after /p/. The old one keeps redirecting to it. Needs page_id.
`page_id`	No	The page id, from list_link_pages. Absent: the default page, the one at /{accountCode}.
`make_default`	No	true makes this page the one at /{accountCode}. Needs page_id, and the page must be published (enabled true).
`workspace_id`	No	The workspace this call acts in: an id from list_my_workspaces. Required for a person signed in with several workspaces and for staff of this deployment; optional with an API key or with only one workspace.

Output Schema

Name	Required	Description
`live`	Yes	True when the page is saved with enabled: true, so public_url serves it. False: public_url answers 404.
`name`	Yes	The internal name; blank when nobody named it.
`page`	Yes	The stored page, ready to send back to update_link_page after changing it; null when there is none.
`slug`	Yes	The page slug; the default page is served at /{accountCode} whatever its slug.
`forms`	Yes	The workspace forms a form button can point at, by id.
`page_id`	Yes	The page id; null when the workspace has no page yet.
`brand_kit`	Yes	The brand kit the page takes its type, default colors and default logo from.
`workspace`	Yes	The workspace this call acted in, to compare with the one the user means.
`is_default`	Yes	True for the page at /{accountCode}.
`public_url`	Yes	The page address, to give to users exactly as returned; null when the deployment has no public address.
`account_code`	Yes	The workspace code the pages live under.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 13, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations already flag destructiveHint=true and idempotentHint=true, but the description adds real behavior: replace-whole-content semantics (an omitted field is no longer set), enabled:false makes public_url answer 404, the old slug keeps redirecting, and any member may call it. It also covers failure handling — after an error or timeout, read to check rather than blindly retry — and that the change should be confirmed with 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?

One dense paragraph, but front-loaded with the operation and target, then the replace semantics, then edge cases, then alternatives. Practically every sentence carries behavior, though the inline field inventory (socials, colors, items) partly duplicates schema text and the block would scan better if broken up.

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?

For a 6-parameter mutation with a recursive page payload, it covers target selection, replace-vs-keep semantics, the delete path and its precondition, publish/404 consequences, permissions, and post-error verification. Return shape is covered by the output schema, so nothing an agent needs in order to call 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 the schema already defines every field, which sets a baseline of 3. The description still earns credit for cross-field semantics the schema can't express on its own: absent-vs-null for logo (brand kit / none / URL), the whatsapp digits round-trip with get_link_page, and the 'usually patch the get_link_page result' workflow. It largely restates field lists the schema already covers, so 4 rather than 5.

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 ('Change a workspace link page') and immediately disambiguates the target: the default page unless page_id names another. That single clause separates it from every sibling page tool without needing their 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?

It routes explicitly across alternatives: fonts go to update_brand_kit, non-default pages are removed with delete_link_page, and the page content to send is what get_link_page returned. It also states the conditions under which the destructive null form is legal (only the default page, only when it is the workspace's only one).

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

All dForms tools Inspect

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

Need Help?