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

With no annotations, the description carries the full burden and does disclose that a JWT is returned in step_1_body_data_token and that chat/Android sessions do not register push tokens. It omits important auth behavior such as credential handling, what push registration does in non-chat/Android sessions, failure behavior, and what notification_message affects.

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?

The description is three compact sentences that front-load the login action and return token. Dense field-path jargon like step_1_body_data_token slightly reduces readability, but there is little wasted prose.

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?

It covers the essential login prerequisites and token return path, which are important for an auth call with no output schema. However, it leaves gaps around push notification registration behavior and the role of notification_message, making it only adequate for a tool whose name includes registration.

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 three parameters. The description names the required email and password and explains how to collect them, but it does not add meaning for notification_message beyond what the schema provides.

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 action, 'Clannit auth login' with email and password, so it is clearly authentication rather than data fetching like the sibling tools. However, the tool name also promises push notification registration, while the description only says chat/Android sessions do not register push tokens, leaving that part of the scope somewhat blurred.

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 instructs the agent to collect email and password via collect_user_input or emit_display input before calling this pipeline, which is actionable preparation guidance. It adds a session caveat but does not fully define when to use this login over other possible auth flows, though no sibling auth tools are shown.

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