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

readOnlyHint already tells the agent this is a safe read, so the description's job is domain context – which it supplies by naming the Czech address-book concept ('adresar') and enumerating the default returned fields (kod, name, ic, dic, e-mail, phone, address). It omits pagination/result-count behavior, but the entry that 'kod' links to invoices is genuinely useful cross-tool context.

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?

Two sentences, front-loaded with the core action and resource, and the second sentence carries a non-obvious workflow link rather than filler. The field enumeration is dense but each item is informative.

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?

For a six-parameter, zero-required read tool with no output schema, the description covers what the tool searches, what fields come back, and how the returned code is reused. Only paging/result-count expectations are left implicit, which the schema largely handles.

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 coverage is 100%, with limit/start/order/search/fields/city all documented in the schema itself. The description adds no parameter-level detail beyond the schema, so the baseline 3 applies.

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 ('List or search') and resource ('the address book (adresar): customers and suppliers'), and names the domain fields available. It is clearly distinguishable from abraflexi_get_contact (single record) and from the invoice list siblings, though it never explicitly names those alternatives.

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?

Usage is implied by 'List or search' and the note that 'the code from here identifies the customer in invoices' hints at the follow-up workflow. There is no explicit when-to-use/when-not guidance versus abraflexi_get_contact, abraflexi_list_records, or abraflexi_create_contact.

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