abs_sessions

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

Annotations declare readOnlyHint=false and destructiveHint=false but say nothing about the write gate, auth, or hosting constraint; the description supplies all three (Bearer from ABS_API_TOKEN, self-hosted Audiobookshelf only, confirm-plus-env-var required, omission = no-op preview). It stops short of describing what post_session_close actually does to a session or whether repeats are safe, despite idempotentHint=false.

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?

Five dense sentences, each covering a distinct concern (scope, auth, hosting, help/parameters, write safety, action list) with no filler. Front-loading is decent, though the action enumeration would be more useful at the top than as a trailing clause after the confirm rules.

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 six-parameter, nested-payload gateway with no output schema, the description covers the things most likely to cause a failed or unsafe call: authentication, hosting environment, dry-run default, and the full action set. It omits per-action path-parameter expectations (e.g. which id 'get_session' needs) beyond pointing at 'help', which is a real but manageable gap.

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 all six parameters are documented in the schema itself, establishing a baseline of 3. The description adds only one genuinely new semantic — that 'target' is meaningful solely when action=help — and otherwise restates the confirm contract already spelled out in the schema.

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 by naming the resource domain (sessions toolset) and enumerates the four concrete operations (get, get_open, get_session, post_session_close), which lets an agent separate it from siblings like abs_items or abs_playlists. It never states in plain language what a 'session' is (an active playback session), so an agent must infer this from the action names.

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?

Gives explicit operational guidance: use 'action help' with a target to get an action's parameters, writes require confirm=true plus ABS_ALLOW_WRITES=true, and omitting confirm yields a dry-run. It does not say when to prefer abs_sessions over a sibling such as abs_items when looking for playback state, so selection guidance stops at the domain boundary.

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