Skip to main content
Glama

twocents

by page.twocents
OverviewDiscussionsAdmin

Share a page for visual feedback

share_page

Share a page or document and get back a review link to send to people. Pass "html" for a self-contained page, or "markdown" for a plan, spec, PR description or report — markdown is rendered to a styled, readable document for you, so prefer it whenever the thing you want a human to approve is prose rather than a built page. Reviewers open the link and pin notes directly on it — no login or install. Call again with the same room id to update the page; connected reviewers see the update live. Use get_feedback to collect the notes. Rooms are sticky per project: if the project has a .twocents/state.json, pass its room id instead of creating a new room, so the review link stays stable across sessions.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
htmlNoA complete, self-contained HTML document (inline CSS/JS/images — no local file references, they will 404 for reviewers). Max ~120 KB.
pathNoFor multi-page sets: the filename this content lives at in the room (e.g. "about.html" or "plan.md"). Defaults to "index.html", the page reviewers land on. For a set of more than one page prefer share_pages, which publishes them all in one atomic request — sharing them one call at a time can leave a half-published room whose links point at pages that were never stored.
roomNoRoom id from a previous share_page call, to update that page. Omit to create a new room.
sourceNoWhere this content came from, for whoever reads the feedback later — a project path like "DROPS.md" or "public/p/foo/index.html", or a note like "drafted in this conversation, not yet a file". You are the only one who knows this: twocents receives HTML, never a path, so if you omit it a future session gets reviewer notes with nothing to point them at the right file. get_feedback echoes it back verbatim.
markdownNoMarkdown to render as a document, instead of "html". Use this for plans, specs, PR descriptions, summaries — anything you want a human to read and approve before you act. Pass exactly one of html or markdown. Max ~120 KB.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / path / description
      Previous value: -"For multi-page sets: the filename this content lives at in the room (e.g. \"about.html\" or \"plan.md\"). Defaults to \"index.html\", the page reviewers land on. Share the other files into the same room id and link between them with plain relative hrefs — formats can be mixed freely, so a plan.md may link to a demo.html and back."New value: +"For multi-page sets: the filename this content lives at in the room (e.g. \"about.html\" or \"plan.md\"). Defaults to \"index.html\", the page reviewers land on. For a set of more than one page prefer share_pages, which publishes them all in one atomic request — sharing them one call at a time can leave a half-published room whose links point at pages that were never stored."
  2. Changed5 schema fields changed
    • addedInput schema / anyOf
      Added value: +[
+  {
+    "required": [
+      "html"
+    ]
+  },
+  {
+    "required": [
+      "markdown"
+    ]
+  }
+]
    • addedInput schema / properties / markdown
      Added value: +{
+  "description": "Markdown to render as a document, instead of \"html\". Use this for plans, specs, PR descriptions, summaries — anything you want a human to read and approve before you act. Pass exactly one of html or markdown. Max ~120 KB.",
+  "type": "string"
+}
    • changedInput schema / properties / path / description
      Previous value: -"For multi-page sites: the filename this HTML lives at in the room (e.g. \"about.html\"). Defaults to \"index.html\", the page reviewers land on. Share the other pages into the same room id and link between them with plain relative hrefs."New value: +"For multi-page sets: the filename this content lives at in the room (e.g. \"about.html\" or \"plan.md\"). Defaults to \"index.html\", the page reviewers land on. Share the other files into the same room id and link between them with plain relative hrefs — formats can be mixed freely, so a plan.md may link to a demo.html and back."
    • addedInput schema / properties / source
      Added value: +{
+  "description": "Where this content came from, for whoever reads the feedback later — a project path like \"DROPS.md\" or \"public/p/foo/index.html\", or a note like \"drafted in this conversation, not yet a file\". You are the only one who knows this: twocents receives HTML, never a path, so if you omit it a future session gets reviewer notes with nothing to point them at the right file. get_feedback echoes it back verbatim.",
+  "type": "string"
+}
    • changedInput schema / required
      Previous value: -[
-  "html"
-]New value: +[]
  3. First observed

TDQS

A4.7/5.0
Behavior5/5

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

With no annotations, the description carries the full disclosure burden and does so thoroughly: it reveals that markdown is rendered into a styled document, that the result is a review link, that reviewers need no login/install, that updates propagate live, and that rooms are sticky per project via .twocents/state.json. This gives an agent a strong behavioral model beyond the raw schema.

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

Conciseness5/5

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

The description is long but every sentence earns its place: core action, format choice, reviewer experience, update semantics, feedback collection, and project stickiness. The front-loaded first sentence states the purpose immediately, and no content is redundant with the schema.

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?

The description covers the return value (review link), the main invocation choice, update behavior, project persistence, and the feedback-collection handoff. Combined with the schema's ownership of parameter details and the share_pages recommendation in the path property, nothing essential is missing for correct invocation.

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, but the description adds practical meaning beyond the schema: when to prefer markdown over html, why source provenance matters, and why a project room id should be reused. It reinforces and contextualizes the parameters rather than just restating their names.

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?

The description opens with a specific action and object — 'Share a page or document and get back a review link' — and clearly positions the tool as a visual-feedback workflow. It also routes to get_feedback for collecting notes and refers to a single page/document, distinguishing it from the plural share_pages sibling.

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?

The description gives concrete when-to-use guidance: prefer markdown for prose needing human approval, use html for built pages, call again with the same room id to update, and use get_feedback to collect notes. It does not explicitly mention the share_pages alternative in the main description, though the schema's path property covers that exclusion.

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

All twocents 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