submit_job_jsonSubmits a creative job using a JSON payload serialized from the action schema parameters. Reuse the original idempotency key on timeouts instead of resubmitting.
与 submit_job 完全等价的简洁输入入口。先查 action_schema，将含 action 的完整参数对象序列化为 payloadJson。后端仍逐字段严格校验；超时必须复用原 idempotencyKey，不自动重提。
| Name | Required | Description | Default |
|---|---|---|---|
| payloadJson | Yes | ||
| idempotencyKey | Yes |
Changes observed during successful MCP inspections.
v0.1.1Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already flag destructive=true, idempotent=true and openWorld=true, so the safety profile is known; the description adds real context beyond them – the backend still strictly validates each field, and timeouts must reuse the original idempotencyKey rather than resubmitting. That retry/idempotency guidance is the kind of behavioral detail the annotations cannot convey.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences with no filler: equivalence and input format first, then the prerequisite lookup, then the retry constraint. Every sentence carries actionable information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With only two parameters and no output schema, the description covers the call mechanics well by deflecting payload structure to action_schema and spelling out retry behavior. It is slightly incomplete on return value and payload encoding, but nothing critical for a correct invocation is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must carry the burden, and it does: it explains that payloadJson is the serialized full argument object including an 'action' field, and that the shape must be discovered from action_schema first. It also gives idempotencyKey semantics (reuse the original on timeout), though it never states that payloadJson is a JSON-encoded string with size limits.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific action (submit a job through a JSON payload entry point) and explicitly declares it is fully equivalent to the sibling submit_job, which lets an agent distinguish the two. The 'concise input entry point' framing is clear, though it never says what the tool actually returns or which action values exist.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives a concrete prerequisite ('先查 action_schema') before calling, and an explicit retry rule on timeout (reuse the original idempotencyKey, never auto-resubmit). It also frames this as equivalent to submit_job, implying the two are interchangeable, but it doesn't say when to prefer one over the other.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.