Loading ToolBench
MCP server for Parity Studio and NodeSlide. Gives coding agents governed deck reads, reviewable edits, traces, and design-to-code workflows.
Parity Studio MCP demonstrates solid tool design with comprehensive descriptions and well-structured schemas. All 15 tools have clear, detailed descriptions (avg 180 chars) explaining purpose, prerequisites, and return values. Input schemas are present and typed for all tools. Tool naming follows verb_noun convention (search_, inspect_, list_, read_, plan_, apply_, export_). However, several tools expose sensitive parameters (ownerAccessKey) that should use server-side injection, and some parameter descriptions lack explicit constraints (e.g., max lengths for IDs). Output schemas are not formally documented in the source. Error handling guidance is minimal, tools lack recovery hints for common failure modes.
The topology gate. Given the artifact kinds a rendered slide actually contains, report whether the archetype is satisfied or whether the slide fell back to a forbidden substitute such as prose standing in for an architecture diagram. Returns an empty violation list when the slide passes.
Fail-closed licence gate. Answers whether a specific source may be downloaded, cached, displayed, redistributed, indexed for retrieval, or used for training. An unregistered source, an unapproved status, or a use above the access lane all deny, and every denial carries its reason. Call this before ingesting or reusing any external asset.
Return one archetype: its narrative job, the artifact kinds that satisfy it, and the named substitutes the topology gate rejects.
List every reviewed Atlas source with its access lane and review status. Sources absent from this list are denied by default.
Find slide archetypes by narrative job. Each result names the artifact the slide must actually contain and the substitutes that do not satisfy it, so an agent picks a real chart or diagram rather than prose describing one. Read-only; results are deterministic and capped.
ownerAccessKey exposed as optional parameter in 8 tools (plan_patch, apply_patch, list_patches, get_patch, list_traces, list_versions, get_version, export_pptx, export_json). Credentials must use server-side injection via environment variables, not tool parameters. Agent traces log all parameters, secrets leak into logs and prompt history.
Output schemas not documented in source code. Tools return complex structures (patches, traces, versions, workspace) but LLMs cannot see field definitions, types, or required fields. This forces LLMs to guess at response structure and risks downstream tool call failures.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 60 | 2026-07-28+ | v2 |
Apply a patch to the deck: execute operations and record the change. Requires owner access and explicit consent.
Export the deck as a JSON file. Returns the full workspace structure. Requires owner access.
Export the deck as a PowerPoint file. Returns a base64-encoded PPTX file. Requires owner access.
Get a single patch by ID with full details. Read-only.
Get a single version (snapshot) by ID. Read-only.
List patches for a deck with pagination. Read-only.
List traces (audit log) for a deck with pagination. Read-only.
List versions (snapshots) for a deck with pagination. Read-only.
Plan a patch: decompose a brief into operations, validate against the workspace, and return a reviewable summary. Does not apply changes. Requires owner access.
Read the current deck workspace: slides, elements, sources, patches, traces, and versions. Scoped to deck or slide level. Read-only.
Parameter constraints not fully specified in descriptions. archetypeId, sourceId, deckId, patchId, versionId accept '1-120 characters' but lack regex patterns, character restrictions, or format hints. LLMs cannot validate inputs before calling tools.
Error handling lacks recovery guidance. Tools do not document what errors are retryable, user-fixable, or fatal. No examples of error responses or actionable error messages. LLMs cannot determine next steps on failure.
Destructive operations (apply_patch, export_pptx, export_json) require explicit consent parameter but lack confirmation/dry-run pattern. No mention of rollback capability or undo tools if operations partially fail.