A
licenseNot graded
qualityC
maintenancePublishes AI-generated HTML and Markdown to a hosted, shareable URL with versioning, theming, and access control.
1
MIT
dochost-mcp
Server Details
Publish Markdown or HTML to a shareable link from your AI assistant. OAuth, no API keys.
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
- Transport
- Streamable HTTP
- URL
- Repository
- zyli5313/dochost-mcp
- GitHub Stars
- 1
- Server Listing
- dochost
Available Tools
6 toolsdelete_pageDelete a dochost pageADestructiveInspect
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.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| ok | Yes | |
| slug | Yes | |
| alreadyDeleted | No |
TDQS
A4.5/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds rich behavioral details beyond the annotations: permanence, immediate effect, slug being freed, and safe no-op for already-deleted pages. These specifics are not covered by readOnlyHint=false or destructiveHint=true, significantly enhancing transparency.
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 three concise sentences, front-loaded with the core action. Each sentence provides useful information: what it does, immediate effects, and idempotency, with no wasted words.
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 simple one-parameter delete tool, the description covers the purpose, parameter semantics, behavioral outcomes, and safety (no-op). Annotations cover destructive nature, and an output schema exists, making this complete.
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?
With schema description coverage at 0%, the description compensates by explaining that the 'slug' parameter is the page identifier used for deletion. It doesn't repeat schema constraints but adds semantic meaning that the schema alone doesn't convey.
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 clearly states the tool deletes a page permanently by slug, which is a specific verb and resource. It also distinguishes from sibling tools like get_page, list_my_pages, publish, and update_page by focusing on deletion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for deleting pages but does not explicitly state when to use it versus alternatives. It provides behavioral context about effects (immediate link stop, slug freed, no-op) but lacks explicit when-to-use or when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_accountGet my dochost accountARead-onlyInspect
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.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
ParametersJSON Schema
| 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. |
TDQS
A4.7/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare this as safe and read-only, and the description adds useful behavioral context: it reports usage/quota information, includes entitlement flags, and clarifies that the primary host cannot be changed via the API. No contradiction with annotations.
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 with no filler: the return contents are front-loaded, the usage timing follows, and the dashboard caveat closes. Every sentence earns its place.
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 zero-parameter read-only tool with an output schema, the description fully covers what the tool does, when to call it, and an important limitation. The sibling tools and annotations further contextualize it adequately.
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?
The tool has no parameters, so the description cannot add parameter-level meaning beyond the schema. The baseline of 4 applies because the schema coverage is complete and no parameter ambiguity exists.
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 — 'Get your dochost account' — and enumerates exactly what is returned: plan, page-quota usage, entitlement flags, and primary host. This clearly distinguishes it from the page-level sibling tools like get_page 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.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises calling 'before publishing' so the agent knows limits up front, tying the tool to the publish workflow. It also spells out a boundary: the primary host is configured in the dashboard and 'not through this API', preventing misuse.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_pageGet one of my dochost pagesARead-onlyInspect
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.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes |
Output Schema
ParametersJSON Schema
| 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 |
TDQS
A4.5/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds valuable behavioral disclosure: 'Never returns the page body or the password.' This is an explicit constraint on the response beyond the annotation, which helps the agent set expectations. No contradictions with annotations.
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 a single, front-loaded sentence. It states the action, resource, identifier, returned fields, and a critical negative guarantee ('Never returns the page body or the password') without any redundant wording. Every clause earns its place.
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 tool is simple: one parameter, output schema exists, and annotations cover safety. The description fully covers what the agent needs to know: what data is returned and what is excluded. With an output schema present, it doesn't need to list return types. No significant gaps remain.
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 0%, so the description must compensate. It does by explicitly stating the tool fetches pages 'by slug', clarifying the purpose of the single parameter. The schema provides type and length constraints. The description adds the semantic role of the slug, which is sufficient for this simple one-parameter tool, though it doesn't elaborate on slug format or sourcing.
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 uses a specific verb ('Get') and resource ('your pages by slug'), enumerates the returned fields (title, format, status, counts, expiry, password-protection), and clearly distinguishes itself from siblings like list_my_pages (listing) and delete_page/update_page (mutations). It also explicitly states what it does NOT return, which sharpens purpose.
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 clearly implies when to use this tool: when you need metadata for a single page identified by slug. It does not explicitly name alternatives or exclusions (e.g., 'use list_my_pages to list all pages'), but the context from sibling tool names and the 'by slug' qualifier provides clear usage context. Lacks explicit when-not-to-use guidance, so not a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_my_pagesList my dochost pagesARead-onlyInspect
List the pages you have published to dochost, newest first. Paginated; returns compact records (no page bodies).
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| offset | No |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| limit | Yes | |
| pages | Yes | |
| total | Yes | |
| offset | Yes | |
| hasMore | Yes |
TDQS
A4.3/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only and non-destructive. The description adds behavioral traits beyond that: pagination, order (newest first), and the fact that records are compact without bodies. This informs the agent about response characteristics without contradicting annotations.
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 a single, well-structured sentence. It leads with the action and resource, then adds ordering and pagination details, with no filler words.
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?
With the output schema present and annotations covering safety, the description needn't explain return values. It covers purpose, ordering, pagination, and a key limitation (no page bodies), making it complete for this tool's complexity.
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 has no descriptions for limit/offset (0% coverage). 'Paginated' hints at their purpose but doesn't explicitly explain each parameter or how they interact. However, for a simple list tool with standard pagination semantics, this is adequate 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 uses a specific verb ('List') and resource ('pages you have published to dochost'), with additional detail on ordering ('newest first'). This clearly distinguishes it from siblings like get_page (single page) and publish/update/delete (mutations).
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 implies appropriate usage: it lists the user's own published pages, is paginated, and returns compact records without page bodies, hinting that get_page should be used when full content is needed. While no explicit alternatives are named, context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
publishPublish to dochostAInspect
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.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| body | Yes | ||
| format | No | ||
| public | No | ||
| password | No | ||
| customSlug | No | ||
| noBranding | No |
Output Schema
ParametersJSON Schema
| 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. |
TDQS
A3.9/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate this is not read-only and not destructive, and the description adds useful behavioral context: plan-dependent lifetime, password protection, custom slug, branding behavior, and host selection. It does not disclose idempotency or what happens if a customSlug is already taken, but the core behavior is transparent.
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 concise and front-loaded with the core purpose in the first sentence. The remaining sentences add valuable behavioral details without filler, and the structure makes the most important information immediately accessible.
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?
The description covers plan constraints, branding, and host resolution, which are important context for invoking the tool correctly. The output schema covers return values, so the missing parameter-level details are the main gap, but the overall context is sufficient for most usage scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
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, but it only explains noBranding semantics. The other parameters (body, format, public, password, customSlug) are not described beyond their property names, leaving the agent to infer their exact meaning and constraints.
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 uses a specific verb ('Publish') and resource ('Markdown or HTML as a hosted dochost page') and clearly states the outcome ('get a shareable URL'). It is easy to distinguish from sibling tools like delete_page, get_page, and update_page.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended use is clear: publish new content to a hosted page. However, there is no explicit statement about when to use this tool instead of update_page or how to handle existing pages, and the mention of get_account is informational rather than a usage rule.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
update_pageUpdate a dochost pageADestructiveInspect
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.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| body | Yes | ||
| slug | Yes | ||
| title | No | ||
| format | No |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| ok | Yes | |
| slug | Yes | |
| title | No | |
| format | No | |
| version | No |
TDQS
A4.9/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds several behavioral traits beyond the annotations: 'The URL, view/like counts, and expiry stay the same; only the body, format, and title change,' and 'Resending identical content is a no-op.' This gives the agent context about state preservation and idempotency, complementing the destructiveHint and openWorldHint annotations without contradicting them.
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 two sentences long, front-loads the core action, and every clause adds value. The second sentence provides a clear usage heuristic and a rationale, with no redundancy or filler.
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 is complete for a mutating operation: it states what is changed, what is preserved, idempotency behavior, and when to prefer it over the sibling publish tool. Since an output schema exists, not explaining return values is appropriate. It covers all necessary operational context despite the absence of parameter schema descriptions.
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?
With 0% schema description coverage, the description compensates by explaining the effect of three parameters (body, format, title) via 'only the body, format, and title change.' It does not explicitly describe the 'slug' parameter, but it is implied as the page identifier ('one of your pages') and needed for 'in place' replacement. The enum for format is not elaborated, but schema provides 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?
The description opens with 'Replace the content of one of your pages in place,' which is a specific verb-resource pairing that clearly states the action. It distinguishes itself from siblings by contrasting with publishing again, naming the exact fields that change (body, format, title) and what stays the same (URL, counts, expiry).
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?
Provides explicit when-to-use guidance: 'Prefer this over publishing again whenever the user is revising something you already published for them,' and explains why over publishing is harmful ('a second publish creates a second link and strands the one they already shared'). This clearly differentiates from the sibling publish tool.
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. Dates show when Glama detected each change.
2 tool updates
- Changed
get_account2 fields changed- added
Output 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" +} - added
Output schema / properties / primaryHostAdded value: +{ + "description": "Host new links publish on: a custom domain, `{sub}.dochost.co`, or `dochost.co/d`.", + "type": "string" +}
- Changed
publish1 field changed- changed
Output 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."
1 tool update
- Changed
publish1 field changed- added
Output schema / properties / iterateHintAdded value: +{ + "description": "How to revise this page later. Follow it instead of publishing a second time.", + "type": "string" +}
1 tool update
- Changed
publish1 field changed- added
Output schema / properties / noteAdded value: +{ + "description": "Free-tier only: expiry warning + upgrade link. Relay this to the user.", + "type": "string" +}
6 tool updates
- Changed
delete_page1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "properties": { + "alreadyDeleted": { + "type": "boolean" + }, + "ok": { + "type": "boolean" + }, + "slug": { + "type": "string" + } + }, + "required": [ + "ok", + "slug" + ], + "type": "object" +}
- Changed
get_account1 field changed- changed
Output 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" +}
- Changed
get_page1 field changed- changed
Output 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" +}
- Changed
list_my_pages1 field changed- changed
Output 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" +}
- Changed
publish1 field changed- changed
Output 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" +}
- Changed
update_page1 field changed- changed
Output 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" +}
6 tool updates
- First observed
delete_page - First observed
get_account - First observed
get_page - First observed
list_my_pages - First observed
publish - First observed
update_page
Frequently Asked Questions
Claiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity — fastest for official registry listings. For a namespace such as
io.github.alice/server, link the matching GitHub user, then choose Claim with GitHub. An organization namespace such asio.github.acme/serveralso needs that organization to have installed the Glama AI GitHub App and approved its permissions, because GitHub discloses organization membership only to apps it has installed. Use HTTP or DNS when it has not.HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at
/.well-known/glama.jsonon the same origin as the connector, then choose Check HTTP challenge.DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!
Related MCP Connectors
Share markdown as public links from your AI assistant — expiring or permanent, no API key.
Publish and share Markdown/HTML docs from AI assistants. Requires grtwo.app Pro. OAuth or API key.
- AigistOAuthcom.ai-gist
Publish & manage shareable HTML/Markdown pages from your LLM, with access control.
- dropOAuthio.neuronik
Publish web pages straight from your AI assistant and share them with a link.
Related MCP Servers
- AlicenseNot gradedqualityAmaintenanceEnables AI agents to publish HTML or Markdown to a public URL with a single HTTP POST, automatically converting Markdown to a styled webpage, with no account or setup required.71MIT
- AlicenseNot gradedqualityDmaintenancePublishes HTML pages straight from your AI assistant to a shareable URL, then lets you manage them - update, list, search, fetch, and delete pages in a public or private workspace. Turns "share what I just made" into a single tool call from Claude, Cursor, or any MCP client.MIT
Publee MCP Serverofficial
AlicenseAqualityCmaintenanceEnables AI tools to publish HTML pages and get shareable URLs instantly, with optional account features for persistence, in-place updates, and visibility control.1MIT
Try in Browser
Glama MCP Gateway
Add one secure layer between your agents and this server.
TDQS
A4.5/5.0
Disambiguation5/5
Each tool targets a distinct operation: create (publish), read (get_page, list_my_pages, get_account), update (update_page), and delete (delete_page). There is no overlap or ambiguity between tools.
Naming Consistency4/5
Most tools follow a clear verb_noun pattern (delete_page, get_account, get_page, list_my_pages, update_page). The exception is 'publish' which is a single verb, but it is still clear and does not cause confusion.
Tool Count5/5
With 6 tools, the server is well-scoped for its purpose. Each tool covers a necessary aspect of page hosting: creation, retrieval, listing, updating, deletion, and account entitlements.
Completeness5/5
The tool surface provides full CRUD coverage for pages (publish, get_page, update_page, delete_page) plus listing and account information. No obvious gaps exist for the stated domain.