Зарегистрировать рекламодателя (ОРД)

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

The description discloses that there are no update/delete endpoints, that mistakes must be replaced with new records, that legal details must match the state registry, and that creation consumes API points (apiPointBalance). It does not mention any side effects on other resources or auth requirements, but given the annotations already indicate non-read-only and non-idempotent, the additional info is useful.

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 informative but somewhat lengthy, packing multiple important details into one block. It is not repetitive or tautological, and the key facts (return value, no-update caveat, legal checks) are clearly stated without redundancy. Slightly overexplained but justifiable given the domain complexity.

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?

The description provides a complete operational picture: creation under the account, return value with id and balance, the id's role in other entities, legal validation rules, and guidance to check existing records first. This is sufficient for an agent to decide when to call this tool and what to expect.

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?

The schema covers all parameters with required flags and reasonable descriptionscars. The description clarifies legalRole enums, kpp conditionality for ul vs ip, and the inn digit count. Addresses are minimally described but acceptable as generic strings. Could be more explicit about actualAddress matching legalAddress if identical, which is partially implied.

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 clearly states the verb (регистрирует) and resource (рекламодателя/контрагента ОРД), specifies it returns id and apiPointBalance, and explains the significance of the id for campaigns and contracts. It distinguishes from list_advertisers, which is a search tool, so the purpose is unambiguous.

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?

Explicit guidance is given: because there are no update/delete endpoints, the agent is advised to first search via list_advertisers to avoid creating duplicates. This directly steers tool selection and sequencing among siblings.

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