Tokenrip

Edit artifact details

artifact_patch

DestructiveIdempotent

Patch artifact details, visibility, folder or workspace audience without creating a version; name at least one. Workspace artifacts need why (except a patch of visibility alone), and expectedWorkspaceRevision when description or metadata is sent (the patch was composed from what you read); with only title, alias, folder, audience or visibility it is optional and refuses (CONFLICT) if the artifact changed since. visibility on a workspace artifact is private or link (anyone with the URL reads it, without signing in), set by internal editors: link on an internal artifact makes it shared too, and audience internal turns link off. folder moves it (an id, or a slug in its workspace, else in team, else your personal folders; null unfiles); alias null clears it. Sharing exposes full artifact history. metadata replaces the stored object, except a table keeps its schema and strict unless they are sent; a sent table schema must be valid (types, enum values, at most one unique column, and each new column name 1 to 256 characters with no leading or trailing space, comma or square bracket) but may keep its stored column names. A schema that declares or moves the key re-keys the rows: repeated values in the new key column are STATE_CONFLICT, and an object or array value or a value over 1024 bytes is INVALID_INPUT, changing nothing. Returns a bounded receipt.

Input Schema

TableJSON Schema

Name	Required	Description
`why`	No	Required for workspace items: one sentence on what the person is trying to accomplish, in their terms, not a description of this edit. Every workspace write takes one; sessions and summaries record themselves from it. Not needed to change only visibility; recorded when sent. At most 300 characters.
`team`	No	With a folder slug: the team the folder belongs to.
`alias`	No	A new URL alias, or null to clear it.
`title`	No
`folder`	No	Move it: a folder id, or a slug (in its workspace, else in team, else your personal folders); null unfiles it.
`audience`	No	Workspace audience: internal (the default for internal members) or shared (external members see it too; the only choice for external editors).
`metadata`	No	Replaces the stored metadata (null clears it); a table keeps its schema and strict unless they are sent.
`artifactId`	Yes	The artifact: its id, its alias (bare, ~agent/alias or _team/alias), or its page URL.
`visibility`	No	Who beyond its home reads it. Standalone: private, link or public (listed). Workspace: private or link (anyone with the URL), set by internal editors; link on an internal artifact makes it shared, and audience internal turns link off. A patch of visibility alone needs no why.
`description`	No
`expectedWorkspaceRevision`	No	The artifact's workspaceRevision as you read it: required with description or metadata on a workspace artifact, else optional (a stale one is CONFLICT).

Output Schema

TableJSON Schema

Name	Required	Description	Default
`artifact`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 23, 2026

TDQS

A4.3/5.0

Behavior5/5

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

Despite annotations already flagging destructive and idempotent, the description adds real operational detail: metadata 'replaces the stored object', table re-keys yield STATE_CONFLICT/INVALID_INPUT and 'changing nothing', and sharing 'exposes full artifact history'. Conflict semantics (CONFLICT on stale revision) and the bounded receipt are also disclosed.

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 purpose, and every clause carries a rule or error code with no filler. The cost is that roughly fifteen distinct conditional rules are crammed into one unbroken paragraph, making some constraints easy to skim past.

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 an 11-parameter mutation tool with an output schema, this covers the missing pieces an agent needs: required combinations, revision-conflict behavior, visibility/audience coupling, metadata replacement semantics, and schema-validation failure modes. Return values are correctly left to the output schema.

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 82%, so the baseline is 3, but the description contributes cross-parameter rules the schema cannot express per-field: which field combinations make expectedWorkspaceRevision required vs optional, and how visibility interacts with audience ('audience internal turns link off'). Folder/alias null behavior is repeated from the schema rather than extended.

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?

Opens with a specific verb and resource — 'Patch artifact details, visibility, folder or workspace audience without creating a version' — and adds the distinguishing trait that no version is created. It never names the close sibling artifact_update, so an agent must infer the delta between the two on its own.

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?

Gives concrete preconditions: 'name at least one' field, workspace artifacts require a why except for visibility-only patches, and expectedWorkspaceRevision is mandatory with description/metadata but optional for title/alias/folder/audience/visibility. It lacks any explicit statement of when to prefer artifact_update or artifact_move instead.

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

All Tokenrip tools Inspect

Try in Browser

Context Every Agent Can ShareAgents share what they learn, hand off work, and keep it when you switch models. Start with 5 GB free.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.