NexDoc Design

Create design

create_design

Destructive

Create a job (or reuse job_id) and start a generative run. Omitting job_id ALWAYS creates a NEW job — call at most ONCE per user request. If you already have a job_id (including from a prior create_design error), pass it or use update_design; never call create_design again without job_id for the same request. Always tell the user job_id and run_id as soon as this returns. If the result includes concurrency_notice, show that reminder (pay-as-you-go accounts run one design at a time). Do not set wait:true. If the user asked to be emailed (including in the original request), set notify_email:true here immediately — do not wait until after wait_for_run. After create, call wait_for_run ONCE (default ~45s). If still_running and they have not already asked for email, stop polling, show the IDs, and offer notify_run_email. Photos/logos: prefer request_file_upload (or upload_file on stdio) then pass file_ids — never compress or generate a replacement. asset_paths is stdio-only; asset_files base64 is a last resort for tiny files. After completion, return viewer_url and offer export (pdf/html/png) — do not publish unless the user asks.

Input Schema

TableJSON Schema

Name	Required	Description
`name`	No	Job name when creating a new job
`wait`	No	Avoid. Prefer wait_for_run once after create so the user sees job_id first.
`format`	Yes	Format slug, e.g. landing-page, report, business-card
`job_id`	No	Existing job id to reuse. Required when retrying after a partial failure or continuing the same request — omitting this creates a duplicate job.
`content`	No	Source copy (markdown/text)
`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	Design direction / edit notes
`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). Do not wait until after wait_for_run.

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.9/5.0

Behavior5/5

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

Annotations already indicate destructiveHint=true and readOnlyHint=false, but the description adds important behavioral specifics: omitting job_id always creates a new job, call at most once per request, concurrency_notice must be surfaced, notify_email should be set immediately, and after completion the user should see viewer_url. No contradiction with annotations exists.

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?

The description is front-loaded with the main action and every clause carries necessary operational guidance. However, it is a single dense paragraph of semicolon-separated constraints, which is difficult to scan; grouped bullets or sections would improve readability without adding length.

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?

The description covers the full lifecycle: creation, retry/duplicate avoidance, email handling, file upload preferences, polling via wait_for_run, concurrency notices, and follow-up actions like offering export. With an output schema present, nothing essential for correct invocation is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, but the description adds meaningful decision-level semantics beyond the schema: file_ids are preferred, asset_files is a last resort, asset_paths cannot work on remote MCP, notify_email must be set early, and wait should be avoided. This is far more than repeating parameter names.

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

Purpose5/5

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

The description states a specific action and resource: 'Create a job (or reuse job_id) and start a generative run.' This clearly distinguishes the tool from siblings like update_design and wait_for_run by naming the core outcome.

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?

The description gives explicit when-to-use and when-not-to-use guidance: reuse job_id or use update_design if a job already exists, never call again without job_id for the same request, prefer request_file_upload for files, and use wait_for_run after creation. It also states exclusions like 'Do not set wait:true' and asset_paths being stdio-only.

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?