Publish HTML, static sites and files to .chorus.host, and deploy Cloudflare Workers backends to .worker.chorus.host, from any agent.
Scored across 3 tools
The three tools have clearly distinct purposes: get_docs returns documentation, get_site retrieves site status and metadata, and publish_site creates or updates a site. There is no overlap in function, and each tool's action and target are unambiguous.
All tool names follow a consistent snake_case verb_noun pattern: get_docs, get_site, publish_site. The verbs appropriately reflect the actions, and there is no mixing of conventions.
With only 3 tools, the set is minimal but still covers the core publishing workflow (publish, check, and documentation). It is slightly thin for a hosting service that also supports accounts, API keys, and Workers, but each tool is substantial and earns its place.
The surface covers create/update and read operations for sites, but lacks tools for deletion, claiming a site programmatically, setting password protection, or managing API keys and Workers. These features are documented in get_docs, but agents cannot perform them directly, creating notable gaps for full lifecycle management.
Return the full chorus.host documentation as Markdown (the same text as https://chorus.host/skill.md): the REST API, the beacon CLI, accounts and API keys, claiming sites, password protection, and Workers, which run server-side JavaScript at .worker.chorus.host for APIs and webhooks. Read it before building a backend, when the user asks about accounts or limits, or when a task needs something publish_site can't do.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and openWorldHint=false, so safety behavior is covered. The description usefully adds that the return is Markdown identical to https://chorus.host/skill.md, plus the breadth of content returned, though it says nothing about size or truncation for a large document.
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 sentences, front-loaded with what is returned before the usage guidance. The content enumeration is somewhat long but each listed area maps to real documentation scope and no sentence is filler.
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 no output schema, the description carries the return-value burden and does so by stating the format (Markdown) and the content covered. For a zero-parameter, read-only reference tool, an agent has everything it needs to call it 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?
Zero parameters, so there is no parameter semantics to explain; baseline is 4. The description correctly implies a plain no-argument full-document fetch, consistent with an empty object schema.
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 and resource ('Return the full chorus.host documentation as Markdown') and enumerates exactly what the docs cover: REST API, beacon CLI, accounts, API keys, claiming sites, password protection, and Workers. It also names the sibling boundary by noting docs for things 'publish_site can't do', so an agent can distinguish it from get_site/publish_site.
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?
Gives explicit trigger conditions: 'Read it before building a backend, when the user asks about accounts or limits, or when a task needs something publish_site can't do.' This names both the when-to-use conditions and the sibling alternative that signals the switch.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check a chorus.host site: whether it is live, its URL, whether it has a password, and when it expires. With the site's claim_token (or an API key that owns the site) it also returns the file list, total size, live version and claim link. Use it to confirm a publish worked, to see when an anonymous site expires, or to see what is published at a slug.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | The site's slug, i.e. the subdomain in <slug>.chorus.host. A full URL also works. | |
| claim_token | No | Optional claim_token (ctk_...) of the site. Unlocks the file list and other details. |
| Name | Required | Description |
|---|---|---|
| url | No | |
| slug | Yes | |
| files | No | File paths of the live version (first 200). |
| title | No | |
| status | Yes | live, not_live (created but nothing published yet) or not_found (never published, expired or deleted). |
| claimed | No | Whether an account owns the site. Only returned when can_manage is true. |
| summary | Yes | |
| claim_url | No | |
| can_manage | Yes | True when the claim_token or API key you sent lets you update this site. |
| created_at | No | |
| expires_at | No | When the site will be deleted (RFC 3339). Empty for sites that never expire. |
| file_count | No | |
| updated_at | No | |
| total_bytes | No | |
| files_truncated | No | |
| current_version_id | No | |
| password_protected | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnlyHint=true, openWorldHint=false), so the bar is lower, and the description still adds real behavioral detail: output is conditional on supplying a claim_token or an owning API key, which unlocks file list, total size, live version, and claim link. It does not flag the unusual idempotentHint=false or note any rate limits, keeping it short of a 5.
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 tight sentences with no filler. The core status fields are front-loaded, followed by the conditional-auth behavior and then use cases, which is the right order for an agent scanning for relevance.
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?
An output schema exists, so return values need no prose explanation. Between the enumerated status fields, the auth-conditional behavior, and the usage scenarios, an agent has everything needed to decide and call 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 coverage is 100% and the schema already explains slug (including full-URL acceptance) and claim_token, so the baseline is 3. The description goes further by clarifying that an API key owning the site can substitute for claim_token and that this unlocks additional fields, adding auth semantics beyond the schema.
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 ('Check') and resource ('a chorus.host site') and enumerates exactly what is reported: liveness, URL, password presence, and expiry. It also states the richer payload returned when a claim_token is supplied, so an agent can distinguish it from publish_site and get_docs without opening any schema.
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?
Three concrete usage scenarios are given: confirming a publish worked, checking when an anonymous site expires, and seeing what is published at a slug. This routes the agent well relative to publish_site, though no alternative is named explicitly and there are no stated exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Publish HTML/CSS/JS or any static files to a live public HTTPS URL at .chorus.host in one call. No account or API key needed. Use it when the user asks to publish, host, deploy or share a page, website, landing page, report, dashboard, portfolio, game or demo, or wants a link to something you made. Send every file with its path (index.html is served at the root) and its content: plain text for HTML, CSS, JS, SVG, JSON and Markdown, or base64 with encoding='base64' for images, fonts and other binary files. Each call publishes the complete site: files you leave out are removed. Limits: 4 MB of file content per call without an API key, 10 MB with one, and 1,000 files. Anonymous sites stay live for 24 hours; the result has a claim_url to give the user so they can keep the site for free, and a claim_token to save. To update a site, call again with the same slug and its claim_token.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | No | Optional. Subdomain to publish to (3-63 lowercase letters, digits and hyphens). Leave empty for a random one. To update an existing site, pass its slug together with its claim_token. | |
| files | Yes | Every file of the site. Each call replaces all files of the site. | |
| title | No | Optional human-readable title saved with the site. | |
| claim_token | No | The claim_token (ctk_...) returned when the site was first published. Required to update an anonymous site. |
| Name | Required | Description |
|---|---|---|
| url | Yes | Live URL of the site root. |
| slug | Yes | |
| updated | Yes | True when an existing site got a new version. |
| page_url | Yes | URL to open: the site root, or the only HTML page when there is no index.html. |
| warnings | No | |
| anonymous | Yes | True when the site is not owned by an account and will expire unless claimed. |
| claim_url | No | Link for the user to keep the site: they open it and sign in with their email. |
| expires_at | No | When the site will be deleted (RFC 3339), unless claimed. |
| file_count | Yes | |
| next_steps | Yes | Notes for you, the agent. |
| version_id | Yes | |
| claim_token | No | Secret needed to update this anonymous site later. Save it; never put it on the page. |
| total_bytes | Yes | |
| tell_the_user | Yes | Plain-English message to relay to the user. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses behavior that contradicts the annotations: it states 'Each call publishes the complete site: files you leave out are removed,' which is a destructive replacement of existing content, while the annotations declare destructiveHint=false (only additive updates). The remaining disclosures (24-hour anonymous lifetime, 4 MB/10 MB limits, 1,000 files, claim_url/claim_token) are genuinely useful, but the destructive-vs-additive contradiction is material.
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 definition is dense but front-loaded: what it does and where it lands comes first, then triggers, then file-passing mechanics, then limits and the claim flow. It is long (a single large paragraph covering many facets), but each sentence carries distinct operational information; only minor tightening is possible.
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 publish/deploy tool with a nested files array, limits, expiry and a claim flow, the description covers everything an agent needs: content types and encoding, replacement semantics, size/file limits, anonymous lifetime, and the fields present in the result (claim_url, claim_token). An output schema exists, so return-value documentation beyond those flags is unnecessary.
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 already 100%, so the baseline is 3, and the description adds real meaning on top: index.html is served at the root, plain text vs base64 (encoding='base64') selection for binary assets, and the slug+claim_token pairing needed to update rather than create. It does not restate the schema's format constraints on slug, which keeps it from being exhaustive.
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 (publish) and resource (HTML/CSS/JS or any static files) plus the concrete outcome (a live public HTTPS URL at <slug>.chorus.host in one call). It is immediately distinguishable from the read-oriented siblings get_docs and get_site without opening any schema.
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?
Explicit when-to-use triggers are listed ('when the user asks to publish, host, deploy or share a page, website, landing page, report, dashboard, portfolio, game or demo, or wants a link to something you made'), and the update path is spelled out ('call again with the same slug and its claim_token'). No inference is required about the situation that selects this tool.
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_docsget_sitepublish_site
Add one secure layer between your agents and this server.