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

No annotations are provided, so the description carries the full disclosure burden. It implies a write plus sharing ('shared experience cube') but never states who sees the cube, that cube_publish defaults to true (a real side effect), how supersedes/cube_id rebinding behaves, or whether creation is idempotent. For a mutating, publishing tool this is a significant 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?

It is a single compact sentence with the required-field list front-loaded, so there is little waste. But the compression comes at the cost of clarity: 'DUTY at task end' and 'send duty=cube_nothing' are dense internal shorthand that force the agent to guess.

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 12 parameters, no annotations, no output schema and 0% schema coverage, the description is far too thin to let an agent call this correctly. It never explains what a cube is, what the optional fields change, or what publishing means, leaving the majority of the call surface undocumented.

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 0% across 12 parameters, so the description must compensate and largely doesn't. It mentions topic, essence, rules, skill_md, hooks and carrier but explains none of them, and omits kind, cube_id, msg_ref, evidence, supersedes and cube_publish entirely — including the publish flag, which materially changes the tool's effect.

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?

The description names a verb (create) and a resource (shared experience cube) and lists the three required fields, so the basic action is recoverable. However, 'cube' is unexplained jargon and nothing distinguishes this from sibling tools like cube_install or cube_link, so an agent cannot confidently tell which creation path applies. 'DUTY at task end' adds ambiguity rather than clarity.

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 does state a trigger ('at task end') and gestures at an alternative ('send duty=cube_nothing'), which is more than most descriptions offer. But the alternative is phrased in an internal vocabulary that is never explained, and there is no guidance on when to use cube_create versus cube_install or cube_link.

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