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

Annotations already cover safety (readOnlyHint, idempotentHint, destructiveHint), so the description does not need to restate those. It adds little beyond the query-match behavior and does not disclose ordering, pagination, or localization default behavior, which are minor for a listing tool.

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 description is one short, front-loaded sentence with no filler. It is concise, though it stays close to the title and could have used the available space to add one more behavioral or scoping detail.

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 simple, optional-parameter listing tool with read-only and idempotent annotations, the description is nearly sufficient for an agent to select and invoke it. The lack of an output schema and any mention of result shape or defaults is a minor gap given the tool's simplicity.

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?

The schema already documents lang and query with useful descriptions; limit only has min/max bounds. The description's 'match a query' reinforces the query parameter but adds no new meaning for limit or lang. With 2 of 3 parameters already described in the schema, this is adequate.

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 uses a specific verb ('List') and resource ('Pionra country communities'), and adds scoping with 'match a query.' It is clearly distinct from singular get_community, though it does not explicitly name siblings for full differentiation.

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?

The usage context is implied: use this when you want a query-based list of communities rather than a single record. However, there is no explicit guidance about when to prefer this over search_pionra or get_community, and no exclusions are stated.

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