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

Annotations already declare readOnlyHint=false, idempotentHint=true, and destructiveHint=false, so safety is covered. The description's 'Set the weekly availability hours' weakly implies full replacement of the week's schedule, but it never states whether omitted days are cleared, whether existing bookings are affected, or how timezone interacts with the windows.

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?

Two brief sentences, front-loaded with the action and followed by the payload contract. No filler and nothing buried.

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 nested-object mutation with no output schema and fully documented params, the description covers what the tool does and the payload format. The notable gap is the timezone parameter, which is central to availability semantics and is never referenced in the description.

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 100% and the schema already documents calendarId (UUID), timezone (IANA), and the weeklyHours map with the HH:mm example. The description's restatement of the day→[{start,end}] shape and HH:mm format duplicates schema content rather than adding new meaning, so the baseline 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?

States a specific verb and resource: setting weekly availability hours for a calendar, and clarifies the payload shape (day → array of start/end windows). It is distinguishable from the read-side sibling neuron_get_availability and from neuron_update_calendar, though it does not name those siblings explicitly.

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 guidance on when to use this versus neuron_get_availability, neuron_update_calendar, or neuron_team_availability, nor any stated prerequisite (e.g. must own the calendar). Usage is only implied by the verb.

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