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.
forkableNoWhether reviewers may take their own copy of this page to work on (default true). Pass false for something you are circulating for comment but do not want handed onward — it hides the Fork button and makes the fork command refuse. It is a stated intent rather than a lock: anyone holding the review link can already read the page.
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.
creatorKeyNoOnly needed to change "forkable" on a room you created in an EARLIER session — the key that share_page returned then. New rooms are claimed automatically.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • addedInput schema / properties / creatorKey
      Added value: +{
+  "description": "Only needed to change \"forkable\" on a room you created in an EARLIER session — the key that share_page returned then. New rooms are claimed automatically.",
+  "type": "string"
+}
    • addedInput schema / properties / forkable
      Added value: +{
+  "description": "Whether reviewers may take their own copy of this page to work on (default true). Pass false for something you are circulating for comment but do not want handed onward — it hides the Fork button and makes the fork command refuse. It is a stated intent rather than a lock: anyone holding the review link can already read the page.",
+  "type": "boolean"
+}
  2. 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."
  3. 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: +[]
  4. First observed

TDQS

A4.3/5.0
Behavior4/5

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

With no annotations, the description carries the burden and does well: it discloses that reviewers need no login or install, that connected reviewers see updates live, and that rooms are sticky per project via .twocents/state.json. It omits size/limit and any auth caveat, but the interaction model is otherwise clear.

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 outcome, then the mode choice, then the update/reuse workflow. Slightly long, and the markdown-rendering sentence largely repeats what the schema already states, but no sentence is filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers the return value (a review link) in lieu of an output schema and explains the multi-session room-reuse workflow needed to call it correctly. Does not mention share_pages for multi-page sets, though that guidance lives in the path parameter description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/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 schema already explains html, markdown, room, path, source, forkable and creatorKey in detail. The description adds the html/markdown selection heuristic, which is genuinely useful, but little beyond that.

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+resource (share a page/document, get back a review link) and immediately distinguishes the two content modes — self-contained 'html' vs prose 'markdown'. An agent can tell what it produces without reading the 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 routing rule ('prefer markdown whenever the thing you want a human to approve is prose rather than a built page'), states the update-in-place condition ('call again with the same room id'), and names the sibling to use afterwards ('use get_feedback to collect the notes').

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
Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources