Skip to main content
Glama

twocents

by page.twocents
OverviewDiscussionsAdmin

Share a whole set of pages in one request

share_pages

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

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
roomNoRoom id to publish into. Omit to create a new room.
entryNoWhich 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.
pagesYesThe 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.
pruneNoDelete 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.
forkableNoWhether 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.
creatorKeyNoOnly to change "forkable" on a room created in an earlier session.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema 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"
+}
  2. Added

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.

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