session_upload

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

No annotations exist, so the description carries the full burden. It adds one meaningful behavioral fact — an active session must exist before the upload can work — but it does not disclose side effects, failure modes for a bad local path or selector, whether the operation mutates server state, or what happens in response.

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 a compact single sentence with the main verb and object front-loaded, followed by parameter roles and the session prerequisite, with no filler words. The one slight redundancy is 'Паттерн form file upload', which re-labels what the initial clause already communicates.

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 two required parameters and an output schema, the description covers the core usage context: the action, the parameter semantics for the required args, and the session_start dependency that is vital in a session_* tool family. The notable gap is the unexplained max_chars parameter, plus minimal guidance on failure behavior such as a nonexistent file path.

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?

With schema description coverage at 0%, the description compensates partially by explaining selector (the file input) and path (the local path), which are the two required parameters. However, max_chars — an optional parameter with a default of 6000 — is not explained in either the schema or the description, so the agent cannot know what semantics it controls.

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 phrase 'Загрузить файл в форму' (upload file to form) directly expresses the action, and the explicit correspondence of selector to input[type=file] leaves no ambiguity about the target element kind.

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 provides one explicit prerequisite, 'Требует session_start', which tells the agent the tool cannot run on an empty session. It does not state when to choose this over session_form_fill or session_type, nor when not to use it; the file-upload usage context is mostly implied by the tool name and the selector clue.

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