keyso_post_tools_check_top

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

With no annotations provided, the description must disclose behavior, but it does not. It mentions only the HTTP method and path, and a sample query, without stating whether the operation is read-only, what data it affects, what it returns, or any side effects. The phrase 'highlighting tops' is too vague to convey any behavioral detail.

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?

While the description is short, it is under-specified rather than concise. It includes a verbatim URL example but omits essential information about purpose and behavior. The placement of the example is not front-loaded with useful context; instead it is a bare request sample that assumes prior knowledge.

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 tool has no output schema and only four parameters, but the description fails to explain what the tool returns, what the POST body should contain, or what the 'base' parameter does. Given the complexity of the sibling tools and the lack of any behavioral annotation, this description is completely inadequate for an agent to call the tool correctly.

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 has descriptions for token and base_url, which are self-explanatory, but base only has 'in: query' and the description does not clarify its meaning (e.g., region code). The body parameter is an empty object with no semantics. The example uses base=msk but doesn't explain what 'msk' means. The description adds no value beyond the schema, and because schema descriptions are weak for base and body, this is below the baseline.

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 'Подсветка топов' ('highlighting tops') is vague and does not specify what 'tops' refers to or what the tool actually does. It provides a method and path but no resource or behavior, and it does not distinguish itself from the sibling tools like check_top_concurents_domains. The name implies 'check top', but the purpose remains unclear.

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?

There is no guidance on when to use this tool versus alternatives. It does not mention any conditions, prerequisites, or exclusions. The example request is provided but does not explain the context in which this tool should be chosen over siblings, leaving the agent without routing information.

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