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 with GitHub, an HTTP challenge, or a DNS record. Claimed connector authors can inspect health checks, view analytics, and manage their listing.

Status: Healthy
Last Tested: 2026-09-21 03:50
Transport: Streamable HTTP · MCP 2025-06-18
URL
Repository: twocents-page/twocents-mcp
GitHub Stars: 0
Server Listing: twocents

TDQS

A4.9/5.0

Scored 2026-09-09 19:16 across 4 tools

Disambiguation5/5

Each tool has a clearly distinct job: share_page handles single documents, share_pages handles atomic multi-page publishing, get_feedback retrieves notes, and resolve_feedback updates their resolved state. The one potentially overlapping pair, share_page vs share_pages, is explicitly differentiated in the descriptions and by plural naming.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern: share_page, share_pages, get_feedback, resolve_feedback. The singular/plural distinction between share_page and share_pages is intentional and matches their actual behavior.

Tool Count5/5

Four tools is well-scoped for this review workflow: share content, share multi-page sets, fetch feedback, and resolve feedback. Each tool earns its place with no redundant utilities.

Completeness5/5

The set covers the full review loop: publishing/updating a page, publishing multi-page sets, reading reviewer notes, and resolving/reopening them. No obvious dead ends remain since updates go through share_page again and notes can be toggled back open.

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.
`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.

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.

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.

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 the full burden of behavioral disclosure. It clearly reveals the atomic all-or-nothing behavior, hard room limits (200 pages, 6 MB), and the conceptual ceiling that 'a room is a review set, not a host.' It also calls out how pages link together and why the ceiling matters in practice.

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: primary behavior first, then when-to-use guidance, then resource limits, then an alternative workflow with a concrete command. The structure front-loads the most decision-relevant information and does not repeat schema content unnecessarily.

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?

Given that there are no annotations and no output schema, the description covers everything an agent needs to decide whether and how to call this tool: what it does, when to use it, when not to use it, what constraints apply, and how pages should relate to each other. Nothing critical is left to inference.

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, but the description adds meaningful context beyond the schema: it frames pages as an entry page plus linked pages, stresses the atomicity requirement, and clarifies that plain relative hrefs allow mixed formats. This gives an agent a better mental model of how to construct the 'pages' array than the schema alone.

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 ('Publish a multi-page set') on a specific resource ('into one room') and immediately contrasts it with the sibling share_page by emphasizing atomicity and multi-page scope. An agent can clearly distinguish this tool from share_page without opening 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?

It explicitly says to use this 'instead of calling share_page N times whenever you have more than one page' and also directs file-based workflows to the uploader alternative. It even provides a ready-to-run command for that alternative, leaving no ambiguity about when this tool is the right choice.

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.

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
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
MarkupBase AOAuthDeprecated
com.markupbase
Versioned artifact review for people and AI agents, with contextual comments and human control.
Developer Tools Project Management Workplace & Productivity
1

Related MCP Servers

Terrarium
Developer Tools Project Management
nelsonsantryhkd
F
license
Not graded
quality
D
maintenance
Enables AI agents to publish HTML artifacts for human review, receive anchored feedback, and iterate until approval.
Updated 2 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 a month ago (2026-08-22 03:13 UTC)
1
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 7 days ago (2026-09-14 13:33 UTC)
351 PyPI
3
Apache 2.0
Gatewerkofficial
Autonomous Agents App Automation Workplace & Productivity
gatewerk
A
license
A
quality
A
maintenance
The open-source review layer for AI agents. Work done for humans is decided by humans.
Updated 3 days ago (2026-09-18 15:13 UTC)
18
15 npm
1
AGPL 3.0

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.

Server Details

Available Tools

Tool Schema Changelog

Related MCP Connectors

Related MCP Servers

Gatewerkofficial

Glama MCP Gateway

Resources