Publish Markdown or HTML to a clean, shareable link straight from your AI assistant. OAuth sign-in, no API keys. Two tools: publish (Markdown/HTML → URL, with optional password, custom slug, and public/unlisted) and list_my_pages. Homepage: https://dochost.io
Scored across 6 tools
Each tool has a clearly distinct purpose: delete, get account, get page metadata, list pages, publish new, update existing. No overlap or ambiguity.
All names follow a lowercase snake_case verb_noun pattern (delete_page, get_account, get_page, list_my_pages, update_page) with only 'publish' being a single verb but still clear and consistent with the pattern.
6 tools cover the core operations of a page hosting service (CRUD, list, account info) without being too many or too few. The scope is well-scoped.
The tool set covers CRUD and listing, but notably get_page does not return the page body, so agents cannot retrieve published content via API. Missing tools like 'search pages' or account management, but the core workflow is largely complete.
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.
get_account2 fields changedOutput schema / properties / manageDomainsUrlAdded value: +{
+ "description": "Dashboard page where the user adds domains and picks the primary one. Send them here to change it.",
+ "type": "string"
+}Output schema / properties / primaryHostAdded value: +{
+ "description": "Host new links publish on: a custom domain, `{sub}.dochost.co`, or `dochost.co/d`.",
+ "type": "string"
+}publish1 field changedOutput schema / properties / url / descriptionPrevious value: -"The shareable dochost.co page URL."New value: +"The shareable page URL, on the account's primary host (custom domain, subdomain, or dochost.co/d). Relay it verbatim."publish1 field changedOutput schema / properties / iterateHintAdded value: +{
+ "description": "How to revise this page later. Follow it instead of publishing a second time.",
+ "type": "string"
+}publish1 field changedOutput schema / properties / noteAdded value: +{
+ "description": "Free-tier only: expiry warning + upgrade link. Relay this to the user.",
+ "type": "string"
+}delete_page1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "alreadyDeleted": {
+ "type": "boolean"
+ },
+ "ok": {
+ "type": "boolean"
+ },
+ "slug": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "ok",
+ "slug"
+ ],
+ "type": "object"
+}get_account1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "analytics": {
+ "enum": [
+ "none",
+ "totals",
+ "full"
+ ],
+ "type": "string"
+ },
+ "customSlug": {
+ "type": "boolean"
+ },
+ "noBranding": {
+ "type": "boolean"
+ },
+ "ok": {
+ "type": "boolean"
+ },
+ "pageQuota": {
+ "type": [
+ "integer",
+ "null"
+ ]
+ },
+ "pagesRemaining": {
+ "type": [
+ "integer",
+ "null"
+ ]
+ },
+ "pagesUsed": {
+ "type": "integer"
+ },
+ "password": {
+ "type": "boolean"
+ },
+ "permanentLinks": {
+ "type": "boolean"
+ },
+ "plan": {
+ "enum": [
+ "free",
+ "pro",
+ "max"
+ ],
+ "type": "string"
+ },
+ "sizeCapMb": {
+ "type": "integer"
+ }
+ },
+ "required": [
+ "ok",
+ "plan"
+ ],
+ "type": "object"
+}get_page1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "createdAt": {
+ "type": "string"
+ },
+ "expiresAt": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "format": {
+ "enum": [
+ "markdown",
+ "html"
+ ],
+ "type": "string"
+ },
+ "hasPassword": {
+ "type": "boolean"
+ },
+ "likes": {
+ "type": "integer"
+ },
+ "ok": {
+ "type": "boolean"
+ },
+ "permanent": {
+ "type": "boolean"
+ },
+ "slug": {
+ "type": "string"
+ },
+ "status": {
+ "type": "string"
+ },
+ "title": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "url": {
+ "type": "string"
+ },
+ "views": {
+ "type": "integer"
+ }
+ },
+ "required": [
+ "ok",
+ "slug",
+ "url"
+ ],
+ "type": "object"
+}list_my_pages1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "hasMore": {
+ "type": "boolean"
+ },
+ "limit": {
+ "type": "integer"
+ },
+ "offset": {
+ "type": "integer"
+ },
+ "pages": {
+ "items": {
+ "properties": {
+ "createdAt": {
+ "type": "string"
+ },
+ "expiresAt": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "format": {
+ "enum": [
+ "markdown",
+ "html"
+ ],
+ "type": "string"
+ },
+ "likes": {
+ "type": "integer"
+ },
+ "slug": {
+ "type": "string"
+ },
+ "status": {
+ "type": "string"
+ },
+ "title": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "url": {
+ "type": "string"
+ },
+ "views": {
+ "type": "integer"
+ }
+ },
+ "required": [
+ "slug",
+ "url",
+ "format",
+ "status"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "total": {
+ "type": "integer"
+ }
+ },
+ "required": [
+ "pages",
+ "total",
+ "limit",
+ "offset",
+ "hasMore"
+ ],
+ "type": "object"
+}publish1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "additionalProperties": false,
+ "properties": {
+ "expiresAt": {
+ "description": "ISO timestamp, or null when the link is permanent.",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "format": {
+ "enum": [
+ "markdown",
+ "html"
+ ],
+ "type": "string"
+ },
+ "permanent": {
+ "type": "boolean"
+ },
+ "slug": {
+ "type": "string"
+ },
+ "url": {
+ "description": "The shareable dochost.co page URL.",
+ "type": "string"
+ }
+ },
+ "required": [
+ "url",
+ "slug",
+ "format",
+ "permanent"
+ ],
+ "type": "object"
+}update_page1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "format": {
+ "enum": [
+ "markdown",
+ "html"
+ ],
+ "type": "string"
+ },
+ "ok": {
+ "type": "boolean"
+ },
+ "slug": {
+ "type": "string"
+ },
+ "title": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "version": {
+ "type": "integer"
+ }
+ },
+ "required": [
+ "ok",
+ "slug"
+ ],
+ "type": "object"
+}delete_pageget_accountget_pageupdate_pagelist_my_pagespublish
