Skip to main content
Glama
Sign In

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

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_okNoPass true only if the user explicitly agreed that the LivePage team may contact them (via the phone / email already bound to their account); omit otherwise.
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. Changed1 schema field changed
    • changedInput schema / properties / contact_ok / description
      Previous value: -"用户明确同意方案空间团队联系他（用账号已绑定的手机号 / 邮箱）才传 true；没说就不传"New value: +"Pass true only if the user explicitly agreed that the LivePage team may contact them (via the phone / email already bound to their account); omit otherwise."
  2. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations only say readOnlyHint=false and destructiveHint=false; the description supplies far more: the platform auto-attaches the calling agent, related pages/version, and the last failing tool with its error code, so the agent knows what not to duplicate. It also documents the two-step attachment flow (declare mime/size, then PUT to attachment_upload.put_url with a 15-minute validity and a no-terminal fallback), and states the return is id and status with list_my_feedback for follow-up.

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?

Front-loaded with the purpose and the ★ consent gate before any logistics, and each clause carries distinct operational content (consent, content limits, auto-attached context, attachment upload, contact opt-in, return value). It is dense and reads as one long paragraph, so a few clauses (e.g. the mime list) could be compressed, but there is little pure waste.

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 an 8-parameter mutation with a nested attachment object and no output schema, the description covers the consent contract, what the server attaches automatically, what must never be included (page content, reader info, tokens, passwords), the attachment mechanics, and what the call returns. Nothing an agent needs to invoke 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 baseline is 3, and the description goes beyond it: it explains when to pass version_id (from list_versions, for hard-to-describe display problems), the exact condition for contact_ok (only if the user explicitly permits contact, and don't ask just to fill it), the source="hint" origin from feedback_hint, and the consent semantics of user_confirmed. The attachment sub-object handling is described operationally rather than by field, which keeps it from a 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?

States a specific verb and resource (send the user's feedback about LivePage itself to the LivePage team) and explicitly delimits the scope against the nearest sibling: "not a comment on a page (that is add_external_feedback)". An agent can route between this and add_external_feedback 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 an explicit precondition (show a draft, call only after explicit agreement with user_confirmed=true) and an explicit negative case ("If they have not agreed, or were only venting without asking to send feedback, do not call it"). It also routes two alternatives: add_external_feedback for page comments and the server-instruction support link for users who want a person.

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