nippy

Publish a new site

publish_site

Publish files as a new PERMANENT website on nippy.site — returns the live URL. On the free plan a site stays online 30 days at a time and the owner gets an email link to keep it up; paid-plan sites never expire. Use only when the user clearly wants a lasting result; for drafts, iterations, or unclear intent, publish_preview is the right verb (cheap to discard, easy to keep). For a single-page artifact, pass one file named index.html. Small binaries (images, PDFs) go inline with encoding="base64"; anything bigger via start_upload. The free plan hosts 1 live site (25 MB); errors state limits honestly — relay them.

Input Schema

Name	Required	Description	Default
`name`	No	Requested address, e.g. "my-thing" → my-thing.nippy.site. Auto-suggested if omitted; may come back suffixed if taken.
`files`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed7 schema fields changedSep 10, 2026

changedInput schema / $schema

Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"

removedInput schema / additionalProperties
```
Removed value: -false
```
removedInput schema / properties / files / items / additionalProperties
```
Removed value: -false
```

changedInput schema / properties / files / items / properties / content / description

Previous value: -"File content: UTF-8 text, or base64 when encoding is \"base64\""New value: +"File content: UTF-8 text, or base64 when encoding is \"base64\". Omit when passing sourceUrl."

addedInput schema / properties / files / items / properties / sha256

Added value: +{
+  "description": "Optional SHA-256 (hex) of the decoded bytes; verified before publishing, mismatches are rejected with both hashes",
+  "type": "string"
+}

addedInput schema / properties / files / items / properties / sourceUrl

Added value: +{
+  "description": "Public http(s) URL to fetch this file from server-side (max 25 MB) — skips inline token cost for existing assets. Pass exactly one of content or sourceUrl.",
+  "type": "string"
+}

changedInput schema / properties / files / items / required

Previous value: -[
-  "path",
-  "content"
-]New value: +[
+  "path"
+]

First observedJul 24, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Goes well beyond the annotations by disclosing the lifecycle (free-plan sites last 30 days with an email renewal link; paid sites never expire), the quota (1 live site, 25 MB), and error-handling behavior ('errors state limits honestly — relay them'). Annotations only declare it is a non-read-only, non-open-world, non-destructive write; the description supplies the operational consequences.

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-loads the core action and permanence, then layers routing, file conventions, and limits. Every sentence earns its place, though the description is dense and could be trimmed slightly without loss.

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 mutation tool with no output schema, it covers the essentials an agent needs: what is created, that a URL is returned, permanence/quota constraints, the file-shaping rules, and the fallback path for oversized content. Nothing critical is missing.

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?

At 50% schema coverage the description compensates with practical conventions: a single-page artifact is one file named index.html, small binaries go inline with encoding="base64", and larger payloads should use start_upload. It doesn't add much on 'name' or sha256 beyond the schema, but the file-shaping guidance is genuinely additive.

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 ('Publish files as a new PERMANENT website on nippy.site') and explicitly returns the live URL. The word 'PERMANENT' plus the explicit contrast with publish_preview makes it distinguishable from siblings without opening schemas.

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 ('user clearly wants a lasting result') and when-not ('drafts, iterations, or unclear intent') and names the alternative verb (publish_preview) with a reason ('cheap to discard, easy to keep'). Nothing is left to inference.

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

All nippy 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?