Creator
List, read, create, and patch a drop. Free, reversible, and scoped to the caller.
The Creator category is the Creator Kit as four tools. The order is the loop —
list → read → create → patch.
Every one of them reads the owner from the auth context and takes no owner argument, so there is nowhere in the wire shape to name someone else. A drop that belongs to another creator is answered the same as one that does not exist: the store filters by owner inside its own query, so the tools are not id oracles.
Prices are exact
priceUsd is a decimal string, never a float, so a price at the top of the
module's range is not silently rounded. supply is
{ total, minted, remaining }, and it is fixed at creation — a drop that has sold
editions cannot change how many editions exist, because every sold edition's buyer
was promised a collection of a given size.
Two refusals that exist because the mistake is invisible
A paid drop needs creatorAddress. Putty never holds a creator's takings and
has no address to fall back on, so a checkout that takes money and loses it is
refused rather than defaulted.
A patch is validated as a whole, not field by field. Two mistakes only appear when the merged record is judged: lowering a price to zero on a drop with no payout address, and clearing the address on a paid one. Both are refused naming the field.
Every problem with a drop is reported at once, as sentences, so a creator fixing one field per round trip is not forced into three.
What is deliberately not here
| Not exposed | Why | Where it really is |
|---|---|---|
| Minting an edition | a paid mint opens a real payment session | POST /creator/drops/{dropId}/mint |
Publishing (status: "live") | it makes a mint page publicly reachable, irreversibly | PATCH /creator/drops/{dropId} |
publish is one of putty's four approval types for exactly this reason, and the
only gate for it is the run approval path. A direct tool call has no run to ask
through, so drop_update has no status field at all — rather than accepting it
and reporting a patch that did not apply.
What the four tools do here is free and reversible: create a draft, and patch a
drop the caller owns. The drop lands as a draft and is not collectable until
the status is set through the real path.
contract_presets
List every contract the studio can generate, with each preset's parameters, their types and defaults, the OpenZeppelin files it is built on, its licence, its wizard feature flags, and its audit label. Takes no arguments, is public, and is FREE. Call it before generating anything: `params` is per-preset and the order is the constructor's order, so the catalogue is the only place to read a preset's shape from — a required parameter that is missing is refused naming it, and an optional one falls back to its declared default. `audit` is the label the deploy path will enforce for a CLEAN generation of that preset, and it is a label on putty's own template, not an external audit of anything. **This tool does not generate anything.** Generation is a metered operation and the MCP surface does not expose it: a tool that spends credits has to be gated by a run's approval, and a direct tool call has no run to gate. Ask the person to run the deploy path, which prices the generate, the compile, and the tests together.
Drops
The Drops MCP tools: `drop_list`, `drop_get`, `drop_create`, `drop_update`.