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

With no annotations, the description carries the full burden and largely meets it: it discloses the review step, the outcome on approval (ERC-1155 NFT listing on Base), the exact revenue splits for brand vs RRG briefs, the 5 MB JPEG/PNG constraint, and a fallback submission channel. It does not say whether a submission can be edited, replaced, or withdrawn, or what the immediate response contains, leaving a modest gap.

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?

Despite its length, the content is front-loaded with purpose and prerequisites and every block earns its place: revenue terms, image constraints, the base64 workaround, and the parameter constraints. There is little repeated filler relative to the amount of decision-relevant 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?

For a 9-parameter mutation tool with no annotations and no output schema, the description covers review outcome, economics, format limits, and the offline fallback well. It stops short of describing the immediate return (e.g., submission ID/status) and does not cross-reference get_submission_status, so an agent cannot predict the response without another call.

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 100%, so the schema already documents all nine parameters, giving a baseline of 3. The description's required/recommended breakdown and revenue framing of creator_wallet add only marginal meaning beyond the schema, and it actually omits image_url from its 'Required' list even though the schema marks it required.

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 verb and resource ('Submit an original artwork for review') and situates it as Step 2 of a CREATE pipeline, which separates it from the adjacent upload_image tool. An agent can tell immediately that this is the final submission action, not a hosting step.

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?

Explicit prerequisites are given: call list_briefs or get_current_brief FIRST for a brief_id, and call upload_image FIRST if the image exists only as base64. It even names a genuine alternative path (email submission when the runtime truncates base64), which is exactly the routing information an agent needs.

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