Loading ToolBench
Self-hosted platform for publishing and sharing front-end artifacts and documents with sandboxed, versioned, shareable links. Provides MCP tools for AI agents to publish, find, read, update and share artifacts.
Strong foundation with 19 well-named tools following verb_noun convention (publish, update, edit, find, fork, share, delete, etc.). All tools have descriptions and input schemas with typed parameters. However, descriptions are inconsistent in depth, some are terse (e.g., 'Publish a site', 'Update a site', 'Edit a file') while others are comprehensive. Parameter descriptions are generally good but lack explicit constraints (e.g., no min/max for limits, no format specs for encoding enum values). Output schemas are not documented in the provided source. Error handling and recovery guidance are absent. Tool composition is sound (each does one thing), but descriptions could better explain WHEN to use each tool vs. alternatives (e.g., publish vs. upload_start workflow).
Clear official version
Check which remote Artifact Site account/server is connected, diagnose authentication, or check upload size limits. Returns identity, operator status and transfer limits. Authentication is already configured; do not request a token in chat. Operator credentials have no personal library. This is optional diagnostics, not a prerequisite for finding or publishing artifacts.
Delete a site
Edit a file
Export a site
Find artifacts
Terse descriptions on 8 tools (publish, update, get_site, read, delete, set_official, clear_official, operation_status, upload_status). Descriptions like 'Publish a site' and 'Update a site' lack context on WHEN to use each vs. alternatives, prerequisites, or what the tool returns. LLMs cannot distinguish between publish/update/upload_start workflows without richer guidance.
Output schemas not documented. No visibility into what fields publish, update, edit, find, get_site, read, fork, share, rollback, export, operation_status, upload_status, upload_start, upload_write, and upload_cancel return. LLMs cannot plan downstream tool calls or extract required IDs (e.g., version_id, slug) without documented response structures.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 67 | 2026-07-28+ | v2 |
Fork a site
Get a site
Publication status
Publish a site
Read a site
Roll back a site
Set official version
Create a share link
Update a site
Cancel an upload
Start an upload
Upload progress
Write upload content
Parameter constraints missing. 'limit' in find has no min/max bounds (baseline: 1 - 100 or similar). 'encoding' enum values (utf8, base64) lack format guidance. 'policy' enum in share is clear, but other enums lack context on when to use each value. No validation guidance for 'slug' format or 'operation_key' uniqueness requirements.
No error handling or recovery guidance. Tools lack descriptions of failure modes, retryability, or next steps. E.g., if publish fails due to quota, what should the LLM do? If fork fails because the source is deleted, what are alternatives? No error classification (retryable vs. user-fixable vs. fatal).
Destructive operations (delete, rollback, clear_official) lack confirmation or dry-run patterns. No mention of idempotency or whether repeated calls with the same operation_key are safe. LLMs may accidentally delete or rollback without explicit user consent.