twocents

Server Details

Human feedback for AI agents: share HTML, get a live review link, read anchored notes as markdown.

If you are the author of this connector, you can claim ownership by verifying the domain or GitHub account it belongs to. Claimed connector authors can inspect health checks, view analytics, and manage their listing.

Status: Healthy
Uptime: 100.0% over 55 days
Last Tested: 2026-10-11 04:24
Transport: Streamable HTTP · MCP 2025-06-18
URL
Repository: twocents-page/twocents-mcp
GitHub Stars: 0
Server Listing: twocents

TDQS

A4.6/5.0

Scored 2026-10-03 17:15 across 4 tools

Disambiguation5/5

Each tool has a sharply distinct purpose: publish (share_page/share_pages), read (get_feedback), and close the loop (resolve_feedback). The only near-overlap is share_page vs share_pages, and the description explicitly resolves it ('use this instead of calling share_page N times whenever you have more than one page'). An agent can select correctly without hesitation.

Naming Consistency5/5

All four tools follow a clean verb_noun snake_case pattern: get_feedback, resolve_feedback, share_page, share_pages. The singular/plural distinction maps directly onto the single-page vs multi-page semantics, so the naming is both consistent and informative, with no mixed conventions.

Tool Count5/5

Four tools cover a tight, complete review loop—publish, collect, resolve—plus a batch variant for multi-page sets, so every tool earns its place with no redundancy. Nothing feels padded or missing at the count level.

Completeness4/5

The core lifecycle is fully covered: create (share_page/share_pages), read (get_feedback), and update/resolve (resolve_feedback with reopen via resolved:false). Minor gaps remain—there is no tool to list or manage existing rooms, and large corpora require a documented out-of-band curl uploader rather than an MCP tool.

Available Tools

4 tools

get_feedbackGet reviewer feedback for a shared pageAInspect

Fetch the reviewer notes for a page shared with share_page, as markdown grouped by page. Each note carries the anchored text, the element and its markup as the reviewer saw it, so you can locate and apply it; each page heading carries a URL to read the whole page back, so you never have to guess which file it is. Show your human each new note and apply only the ones they approve. Pass the note ids already decided in earlier sessions as "handled" to see only what is new.

ParametersJSON Schema

Name	Required	Description	Default
`room`	Yes	The room id returned by share_page.
`handled`	No	Note ids the creator already decided on (applied or skipped) — e.g. the keys of a saved .twocents/decisions.json. These are summarized in one line each instead of repeated in full, so the response leads with what still needs a decision.

TDQS

A4.9/5.0

Behavior5/5

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

With no annotations provided, the description carries full disclosure burden and meets it exceptionally: it details what the output contains (anchored text, element, markup, URL per heading), how it is structured, and the intended interactive workflow. It goes far beyond a simple 'fetch' and prepares the agent for real usage.

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?

Three sentences, each dense with purpose: the first states the core function and format, the second details the note contents and page URLs, and the third gives operational guidance. No filler, perfectly front-loaded.

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?

Despite no output schema, the description clearly explains the return format (markdown grouped by page, note details, URLs). It covers both parameters contextually and provides a complete workflow for an agent, leaving little ambiguity for a tool with this moderate complexity.

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 schema already documents 'room' and 'handled'. The description adds meaningful context for 'handled' by explaining it represents previously decided note ids and that such notes appear summarized rather than in full, which goes beyond the schema's field description.

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 verb ('Fetch') and resource ('reviewer notes for a page shared with share_page'), and adds useful detail (markdown, grouped by page). It clearly distinguishes from the sibling share_page by focusing on retrieval rather than creation.

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?

It explicitly ties usage to pages shared via share_page, explains the workflow (show human, apply only approved notes), and instructs how to use the 'handled' parameter to filter previously decided notes. This gives clear when and how, even without naming alternatives beyond the sibling.

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

resolve_feedbackMark reviewer notes as addressedAInspect

Mark notes resolved once you have actually applied them. This is what closes the loop: the note leaves the active list for every later get_feedback, and the reviewer who wrote it sees it marked resolved on the page — live, if they have it open — instead of finding their old note sitting next to content you already fixed. Pass "what" you changed; that sentence is shown to the reviewer, so write it for them, not for the log. Requires the creatorKey that share_page returned when the room was created — the review link alone cannot resolve, or any reader could clear feedback that was not theirs. Nothing is deleted: call again with resolved:false to reopen a note.

ParametersJSON Schema

