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

Annotations already declare readOnlyHint and idempotentHint, so the safety profile is covered. The description adds genuinely useful behavior beyond that: free mode only reads what the service already knows, off-memory sections return 'missing' with AUTH_REQUIRED, and the call costs 0 operations. The only weakness is that the identifier-format sentences describe behavior this zero-parameter tool does not perform.

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 core content (mode, login, free-tier limits, cost) is front-loaded and useful, but the middle segment about 'id' formats and search_companies is irrelevant to a no-argument tool and inflates the text. One sentence of genuinely off-topic material undercuts an otherwise compact line.

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 spelled out; the description still covers what an agent needs — mode, auth state, free-tier restrictions, AUTH_REQUIRED behavior, and cost. Only the misplaced identifier discussion keeps it from being fully tailored to this tool's actual surface.

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 zero parameters the baseline is 4, but the description explicitly discusses an 'id' argument (KRS/NIP/REGON/address/'p-…'), which does not exist in this tool's schema. This injects parameter-like semantics that could mislead an agent into expecting or supplying an identifier, so it scores below the clean 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 opening clause names a concrete verb and resource: returns the operating mode (free or Pro) and login status, plus free-tier usage instructions. This is distinguishable from data-fetching siblings like get_company, though the later sentences about 'id' formats (KRS, NIP, REGON, 'p-…') describe identifier semantics that belong to other tools and muddy the purpose.

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?

'Użyj na początku rozmowy' gives an explicit call condition (start of conversation) tied to a stated goal — knowing whether off-memory sections can be fetched. The additional 'zacznij od search_companies, gdy nie masz identyfikatora' is guidance for a different tool and reads as copy-paste, but the core when-to-use is unambiguous.

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