UiChemy AI Website Creator

uichemy_publish_emdash

Destructive

Put a project ONLINE as an Astro site WITH the EmDash CMS on the user's OWN Cloudflare account (a Worker at https://..workers.dev, plus a D1 database and login storage in their account). The site's pages, sections and blog posts become editable content in its admin at /_emdash/admin. This is PUBLIC: only call it when the user asks to publish, deploy or go live with EmDash or a CMS on Cloudflare, and tell them the address. The first time, the account is not connected: this returns a link the user must open to approve UiChemy on Cloudflare; after they have, call this again. If their Cloudflare login has several accounts, this lists them: ask which one and pass its accountId. Calling it again for a published project UPDATES the same site and keeps its CMS content and users. After the FIRST publish the CMS is locked behind a one-time setup link: give it to the user. Publishing takes about a minute; this waits up to 40 seconds, then returns a jobId for uichemy_emdash_status. Only generated pages are published. For a plain static site without a CMS use uichemy_deploy_to_cloudflare.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "projectId": "<projectId>"
    },
    "name": "uichemy_publish_emdash"
  }
}

Input Schema

Name	Required	Description
`build`	No	html = HTML + EmDash (UiChemy designs, the default for a new site); astro = Astro + EmDash (every section's text and images edited in CMS fields). Omit to keep the build a published site already uses. Only when the user asks for a specific build.
`pages`	No	Page names to publish. Omit for every generated page.
`accountId`	No	Cloudflare account id, only when this tool listed several. Omit otherwise.
`projectId`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedNov 2, 2026

addedInput schema / properties / build

Added value: +{
+  "description": "html = HTML + EmDash (UiChemy designs, the default for a new site); astro = Astro + EmDash (every section's text and images edited in CMS fields). Omit to keep the build a published site already uses. Only when the user asks for a specific build.",
+  "enum": [
+    "html",
+    "astro"
+  ],
+  "type": "string"
+}

AddedOct 22, 2026

TDQS

A4.8/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Goes far beyond the annotations: discloses the first-run auth handshake (returns an approval link, must be retried), multi-account disambiguation via accountId, the one-time CMS setup link after first publish, in-place update behavior preserving CMS content and users, the ~1 minute duration and 40s wait yielding a jobId, and that only generated pages ship. This is exactly the context the destructiveHint/openWorldHint annotations cannot convey.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the outcome and public-visibility warning, then the operational edge cases in descending importance. It is dense and long, but nearly every sentence carries actionable information (auth, accountId, idempotent update, timing, setup link); only the build/pages detail mildly overlaps the schema.

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 no output schema, the description still explains what comes back at each stage (site URL, approval link, account list, setup link, jobId + status tool), so an agent can drive the whole multi-step flow. For a destructive, open-world deploy tool this is 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?

Schema coverage is 75%, and the description still adds real meaning: accountId is framed as only needed when the tool listed multiple Cloudflare accounts (with the ask-the-user step), and 'Only generated pages are published' constrains the pages array beyond the schema's 'Omit for every generated page'. projectId remains undocumented, but it is the obvious required key.

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 ('Put a project ONLINE as an Astro site WITH the EmDash CMS') plus the exact deployment target (user's own Cloudflare account, Worker at <name>.<subdomain>.workers.dev, D1 database). It explicitly distinguishes itself from the nearest siblings: 'For a plain static site without a CMS use uichemy_deploy_to_cloudflare' and routes long-running follow-up to uichemy_emdash_status.

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?

Gives an explicit when-to-call gate ('only call it when the user asks to publish, deploy or go live with EmDash or a CMS on Cloudflare'), an explicit alternative (deploy_to_cloudflare for static), and the re-invocation semantics (call again after auth approval; calling again for an already-published project updates it).

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All UiChemy AI Website Creator tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?