Skip to main content
Glama

nippy

by host.nippy
OverviewDiscussionsAdmin

Publish a new site

publish_site

Publish files as a new PERMANENT website on nippy.site — returns the live URL, no expiry. 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

TableJSON Schema
NameRequiredDescriptionDefault
nameNoRequested address, e.g. "my-thing" → my-thing.nippy.site. Auto-suggested if omitted; may come back suffixed if taken.
filesYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed7 schema fields changed
    • 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"
+]
  2. First observed

TDQS

A4.6/5.0
Behavior4/5

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

Annotations are all false, so the description carries the burden. It discloses permanence (no expiry), the free-plan limit (1 site, 25 MB), and error handling ('errors state limits honestly — relay them'). It does not mention auth requirements or side effects on existing resources, but for a creation tool this is adequate.

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?

Five concise sentences, each earning its place: core purpose first, then usage guidance, then file-handling tips, then limits. No fluff; information is front-loaded and logically ordered.

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?

No output schema exists, so the description must explain returns ('returns the live URL') and error behavior ('relay them'). It covers key constraints (inline limits, free plan cap) and points to alternatives. It could mention name-collision suffix behavior, but that is documented in the schema, so the overall picture 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?

The schema already documents name and files thoroughly, but the description adds valuable non-obvious facts: the index.html convention for single-page artifacts, base64 for binaries, and the direction to start_upload for larger files. It also reiterates size limits that are partially in schema. This is more than a restatement.

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 is specific: 'Publish files as a new PERMANENT website on nippy.site — returns the live URL, no expiry.' It clearly identifies the verb (publish), resource (files), and result (live URL), and immediately contrasts with publish_preview, making the distinction unambiguous.

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 states when to use: 'Use only when the user clearly wants a lasting result,' and when not to: 'for drafts, iterations, or unclear intent, publish_preview is the right verb.' Also provides routing for large files to start_upload. This is textbook guidance.

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

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