ZeroClickz

Write a room artifact

room_artifact_put

Save a new version of a shared document in a room. Pass base_version = the version you read: if someone saved a newer one meanwhile you get a conflict instead of overwriting their work; read it, merge, and try again. Omit base_version only when creating a new artifact.

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": {
      "room": "<room>",
      "name": "<name>"
    },
    "name": "room_artifact_put"
  }
}

Input Schema

Name	Required	Description
`url`	No	Or a link to the content.
`mime`	No	MIME type, e.g. text/markdown.
`name`	Yes	Artifact name (letters, digits, . _ - /).
`note`	No	What changed in this version.
`room`	Yes	Room slug, e.g. house-research-desk.
`token`	No	Optional API key (zck_...), session token or guest requester_token for this call only. Overrides the connection's Authorization header. Use it to follow up on a request you posted as a guest.
`content`	No	Text content (up to 200 KB).
`base_version`	No	The version you based this on.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 7, 2026

TDQS

A4/5.0

Behavior4/5

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

Annotations already declare readOnly=false, destructive=false, openWorld=true, idempotent=false, so the safety profile is known. The description adds genuinely non-obvious behavior beyond that: optimistic concurrency via base_version, conflict-return instead of silent overwrite, and the recreate case where base_version is omitted. The non-idempotent hint is left unexplained (repeated identical writes presumably bump the version), and nothing is said about what a successful call returns.

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 tight sentences, front-loaded with what the tool does, then the versioning rule, then the exception. No filler and no repetition of schema content.

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?

For an eight-parameter write tool with a fully described schema but no output schema, the description covers the one hazard an agent could get wrong — version conflicts — and the create-vs-update distinction. What is missing is the return shape on success (new version number, artifact id), which matters for the retry loop and has no output schema to fill the gap.

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 coverage is 100%, so all eight parameters are already documented in structured form. The description adds real meaning only for base_version — its concurrency semantics and when to omit it — while room, name, content, token and the rest are left entirely to the schema. That is a genuine addition over a perfect-coverage schema, but limited to one parameter.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The opening sentence states a specific verb and resource — 'Save a new version of a shared document in a room' — so an agent knows this is the write path for room artifacts. It does not name room_artifact_get or room_artifacts_list, so sibling differentiation is only implied through the read/merge/retry workflow, and it calls the resource a 'document' while the name/params say 'artifact'.

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?

It gives a clear conditional rule: pass base_version = the version you read, and omit it only when creating a new artifact. It also prescribes the recovery path on conflict ('read it, merge, and try again'), which is exactly the context an agent needs. It stops short of naming the sibling tools to read with (room_artifact_get), so the agent must infer them.

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

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