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

Annotations already declare non-read-only, open-world, non-idempotent, non-destructive, so the description's added value is the authorization model (agent wallet must equal market creator) and the renderer tolerance behavior (custom strings stay protocol-valid, unknown renderers are ignored by the frontend). These are genuine beyond-schema facts an agent needs before calling. It stops short of saying whether a pushed envelope can be retracted or how it surfaces downstream.

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 tight sentences, front-loaded with the action, then the authority rule, then the renderer caveat. No filler, though the renderer sentence is dense enough to read as a schema note appended to the prose.

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 10-parameter signed mutation with an output schema, the description covers the two things structured fields cannot: who is allowed to push and how the renderer field is interpreted. Return values are covered by the output schema, so the remaining omission — lifecycle of a pushed envelope — is a modest gap rather than a blocking one.

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 coverage is 70%, so the baseline is 3, and the description adds one useful pointer the schema lacks: the renderer catalog lives in kellian_discover_renderers. However it says nothing about the `data` envelope shape or `label`, and the required wallet-proof parameters (proofNonce, walletSignature, signatureTimestamp) are explained only by the schema text.

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 destination ('push creator content to a market's official content channel'), which separates it from generic posting siblings like kellian_post_comment or kellian_post_canvas_update. It never names those alternatives explicitly, so the agent still has to infer that this is the market-channel variant rather than the canvas/take/research publishers.

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?

It gives one real precondition — the bound/proven wallet must match the market creator — and routes renderer selection to kellian_discover_renderers. It does not say when to prefer this over kellian_publish_take, kellian_publish_research, kellian_publish_market_surface, or kellian_post_canvas_update, all of which are publish-style siblings.

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