Name	Required	Description
`by`	No	Who applied it, if you want it credited. Max 80 chars.
`ids`	Yes	Note ids to resolve — the `id:` field of each note in get_feedback output.
`room`	Yes	The room id the notes belong to.
`what`	No	One sentence on what you changed, shown to the reviewer beside their note. Max 400 chars.
`resolved`	No	Defaults to true. Pass false to reopen a note you resolved by mistake.
`creatorKey`	Yes	The room's creator key, returned by share_page when the room was created and kept in .twocents/state.json. For a room created before creator keys existed, the first key you present claims the room.

TDQS

A4.7/5.0

Behavior5/5

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

With no annotations provided, the description carries the full burden and does so excellently. It discloses that notes disappear from later get_feedback results, the reviewer sees the resolution live, nothing is deleted, and resolved:false reopens a note. It also explains the security rationale for requiring creatorKey.

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 front-loaded with the core purpose and every sentence adds distinct value: trigger condition, system effect, payload guidance, authentication requirement, and reversibility. There is no filler or repetition.

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 a mutation tool with six parameters and no output schema, this is complete: it covers when to use it, what payload to write, the required credential, the behavioral impact on get_feedback, and how to undo the action. No critical calling information 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 the baseline is 3. The description adds meaning beyond the schema by explaining that 'what' is shown directly to the reviewer and should be written for them, that creatorKey comes from share_page and can claim legacy rooms, and that resolved:false reopens. This exceeds baseline.

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 states a specific action ('mark notes resolved'), the target object ('reviewer notes'), and the concrete effect ('leaves the active list for every later get_feedback'). This clearly distinguishes it from sibling tools get_feedback, share_page, and share_pages.

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?

It says when to call: 'once you have actually applied them,' and it gives an important prerequisite: the creatorKey is required and the review link alone cannot resolve. It does not explicitly list alternative-tool routing, but no sibling is a true alternative to resolving feedback, so the context is sufficient.

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

share_pageShare a page for visual feedbackAInspect

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.

ParametersJSON Schema

Name	Required	Description
`html`	No	A complete, self-contained HTML document (inline CSS/JS/images — no local file references, they will 404 for reviewers). Max ~120 KB.
`path`	No	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.
`room`	No	Room id from a previous share_page call, to update that page. Omit to create a new room.
`source`	No	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.
`forkable`	No	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.
`markdown`	No	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.
`creatorKey`	No	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.

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.

share_pagesShare a whole set of pages in one requestAInspect

Publish a multi-page set — an entry page plus the pages it links to — into one room as a single atomic operation. Either the whole set lands or nothing changes, so a reviewer never opens a page whose links point at pages that were never stored. Use this instead of calling share_page N times whenever you have more than one page. Note the ceiling: a room is a review set, not a host — it holds 200 pages and 6 MB total. For a large generated corpus, share the entry points a human would actually read and link out to the rest; nobody pins notes on four hundred pages. If the pages are already files on disk, prefer the uploader — it reads them from the folder instead of making you emit every byte: curl -fsSL /agent.mjs -o .twocents/agent.mjs && FBL_ROOM= node .twocents/agent.mjs --publish

ParametersJSON Schema

Name	Required	Description
`room`	No	Room id to publish into. Omit to create a new room.
`entry`	No	Which page reviewers land on, if it is not already "index.html". Must be one of the paths in "pages"; its content is also stored as index.html so the review link opens it.
`pages`	Yes	The pages of this set. Each item needs a "path" (the filename in the room, e.g. "index.html" or "plan.md") plus exactly one of "html" or "markdown". Link between them with plain relative hrefs; formats mix freely.
`prune`	No	Delete pages already stored in this room that are not in this request. Use it when republishing a set whose layout changed, so stale pages from the old layout do not linger unreachable. Default false — without it a room only ever accretes.
`forkable`	No	Whether reviewers may take their own copy of this set (default true). Pass false to hide the Fork button and make the fork command refuse. A stated intent, not a lock.
`creatorKey`	No	Only to change "forkable" on a room created in an earlier session.

TDQS

A4.5/5.0

Behavior4/5

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

No annotations are provided, so the description carries the full burden, and it does real work: atomicity ('either the whole set lands or nothing changes'), hard ceilings (200 pages, 6 MB), accretion-by-default behavior, and the caveat that 'forkable' is 'a stated intent, not a lock'. It omits auth/permission requirements and what the call returns (room id, review link), which leaves a gap for a write operation.

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?

Core semantics — atomic multi-page publish and its relationship to share_page — are front-loaded, and every sentence carries information. The embedded curl/node invocation in the final sentence is useful routing but the longest, most expendable block.

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?

