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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is fully covered and the description need not repeat it. The description does add one genuinely useful behavioral fact beyond the annotations: the result is a bounded summary of "what is known" about the parcel plus a link to a full report, implying partial coverage. It stops short of saying whether gaps mean unknown vs. unavailable data, or what the linked report costs to fetch.

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 action and then a colon-delimited enumeration of covered domains, which scans well for an agent deciding relevance. The domain list is long but each item earns its place by telling the agent what a call will and will not answer. Minor cost: the enumeration is dense and untiered, with no indication of which domains are primary.

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?

With an output schema present and rich annotations, the description only needs to state scope, which it does through the domain list, and it adds the report-link behavior. For a one-parameter read-only overview tool this is close to sufficient. The remaining gap is routing: it never contrasts itself with get_parcel_section or find_parcel, leaving the agent to infer that this is the broad entry point.

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?

There is a single parameter with 100% schema description coverage, including an example format and the hint that it comes from find_parcel or find_parcel_at_point, so the schema carries the full burden. The description contributes nothing about parcel_id — no format reminder, no fallback if the ID is unknown. Baseline 3 applies when the schema does the heavy lifting.

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 gives a specific verb ("Sprawdź działkę") plus an enumerated scope: local plan, building conditions, flood, utilities, access, nature protection, landslides and local prices. That is concrete enough for an agent to know this is the broad-summary tool rather than a single-section lookup. It never names the sibling get_parcel_section, so the differentiation from it is left implicit.

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 only implied: "Pokazuje, co wiadomo o działce, i link do pełnego raportu" signals a first-pass overview that leads to a fuller report, which hints at when to reach for it. There is no explicit when-to-use, when-not-to-use, or named alternative (e.g. get_parcel_section) and no stated prerequisite for obtaining parcel_id, which only appears in the schema.

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