Allows Hermes headless agents to publish documents using an API key authentication.
Publish Markdown or HTML to a clean, shareable link — straight from your AI
assistant. The dochost MCP server gives Claude, ChatGPT, Cursor and any other MCP
client six tools — publish, update_page, list_my_pages, get_page,
get_account, delete_page — so your assistant can hand back a public
dochost link and then keep maintaining it. No copy-paste,
no separate dashboard.
🌐 Website: https://dochost.io
🔌 MCP server: https://dochost.io/mcp
🛰️ Endpoint: https://dochost.io/api/mcp (Streamable HTTP, OAuth)
🔑 Auth: OAuth sign-in — no API keys
Your LLM produced a report, a README, an HTML artifact. Sending it shouldn't mean
a screenshot or a raw .md blob. dochost turns that output into a normal web page
at its own URL, in one tool call. Markdown and HTML are rendered live.
Related MCP server: htmldrop
Claude Code (one line):
claude mcp add --transport http dochost https://dochost.io/api/mcpThen run /mcp inside Claude Code and approve in the browser. Add --scope user
to use it in every project.
Claude Desktop / Cursor / VS Code / Windsurf — add a remote HTTP server:
{
"mcpServers": {
"dochost": {
"type": "http",
"url": "https://dochost.io/api/mcp"
}
}
}You authorize once via OAuth in the browser; the assistant then publishes as you, and output follows your dochost plan's entitlements.
For clients or directory evaluators that need a local stdio process, this repository includes a bridge to the same hosted MCP endpoint:
npm ci --ignore-scripts
node server/index.jsOr run it in Docker:
docker build -t dochost-mcp .
docker run --rm -i dochost-mcpNode.js 22 or newer is required. The bridge forwards the live tools and schemas;
it is not a self-hosted copy of the dochost application. Initialization and
tool discovery are public. Interactive clients can use OAuth; headless tool
execution needs an existing DOCHOST_API_KEY runtime secret (Docker:
docker run --rm -i -e DOCHOST_API_KEY dochost-mcp).
Maintainers: see Glama claim, build and release instructions.
Client | Recommended auth | Why |
OpenClaw, Hermes | API key | Headless agents (e.g. a Telegram orchestrator). A static Bearer key works with the plain-HTTP skill and any MCP runner, with no browser step per session. |
Claude, Cursor, ChatGPT, VS Code, Windsurf, and all other MCP clients | OAuth | One browser approval, nothing long-lived stored in config; the assistant publishes as you. |
Keep the API key like any secret: store it as an environment variable / host secret (never commit it), and revoke or rotate it from Settings → API keys if it leaks.
OpenClaw and Hermes are headless, so they authenticate with an API key. Create
one at dochost.io → Settings → API keys, export it as
DOCHOST_API_KEY, and either:
Install the skill — a self-contained publish skill that works on any agent
that can make an HTTP request: skills/dochost-publish/.
Wire the MCP — point the agent at https://dochost.io/api/mcp with the key as
a Bearer header: examples/mcporter.config.json.
Per-host install guides:
OpenClaw → clients/openclaw.md
Hermes → clients/hermes.md
One-shot from a shell: examples/publish.sh.
Six tools. publish creates; the rest let the assistant keep working with what it
already published, instead of stranding a link every time you revise something.
publishPublish Markdown or HTML as a hosted page and get a shareable URL.
Parameter | Type | Notes |
| string (required) | The Markdown or HTML content to publish. |
|
| Auto-detected when omitted. |
| boolean | List on Explore. Defaults to |
| string · Pro | Choose the link path instead of a random slug. |
| string · Pro | Gate the page behind a password. |
| boolean · Pro | Hide the dochost footer badge. |
Returns url, slug, expiresAt, and an editToken.
Example: "Publish my Q3 report as a private page with a password." →
dochost.co/d/q3-report(password-gated, 7-day link on free).
update_pageReplace the content of a page in place. The URL, view/like counts and expiry
all survive — only body, format and title change.
Parameter | Type | Notes |
| string (required) | The page to update. |
| string (required) | The new Markdown or HTML content. |
|
| Auto-detected when omitted. |
| string | Override the derived title. |
Prefer this over publishing again whenever you are revising something already published — a second
publishmints a second link and strands the one the reader already has. Resending identical content is a no-op.
list_my_pagesList the pages you have published, newest first. Paginated (limit, offset);
returns compact records without page bodies.
get_pageLook up one page by slug: title, format, status, view/like counts, expiry, and
whether it is password-protected. Never returns the body or the password.
get_accountYour plan, page-quota usage and entitlement flags (size cap, custom slug,
password, branding). Worth calling before publish so the assistant knows your
limits up front instead of failing on them.
delete_pagePermanently delete a page by slug. The link stops working immediately and the
slug is freed. Deleting an already-deleted page is a safe no-op.
Ownership and entitlements come from your authenticated account, never from tool input.
Published pages live on dochost.co, a separate cookieless content origin
— never on the app origin dochost.io. That is what lets dochost serve author
HTML under a hardened policy without it touching your session. dochost.io/d/…
permanently redirects to dochost.co/d/…, so old links keep working.
Free links last 7 days; permanent links, password, custom slug, custom subdomain and branding removal are on the paid plans — see dochost.io.
Homepage — https://dochost.io
MCP setup & docs — https://dochost.io/mcp
MIT — see LICENSE.
Permanently delete one of your pages by slug. The link stops working immediately and the slug is freed. Deleting an already-deleted page is a safe no-op.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes |
| Name | Required | Description |
|---|---|---|
| ok | Yes | |
| slug | Yes | |
| alreadyDeleted | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the destructiveHint annotation, the description adds details: the deletion is permanent, the link stops working immediately, the slug is freed, and deleting an already-deleted page is a safe no-op. This fully discloses the behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three concise sentences with no redundant words. It is well-structured and front-loads the primary action, then explains consequences and edge-case behavior.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple delete operation with one parameter and an output schema, the description covers the effect, the idempotency, and the side effect on the slug. No additional information is needed for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% for the slug parameter. The description says 'by slug' which conveys it is the page identifier, but offers no explanation of format, length constraints, or how to obtain the slug. Minimal compensation for the lack of schema description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (delete), the resource (page), and the identifier (slug). It is distinct from sibling tools such as update_page, publish, and list_my_pages.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The context is clear: use this tool to permanently delete a page. It does not explicitly exclude other tools, but the deletion intent is unambiguous and no competing tool serves the same purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get your plan, page-quota usage, entitlement flags (size cap, custom slug, password, branding), and the primary host new links publish on. Call before publishing so you know your limits up front. The primary host is chosen in the dashboard (manageDomainsUrl), not through this API.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| ok | Yes | |
| plan | Yes | |
| password | No | |
| analytics | No | |
| pageQuota | No | |
| pagesUsed | No | |
| sizeCapMb | No | |
| customSlug | No | |
| noBranding | No | |
| primaryHost | No | Host new links publish on: a custom domain, `{sub}.dochost.co`, or `dochost.co/d`. |
| pagesRemaining | No | |
| permanentLinks | No | |
| manageDomainsUrl | No | Dashboard page where the user adds domains and picks the primary one. Send them here to change it. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, non-destructive behavior. The description adds a valuable limitation beyond annotations: the primary host is chosen in the dashboard (manageDomainsUrl), not through this API. This helps the agent avoid expecting write or configuration capability from this read-only tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded. The first sentence enumerates exactly what is returned, the second gives the usage timing, and the third clarifies an important limitation. Every sentence earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter read-only tool with an output schema and safety annotations, the description is complete. It tells the agent what data it will receive, when to call it, and one key behavioral caveat. The existing output schema covers return-value details, so nothing essential is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and 100% schema coverage, so there are no parameter semantics to clarify. The description appropriately focuses on what the response contains rather than parameters. The baseline of 4 applies for zero-parameter tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb ('Get') and resource ('your plan, page-quota usage, entitlement flags, primary host'), making the tool's purpose explicit. It also distinguishes itself from sibling tools by framing itself as the pre-publication account lookup, which is clearly different from publish, page CRUD, and listing operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit timing guidance: 'Call before publishing so you know your limits up front.' It does not name alternative tools or state when not to use it, but it provides clear context for when the 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.
Get one of your pages by slug: title, format, status, view/like counts, expiry, and whether it is password-protected. Never returns the page body or the password.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes |
| Name | Required | Description |
|---|---|---|
| ok | Yes | |
| url | Yes | |
| slug | Yes | |
| likes | No | |
| title | No | |
| views | No | |
| format | No | |
| status | No | |
| createdAt | No | |
| expiresAt | No | |
| permanent | No | |
| hasPassword | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark read-only/non-destructive; the description adds the crucial privacy behavior that body and password are never returned, and enumerates exactly which fields the caller can expect. This goes well beyond the structured annotation data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences: the first delivers the resource and returned fields, and the second adds a critical exclusion. No filler or unnecessary repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter read with an output schema and annotations, the description is nearly complete: it identifies the selector, enumerates returned fields, and flags excluded data. The only notable gap is not pointing to list_my_pages for discovering slugs or enumerating pages.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description confirms slug is the page identifier, but the schema already names the parameter. With 0% schema description coverage, it only partially compensates by clarifying the slug selects one of 'your' pages; no format, origin, or example is given.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('Get'), a precise resource (one page by slug), and the exact metadata fields returned. 'One of your pages by slug' distinguishes it from list_my_pages (plural enumeration) without needing the sibling list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Clear context: use when you need a single page's metadata and have its slug. It does not explicitly name alternatives or say when not to use it, so no exclusion guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the pages you have published to dochost, newest first. Paginated; returns compact records (no page bodies).
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| offset | No |
| Name | Required | Description |
|---|---|---|
| limit | Yes | |
| pages | Yes | |
| total | Yes | |
| offset | Yes | |
| hasMore | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnlyHint=true, destructiveHint=false), the description adds genuinely useful behavioral traits: ordering ('newest first'), pagination behavior ('Paginated'), and output shape ('compact records, no page bodies'). This tells the agent what it will and won't get back without contradicting any annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences totaling about 18 words, with zero filler. The verb and resource are front-loaded, and every clause earns its place: scope, ordering, pagination, and output-shape caveat.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple listing tool, this is nearly complete: scope, order, pagination, and record content are all disclosed, and the annotations plus existing output schema cover safety and return structure. The only gap is not explicitly routing the agent to get_page when a page body is needed, which is a minor omission given the sibling list is visible.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds the concept of pagination, which gives semantic context for limit/offset, but it does not explicitly say limit controls page size and offset controls the starting position. The compensation is partial, so a middle score is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('List'), a resource ('the pages you have published to dochost'), and an ordering guarantee ('newest first'). It naturally distinguishes from siblings: it is a list/scoping operation, whereas get_page presumably fetches a single page, and publish/update/delete_page are mutations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context: it is scoped to the caller's own published pages and is suitable for browsing/list operations. The 'no page bodies' note implies that content retrieval belongs elsewhere, but it never explicitly names get_page as the alternative for full bodies, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Publish Markdown or HTML as a hosted dochost page and get a shareable URL. Respects your plan: link lifetime, password protection, custom slug, and branding all follow your account entitlements. Paid plans publish without dochost branding by default — pass noBranding: false to keep the mark. The link is issued on the account's primary host (a custom domain or subdomain when one is set in Settings › Domains, otherwise dochost.co/d); get_account reports which.
| Name | Required | Description | Default |
|---|---|---|---|
| body | Yes | ||
| format | No | ||
| public | No | ||
| password | No | ||
| customSlug | No | ||
| noBranding | No |
| Name | Required | Description |
|---|---|---|
| url | Yes | The shareable page URL, on the account's primary host (custom domain, subdomain, or dochost.co/d). Relay it verbatim. |
| note | No | Free-tier only: expiry warning + upgrade link. Relay this to the user. |
| slug | Yes | |
| format | Yes | |
| expiresAt | No | ISO timestamp, or null when the link is permanent. |
| permanent | Yes | |
| iterateHint | No | How to revise this page later. Follow it instead of publishing a second time. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (mutating, open-world, non-destructive), the description discloses plan-dependent behavior, the default branding behavior, and how the host is resolved. This gives the agent a clear picture of what happens for free vs paid plans and where the URL will be issued.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with no filler; the main purpose is front-loaded and every sentence adds useful information. The structure is easy to scan and understand.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema and annotations present, the description covers the key decisions: input format, plan limits, branding, and host resolution. The main gap is the undocumented public parameter and the lack of error or edge-case behavior, but the description is still strong and mostly self-sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must carry parameter meaning. It clarifies noBranding semantics and says password, customSlug, and branding respect plan limits, but it does not explain the public parameter, password constraints, or customSlug format.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The first sentence states a specific action ('Publish') and resource ('hosted dochost page') plus the outcome ('shareable URL'). This clearly differentiates it from the list/get/update/delete sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides useful context about plan entitlements and tells the agent to use get_account to learn the host, but it never explicitly says when to use publish versus update_page or when publishing is not allowed. Usage must be inferred rather than explicitly routed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Replace the content of one of your pages in place. The URL, view/like counts, and expiry stay the same; only the body, format, and title change. Resending identical content is a no-op. Prefer this over publishing again whenever the user is revising something you already published for them — a second publish creates a second link and strands the one they already shared.
| Name | Required | Description | Default |
|---|---|---|---|
| body | Yes | ||
| slug | Yes | ||
| title | No | ||
| format | No |
| Name | Required | Description |
|---|---|---|
| ok | Yes | |
| slug | Yes | |
| title | No | |
| format | No | |
| version | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint=false, destructiveHint=true), the description reveals what stays the same (URL, view/like counts, expiry), what changes (body, format, title), and idempotence (resending identical content is a no-op). This gives the agent a precise mental model of side effects and is consistent with the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each earning its place: operation and scope first, then behavioral details, then routing guidance. No filler or redundant restatement of the title or schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 4-parameter mutation tool with an output schema, the description covers selection, mutation scope, preserved fields, and idempotence. The only notable gap is minimal explicit parameter-level guidance for slug and format, but the schema and enum mostly cover invocation. Overall it is complete enough for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema property descriptions are absent (0% coverage), but the description partially compensates by indicating that body, format, and title are the mutable fields and that the URL stays stable, which implies slug identifies the page. It does not explicitly define slug or explain format values, though the schema's enum and min/max constraints fill some of that gap. This is adequate but not fully compensating.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('replace') and resource ('one of your pages') with clear scope: 'in place.' It explicitly distinguishes update_page from publish by explaining that publishing again creates a second link, so the tool's purpose is unambiguous and easily separated from its siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage guidance is explicit: 'Prefer this over publishing again whenever the user is revising something you already published for them.' It also explains the downside of the alternative ('a second publish creates a second link and strands the one they already shared'), so an agent knows exactly when to choose update_page over publish.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0delete_pageget_accountget_pagelist_my_pagespublishupdate_pageScored across 6 tools
Each tool has a clearly distinct responsibility: publish creates, list_my_pages enumerates, get_page retrieves metadata for one page, update_page modifies content, delete_page removes, and get_account covers account/plan details. The potential publish/update_page overlap is explicitly disambiguated in the descriptions.
Most tools follow a verb_noun pattern: list_my_pages, get_account, get_page, update_page, delete_page. The lone exception is publish, which lacks an explicit object like publish_page, and list_my_pages includes a possessive that the other list/get tools do not.
Six tools is well-scoped for a page hosting service: publish, list, get, update, delete, and account awareness. Each tool covers a necessary workflow step without unnecessary redundancy.
The core page lifecycle is covered: create, list, read metadata, update, delete, plus account/plan information. Minor gaps exist because page bodies are never retrievable via the API, so content recovery or editing an already-published page without the original source is not fully supported.
Publish & manage shareable HTML/Markdown pages from your LLM, with access control.
Publish and share Markdown/HTML docs from AI assistants. Requires grtwo.app Pro. OAuth or API key.
Publish web pages straight from your AI assistant and share them with a link.
Publish, update, read, rename, and share single-URL web pages from any AI agent.