For a 6-parameter mutation tool with no annotations and no output schema, the description covers atomicity, limits, prune/forkable behavior, and alternatives. The main omissions are the return payload (no output schema, and the description never says what identifiers come back) and any auth/permission note.

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 meaning the schema does not: the 200-page/6 MB ceiling that constrains 'pages', the rationale for 'prune' (stale pages from an old layout lingering), and the semantic nature of 'forkable' as intent rather than enforcement. That is genuine value on top of the structured fields.

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 — 'Publish a multi-page set... into one room as a single atomic operation' — and immediately distinguishes itself from the sibling share_page ('Use this instead of calling share_page N times whenever you have more than one page'). An agent can pick between share_page and share_pages 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?

Names the alternative (share_page), the condition that selects this tool (more than one page), an exclusion case (large corpora should share entry points only), and a competing alternative for a different input shape (the uploader/CLI for pages already on disk). This is explicit when-to-use, when-not-to-use, and alternative routing.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

2 tool updatesOct 3, 2026

Changedshare_page2 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"
+}

Changedshare_pages2 fields changed

addedInput schema / properties / creatorKey

Added value: +{
+  "description": "Only to change \"forkable\" on a room created in an earlier session.",
+  "type": "string"
+}

addedInput schema / properties / forkable

Added value: +{
+  "description": "Whether reviewers may take their own copy of this set (default true). Pass false to hide the Fork button and make the fork command refuse. A stated intent, not a lock.",
+  "type": "boolean"
+}

1 tool updateSep 2, 2026
- Addedresolve_feedback

2 tool updatesSep 2, 2026

Changedshare_page1 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."

Addedshare_pages

1 tool updateAug 6, 2026

Changedshare_page5 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: +[]

1 tool updateJul 24, 2026

Changedget_feedback1 field changed

addedInput schema / properties / handled

Added value: +{
+  "description": "Note ids the creator already decided on (applied or skipped) — e.g. the keys of a saved .twocents/decisions.json. These are summarized in one line each instead of repeated in full, so the response leads with what still needs a decision.",
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}

2 tool updatesJul 22, 2026
- First observedget_feedback
- First observedshare_page

Related MCP Connectors

MarigoldOAuth
io.github.immuneeb
Comment on AI-generated webpages; feedback flows back to your coding agent. Free, MIT, local-first.
Developer Tools Browser Automation AI & Machine Learning
2
Artifact ShareOAuth
com.artifactshare
Share HTML and Markdown files from AI agents within your company, with versions and comments.
Workplace & Productivity Content Management Systems Cloud Storage
132
MarkupBase AOAuth
com.markupbase.mcp
MarkupBase turns AI-generated Markdown and HTML into durable, versioned artifacts that people can review and discuss. Its MCP server lets agents publish new versions, preserve contextual comments, include hosted images, and respond to feedback through secure account-linked identities, creating a clear human review boundary without requiring real-time editing.
Content Management Systems RAG Systems Workplace & Productivity
122
ShareMyPageOAuth
app.sharemypage
Host the HTML or Markdown pages your AI generates and share each as a link with comments and access.
Content Management Systems
2

Related MCP Servers

Terrarium
Developer Tools Project Management
nelsonsantryhkd
F
license
Not graded
quality
F
maintenance
Enables AI agents to publish HTML artifacts for human review, receive anchored feedback, and iterate until approval.
Updated 3 months ago (2026-07-07 13:33 UTC)
2
-
anno
Developer Tools Testing & QA Tools Coding Agents
philmingdao
A
license
Not graded
quality
A
maintenance
Local-first HTML review workspace for AI coding agents, enabling direct text and formatting edits, element comments, area annotations, and slide-aware review with durable agent handoffs.
Updated 2 months ago (2026-08-22 03:13 UTC)
MIT
mcp-clickcast
Browser Automation Testing & QA Tools Image & Video Processing
AlexKay28
A
license
Not graded
quality
A
maintenance
Give AI agents visual + structured feedback about live web UIs — and give humans deterministic demo reels while you're at it.
Updated a month ago (2026-09-14 13:33 UTC)
90 PyPI
3
Apache 2.0
web-artefacts
Developer Tools
lbug
A
license
Not graded
quality
A
maintenance
Enables coding agents to publish HTML artifacts that users can review and comment on in a sandboxed browser viewer, with feedback loop support for iterative versions.
Updated 6 days ago (2026-10-04 18:44 UTC)
234 npm
MIT

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.

Server Details

Available Tools

Tool Schema Changelog

Related MCP Connectors

Related MCP Servers

Glama MCP Gateway

Resources