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

With no annotations at all, the description carries the full burden, and it only partially meets it. It does disclose a genuine behavioral trait — that a price in Kehr is paid with a signed coin payment made here, and that scripts are Counterscript (taught by workshop_look) — but says nothing about irreversibility of mutations, failure modes, permission requirements, or what any op returns.

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?

Given 40+ ops, substantial length is unavoidable, but the semicolon-delimited run-on blob is hard to scan and mixes op signatures, payment rules, and data-format notes without structure. The purpose sentence is front-loaded, but the body offers no grouping or hierarchy to help an agent locate the relevant op quickly.

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?

This is a highly complex, mutation-heavy multiplexer with nested args, no output schema, and no annotations; the description covers the op namespace but not return values, error behavior, or the meaning of many args. It defers formats to workshop_look, which is fair, but that still leaves the definition short of what an agent needs to call it reliably.

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% for the two parameters, so the description must compensate, and it makes a real effort by enumerating the valid 'op' values and listing most arg keys per op. However, many arg semantics are left opaque (data, note, part, kinds, needs, work, proposal contents), so an agent can pick an op but still not know what to put in several fields.

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 opening 'Act at the Workshop, signed with this session’s key' states a verb and a domain but is essentially a catch-all; the actual purpose only emerges from the long list of ops that follows. An agent can infer this is the write/action counterpart to workshop_look, but the description never says so, and it is not distinguished from siblings like 'act' or 'enter'.

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?

There is no statement of when to use this tool versus the many siblings (act, book, enter, find_table), and no sequencing guidance for the ops themselves beyond a single parenthetical that vote/open 'passes with more than half of the members the band had when it opened'. Op names are listed but not framed as 'use X when Y', so routing remains guesswork.

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