Skip to main content
Glama

LivePage · 活页

by com.24haowan
OverviewDiscussionsAdmin

Send the user’s feedback to the LivePage team

send_feedback_to_livepage

Send the user’s opinion, problem or feature wish about LivePage itself (this platform) to the LivePage team — not a comment on a page (that is add_external_feedback). ★ First write what you would send as a short draft and show it to the user; call this only after they explicitly agree, and pass user_confirmed=true. If they have not agreed, or were only venting without asking to send feedback, do not call it. Write text in the user’s own sense; do not invent opinions, and never include page content, reader information, tokens or passwords. The platform attaches which agent is calling, the related pages / version (about) and the last tool that failed on this connection with its error code, so there is no need to describe the environment in text. When a display problem is hard to describe: pass version_id (from list_versions) for the version where it shows, so the team can open that exact version; attachment adds one screenshot (png / jpeg / webp / gif, ≤5 MB) — declare only mime and size, then PUT the image unchanged to attachment_upload.put_url from the result (Content-Type as in headers, valid for 15 minutes); without a terminal you cannot upload it, so do not attach. Pass contact_ok=true only when the user explicitly says the team may contact them or wants to talk it through: the LivePage team will reach them via the phone / email already bound to their account (do not put contact details in text); if they did not say so, omit it and do not ask just to fill it. Returns id and status; use list_my_feedback later for status and our reply. If the user wants a person rather than to leave a suggestion, do not use this — give them the support link from the server instructions.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
textYesThe text the user agreed to send (up to 2000 characters).
aboutNoThe proposal_id or version_id of the related page (optional).
sourceNohint = the user is sending this after seeing the “you can send feedback” line (feedback_hint) at the end of a publish result; omit otherwise.
categoryNobug = something broke or is hard to use; idea = a feature they want; other = anything else (default).
attachmentNoAttach one screenshot (optional): the result carries attachment_upload; PUT the image there as it says.
contact_okNo用户明确同意方案空间团队联系他（用账号已绑定的手机号 / 邮箱）才传 true；没说就不传
version_idNoThe version_id of the version where the problem shows (optional, from list_versions); the team will open that exact version.
user_confirmedYesThe user has seen the draft and agreed to send it. Pass true only when they really did.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.7/5.0
Behavior5/5

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

Annotations only cover safety hints (readOnlyHint=false, idempotentHint=false, destructiveHint=false, openWorldHint=false). The description goes far beyond: it explains a two-step confirmation dance, what the platform auto-attaches, the upload flow with a 15-minute URL, the 5 MB limit, the no-terminal limitation, that the team reaches out via account-bound contacts, and what the return value contains.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loads the core purpose, but the paragraph is long and packs many procedural rules into dense prose, which can be hard to parse quickly. Every sentence carries useful information, but the structure could be tightened without losing meaning.

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?

Covers the full lifecycle: draft‑show‑agree step, prerequisites for each optional field, the attachment PUT flow with validity window, what the platform attaches automatically, what the return value includes, how to check status later, and when to redirect to support. No output schema exists, and the description adequately describes the return (id and status).

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 description coverage is 100%, so the baseline is 3. The description adds procedural meaning beyond the schema: the meaning of user_confirmed (must reflect real agreement), contact_ok (only pass when explicit consent given), version_id (to pinpoint a display problem), and how attachment works. It enriches rather than repeats.

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 (send), resource (user's feedback about LivePage itself), and recipient (the LivePage team). It explicitly distinguishes itself from the sibling add_external_feedback by clarifying that this is not a comment on a page.

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 when-to-use (after the user sees a draft and agrees), when-not-to-use (if they were venting, or want a person instead of leaving a suggestion, use the support link), and names the sibling alternative add_external_feedback. Conditions for user_confirmed, contact_ok, and attachment feasibility are all spelled out.

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

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