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

Annotations already declare readOnlyHint=false, idempotentHint=true and destructiveHint=false, but the description goes further: it names the exact dedupe key ('same property, tenants, room and start date is answered instead of added'), states the module must be switched on, states the organisation permission requirement, and names the return value. These are operational facts not derivable from the annotations.

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?

Dense but front-loaded: the first sentence defines the resource, the next two cover dependencies, then duplicate handling, formats, gating and the return. Every sentence carries a distinct operational fact with no filler or restatement of the tool name.

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 15-parameter mutation tool with no output schema, the description closes every gap an agent needs: what is created, what it depends on, dedupe behavior, module/permission gating, units and date format, what is returned, and the natural next step (create_income). Nothing material is missing.

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 15 parameters including formats, enums and defaults. The description reinforces dates as New Zealand yyyy-MM-dd and money as NZD, but adds little parameter-level meaning beyond what the schema carries. Baseline 3 applies when the schema does the heavy lifting.

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?

Opens with a specific verb+resource ('Adds a tenancy') and immediately defines the domain object ('one or more tenants renting a rental property, or a room in it, from a start date at a weekly rent, with its bond'). An agent can distinguish this from update_tenancy, create_property and create_contact without opening any schema.

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?

Explicitly states prerequisites and the alternatives to call first ('The property comes from list_properties (add a new one with create_property) and each tenant is a contact of type tenant from list_contacts (add a new tenant with create_contact first)'). It also names when-not conditions: the dedupe rule, the module requirement, and the permission gate via list_organisations.

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