LivePage · 活页

Read rows appended by viewers

list_data_rows

Read-onlyIdempotent

Read rows viewers appended to a data table from the page (plain form, POST ./_data/ or the SDK space.data.append; sign-ups, check-ins, votes, feedback), newest first. Each row carries its status (approved: passed moderation, visible to viewers; held: flagged by moderation, visible only to the publisher), who submitted it (by: a member is {kind:member, user_id, role, nickname}, a visitor is {kind:visitor}), device, time, and the page version and data version at write time. These rows are not in get_data rows and are never overwritten by set_data; to merge them into the base table, read them back and replace the table with set_data. Visitor rows have device and time only: they do not identify people and must not be read as intent. Filter by table or status; limit defaults to 100, at most 500. Pass since (the next_since from the last reply, a row_id, or an ISO time) to get only newer rows, oldest first. Rows a submitter withdrew from the page are still listed, with withdrawn_at (the page read no longer shows them; the content stays with you). When the form has image fields each row also carries images: { field: [{ id, url, thumb_url, width, height, blocked }] } — url works for one hour and opens the image directly; blocked = image moderation flagged it (so the row is held). Act on a held row with set_data_row_status. On location check-in tables with keep_coords, each row also carries location: { lat, lng, coord: gcj02, located_at, expires_at } (null once 30 days after the check-in have passed).

Input Schema

Name	Required	Description
`limit`	No	默认 100
`since`	No	Only rows after this point (oldest first): the next_since from the last reply, a row_id, or an ISO time
`table`	No	只看这张表；不传 = 全部表
`status`	No	approved = 过审、读者可见；held = 审核命中、只有你看得到
`proposal_id`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 13, 2026

addedInput schema / properties / since

Added value: +{
+  "description": "Only rows after this point (oldest first): the next_since from the last reply, a row_id, or an ISO time",
+  "maxLength": 64,
+  "minLength": 1,
+  "type": "string"
+}

First observedOct 6, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations only declare readOnly/idempotent, yet the description adds substantial behavior: rows are returned newest first but oldest first when since is passed, held vs approved visibility, withdrawn rows remain listed with withdrawn_at, image URLs expire in one hour, and location coordinates null out 30 days post check-in. It also warns that visitor rows carry no identity and must not be read as intent.

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?

It is front-loaded with purpose and the get_data/set_data relationship, and nearly every sentence carries information an agent needs (status values, withdrawal semantics, image and location payloads). It is a dense single paragraph, though, and the payload-shape details would read better as structured lines than run-on prose.

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 carries the full burden of describing return values and does so thoroughly: per-row status, submitter shape (member vs visitor), device, time, versions, plus conditional images and location objects. Nothing an agent needs to interpret a reply 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?

The description clarifies semantics the schema only sketches: limit defaults to 100 and caps at 500, since accepts the returned next_since, a row_id, or an ISO time, and crucially that since flips ordering to oldest first. Only proposal_id gets no explanation in either the description or the schema, a minor gap at 80% coverage.

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 ("Read rows viewers appended to a data table from the page") and immediately scopes it against the sibling read tool: "These rows are not in get_data rows and are never overwritten by set_data." An agent can distinguish this from get_data without opening either schema.

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?

Gives explicit alternatives and the condition that selects them: use set_data to merge these rows into the base table, and set_data_row_status to act on a held row. It also names the filtering and pagination affordances (table/status, since) that define when this call is the right one.

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?