NexDoc Design

Update design

update_design

Destructive

Start an update run on an existing job with edit instructions (diff-style). Always tell the user job_id and the NEW run_id. Do not share the previous viewer_url — that preview is the old design. If the result includes concurrency_notice, show that reminder. Same wait policy as create_design: wait_for_run once on the new run_id, then offer email instead of looping. Only share viewer_url after THIS run's status is completed. New photos: request_file_upload (or upload_file on stdio) then file_ids. Do not base64 a large image. Do not generate a replacement.

Input Schema

TableJSON Schema

Name	Required	Description
`wait`	No	Avoid. Prefer wait_for_run once after this returns.
`format`	Yes	Keep the same format unless changing medium
`job_id`	Yes
`content`	No
`file_ids`	No	file_… ids from request_file_upload / upload_file after status is ready. Preferred for photos and large files — do not also base64 them.
`asset_files`	No	Last-resort inline bytes for tiny files. Prefer request_file_upload + file_ids.
`asset_paths`	No	Local filesystem paths to upload (stdio MCP only). Prefer upload_file then file_ids for large photos. Remote/OAuth MCP cannot read the client's disk — including /mnt/user-data/uploads/ — use request_file_upload + PUT + file_ids instead. Never omit a user photo or generate a replacement.
`timeout_sec`	No	Only with wait:true. Default 45 seconds, capped at 90.
`content_path`	No	Local path to a content file (stdio). Remote MCP: put copy in content instead.
`instructions`	Yes	Edit instructions against the current design
`notify_email`	No	If true, email the account owner when the run finishes. Set this immediately when the user asks to be emailed (including at the start of the request).

Output Schema

TableJSON Schema

Name	Required	Description	Default
`error`	No
`job_id`	No
`run_id`	Yes
`status`	Yes
`log_tail`	No
`next_step`	No
`charge_usd`	No
`created_at`	No
`viewer_url`	No
`commit_hash`	No
`completed_at`	No
`notify_email`	No
`still_running`	No
`concurrency_notice`	No
`previous_preview_stale`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedSep 15, 2026

TDQS

A4.3/5.0

Behavior4/5

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

Annotations already indicate destructive and open world. The description adds that it creates a new run, potentially destructive to previous run context, and provides wait policy. Mentioning not to share old preview and to show concurrency notice adds context beyond annotations.

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?

Dense and informative, each sentence adds action or constraint. Front-loads the core purpose and then details key behaviors. No fluff.

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?

Given a complex tool with 11 params and output schema exists, the description covers critical behavior and error handling, file upload preferences, wait policy, and constraints. Complete enough for an agent to correctly invoke.

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 already provides detailed descriptions for most parameters, with 82% coverage. The description reinforces key guidance like preferring file_ids over base64. It does not add meaning for parameters not covered, but overall schema carries the burden.

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?

Description states it updates an existing job with diff-style edit instructionsJS。 It mentions creating a new run and uses the verb 'start an update run' with a specific resource, which is clear. It does not explicitly differentiate from create_design, but the diff-style edit focus implies the difference.

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 instructs to wait once then offer email, to avoid looping, and to prefer file uploads over base64. It names alternatives like request_file_upload, upload_file, and wait_for_run, providing clear guidance on when to use them. Also tells not to share old viewer_url and to only share after completion.

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

All NexDoc Design 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?