Skip to main content
Glama

dForms

Create a workspace link page

create_link_page

Add a public page to the workspace (at most 20), for an event, a channel or a country. It lives at /{accountCode}/p/{slug}, except the workspace's first page, which becomes the default at /{accountCode}. page takes the same fields as update_link_page; absent, the page starts empty and unpublished. 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": "create_link_page"
  }
}

Input Schema

NameRequiredDescriptionDefault
nameNoAn internal name to tell pages apart ("Expo 2026"). Visitors never see it.
pageNoThe page content. Absent: the page starts empty and unpublished.
slugNoThe address after /p/. Absent: one is made from the name.
workspace_idNoThe 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

NameRequiredDescriptionDefault
liveYesTrue when the page is saved with enabled: true, so public_url serves it. False: public_url answers 404.
nameYesThe internal name; blank when nobody named it.
pageYesThe stored page, ready to send back to update_link_page after changing it; null when there is none.
slugYesThe page slug; the default page is served at /{accountCode} whatever its slug.
formsYesThe workspace forms a form button can point at, by id.
page_idYesThe page id; null when the workspace has no page yet.
brand_kitYesThe brand kit the page takes its type, default colors and default logo from.
workspaceYesThe workspace this call acted in, to compare with the one the user means.
is_defaultYesTrue for the page at /{accountCode}.
public_urlYesThe page address, to give to users exactly as returned; null when the deployment has no public address.
account_codeYesThe workspace code the pages live under.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.1/5.0
Behavior4/5

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

Goes beyond the annotations (readOnlyHint=false, openWorldHint=true, idempotentHint=false, destructiveHint=false) by disclosing a quota ceiling, the permission scope ("Any member can use it"), the default-unpublished state, and the notable side effect that a workspace's first page becomes publicly reachable at /{accountCode}. What it does not say is what the failure mode looks like at the 20-page limit.

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?

Single tight paragraph with the resource, cap, and URL rule front-loaded; nothing is filler. The clause about page taking update_link_page's fields is useful but slightly duplicative 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?

For a nested-object create tool with an output schema and full annotations, the description covers quota, URL layout, publishing default, and auth scope. Remaining gaps are edge behavior (hitting the 20-page cap, slug collision handling) rather than things needed for a correct first call.

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; the description adds meaning to slug by explaining the resulting public URL and the special first-page routing rule to /{accountCode}. It also ties page to update_link_page's field set, though the empty/unpublished default it mentions is already stated in the schema.

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 ("Add a public page to the workspace") plus the domain it serves (event, channel, country) and the cap of 20. Naming the sibling update_link_page and the URL shape makes it distinguishable from get_link_page/duplicate_link_page without opening a schema.

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?

Gives clear context (creation, at most 20 pages, first page becomes the workspace default, any member may call it) but never states when to choose update_link_page or duplicate_link_page instead, or what to do once the 20-page cap is reached. Usage is implied rather than routed.

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.

Resources