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

With no annotations, the description carries the full burden, and it does disclose behavioral context by naming the data provenance (on-chain registration + indexed transactions) and the result categories. It omits anything about data freshness, caching, permissions, or failure modes, which an agent would want for a 1-param lookup with no annotations.

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?

Three short, front-loaded clauses: what it returns, where data comes from, and what it is not. No filler, though the terse style borders on under-specification rather than pure conciseness.

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?

An output schema exists, so return values need not be explained, and the description covers purpose, data source, and non-goals for a simple single-parameter tool. It is otherwise complete, though written in Czech while sibling tooling is English, which slightly raises comprehension risk for the calling agent.

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 should compensate, but it says nothing about the 'address' parameter (expected format, chain, checksum, etc.). The single param name is largely self-evident, keeping this at baseline rather than lower.

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 names the resource (address reputation/risk) and enumerates the exact output levels (LOW/MEDIUM/HIGH/UNKNOWN), so an agent knows what it gets back. It also rules out the sibling get_agent_sla by stating 'Ne SLA' and disclaims trade success rate, aiding disambiguation. It lacks a clear action verb and a plain statement of 'checks a wallet address', but the intent 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?

It gives explicit negative routing guidance ('Ne SLA, ne úspěšnost obchodu'), steering the agent away from the SLA and trade-performance tools. However, it never states positively when this tool should be preferred (e.g., before trusting an address), so the condition that selects it must be inferred.

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