LivePage · 活页

Define a form / order block

set_form

Idempotent

Attach a form viewers can fill in (sign-ups, orders, bookings, leads) to a page: you only define the fields; the platform renders the form in the reading page (mobile-friendly, validated), and each submission lands as a row in this data table, readable with list_data_rows. No form code needed (a plain posting to ./_data/ works too). Idempotent: creates the table when absent, otherwise replaces the whole field definition (rows already collected are kept). fields: at most 20 items of { key, label, type, required?, options?, min?, max? }; six types: text (single line), textarea, select (options), multiselect (options, stored joined with 、), number (min / max), phone (11-digit mobile). amount is optional and only displays a price: { unit_price_cents, qty_field? (which number field holds the quantity) }; the platform computes the total as unit price × quantity and writes it into each row as _amount_cents — no money is collected (payment guidance and real payment are separate tools). Each row also carries _form_rev (the table version at submission time). Viewer write-back is open by default (append_open=true); pass false to close it. Submissions remain rate-limited and text is moderated first: approved rows appear for viewers on refresh, flagged rows are visible only to you in list_data_rows. Preview and presenter sessions never submit; the author and other workspace members can submit on the live page while signed in, and their rows record which member (by) without counting as a visitor. With members_only=true only members can submit and visitors do not see the form. Share the page after defining the form; the page does not need republishing.

Input Schema

TableJSON Schema

Name	Required	Description
`table`	Yes	表名，例如 signup、orders；提交的行落在这张表
`title`	No	表单标题，也是查看页里那枚按钮的字，例如「报名」「下单」；缺省「填写」
`amount`	No	显示金额；不传 = 不显示金额
`fields`	Yes	字段定义，按顺序渲染
`revision`	No	可选：get_data 返回的当前 revision，传了就防并发（不一致 409）；不传按当前修订写
`append_open`	No	读者写回开关，缺省 true；false = 表单不显示、提交被拒
`proposal_id`	Yes
`members_only`	No	Accept submissions from workspace members only (visitors do not see the form and get 403); omitted = keep the current value, false for a new table

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 13, 2026

addedInput schema / properties / members_only

Added value: +{
+  "description": "Accept submissions from workspace members only (visitors do not see the form and get 403); omitted = keep the current value, false for a new table",
+  "type": "boolean"
+}

First observedOct 6, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Far exceeds the annotations (which only mark idempotent/non-destructive). It discloses idempotency semantics (creates table if absent, otherwise replaces the whole field definition while keeping rows), rate-limiting, text moderation (approved vs flagged rows visibility), that preview/presenter sessions never submit, member write-back with 'by' attribution, and members_only behavior. Rich and non-obvious.

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?

Purpose is front-loaded and nearly every sentence carries unique information (idempotency, moderation, amount semantics). It is a dense single-paragraph wall of text for a complex tool, which slightly hurts scannability, but there is little filler to cut.

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 complex 8-param nested tool with no output schema, the description covers the full lifecycle: what it creates, how submissions are returned (list_data_rows), overwrite semantics, moderation, visibility, and account/session rules. Nothing an agent needs to call it correctly appears 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 high (88%, baseline 3), but the description adds real meaning: the six field types with their semantics, multiselect storage joined with '、', phone being an 11-digit mobile, the 20-item cap, and that amount only displays a price with the total written as _amount_cents. This goes beyond the schema field descriptions.

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+scope: 'Attach a form viewers can fill in ... to a page: you only define the fields; the platform renders the form.' It distinguishes itself from siblings by naming list_data_rows for reading submissions and explicitly noting payment is handled by 'separate tools,' so an agent can place this among ~60 siblings.

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

Usage Guidelines4/5

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

Gives clear context: use it to define fields, the platform renders/validates, submissions land as rows readable via list_data_rows, and it notes the plain <form> alternative plus that payment is separate. It also says to share the page after defining (no republish needed). No explicit 'do not use when' exclusions, but the when-and-how is well covered.

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

All LivePage · 活页 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?