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

Annotations already declare this a safe, idempotent read (readOnlyHint, idempotentHint, destructiveHint=false), so the bar is lower. The description adds genuine non-obvious context beyond them: PESEL is never returned (only birth_year), all names are returned, and JDG entities are out of scope. It still says nothing about authorization or coverage/latency, so it stops short of 5.

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 sentences with no filler; the key scope statement leads. The parenthetical '(same as zarząd / wspólnicy)' is slightly cryptic and adds ambiguity rather than clarity, keeping it just below 5.

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?

There is no output schema, so the description must carry return-value information, and it does disclose the important output traits (names included, birth_year instead of PESEL, JDG excluded). That is sufficient to call the tool correctly, though the fallback behavior among the three optional parameters is left implicit.

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 100%, so krs, nip, and name are already documented in the schema with formats and fallback logic. The description adds no additional meaning about these parameters or precedence between them, which is the baseline 3 when the schema carries the load.

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?

States a specific verb and resource: CRBR beneficial owners for a KRS company, scoped to the Polish register context. It partially differentiates from the sibling get_company_people by noting the returned names are 'same as zarząd / wspólnicy', but it does not explicitly contrast the two tools, so an agent must infer the distinction.

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?

Provides one useful exclusion ('JDG are not in CRBR'), which tells the agent when the tool is not applicable. However, it never names an alternative tool (e.g., get_company_people) or states the positive condition for choosing CRBR data over the general people lookup, leaving the when-to-use decision implied.

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