auth_set_token

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

With no annotations provided, the description must carry the behavioral disclosure burden. It does explain that the tool imports a JWT directly and describes where the token comes from, but it does not mention potential side effects such as overwriting an existing session, whether the token is validated, or what happens after the token is set.

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 short and front-loaded: the main action comes first, followed by the source and the specific use-case. Every sentence provides useful information with no filler.

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 tool with a single required string parameter and an output schema, the description is largely complete: it tells the agent what the token is, where to get it, and when to use the tool. It could add a note about whether the tool replaces an existing authenticated session, but this is a minor gap given the low complexity.

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 0%, so the description must compensate. It adds substantial meaning by identifying the token parameter as a JWT and specifying the exact browser source (__NEXT_DATA__.props.pageProps.token), which goes beyond the schema's generic 'token' property.

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 uses a specific verb 'Импортировать' and a clear resource 'JWT', and even names the source location in the browser. This clearly distinguishes it from siblings like auth_send_code, auth_login, and auth_logout, and the mention of a workaround further differentiates it from the normal SMS flow.

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?

The description explicitly states when to use this tool: as a fallback if SMS login did not work ('Обходной путь, если SMS-логин не отработал'). This gives an agent a concrete trigger and implies the alternative normal flow is SMS-based authentication.

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