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

With no annotations, the description carries the full burden and does so well: it discloses that nothing is published until the given address answers the Court's letter, that liability is capped at the stated limit ('nothing beyond it is ever asked of you'), what happens on default (a register entry against your name, Registrar may refuse further undertakings), and that a set-aside order counts as neither kept nor broken. What it omits is whether an undertaking can be withdrawn or amended and what lodging returns to the caller.

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?

Roughly 230 words of legal-register prose with the actual action statement pushed past an opening motive sentence. Several clauses are atmospheric rather than operational (e.g. 'Every undertaking is a promise and the Court holds nothing against it'), and the key facts an agent needs are scattered instead of front-loaded.

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 complex, five-required-parameter mutation with no annotations and no output schema, the description covers a great deal: obligations incurred, publication timing, default consequences, cost, credential requirements, and an optional proof-of-word flow. It leaves only minor gaps such as the return value of a successful lodging (the sight flow implies an id exists but the response is never described).

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 five parameters in the tool's own voice. The description restates their meaning narratively (name read on the register, the address the Court asks, the limit in cents, the day stated) but adds no syntax or format detail beyond the schema, so the baseline of 3 applies.

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 does state a specific verb and resource: 'Lodges an undertaking under Enrolment Act 4.2', and it clarifies that the undertaking is published on the register beside a named agent. However, the core purpose is buried in the second sentence behind a first-person motive statement ('I want people dealing with this agent to know...'), and it never explicitly distinguishes itself from the read-side sibling read_undertakings or nearby lodge_* tools.

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 conveys the situation in which an undertaking is used ('so a counterparty reads it BEFORE it decides to deal') and adds cost/credential context plus an optional challenge path via GET/POST to /undertakings/{id}/sight. But it never states when NOT to use it or names an alternative tool, leaving the choice between this and siblings implicit.

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