get_country_rules

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

With no annotations, the description carries the full burden and does disclose genuinely non-obvious behavior: foundation rules are always included regardless of filters, and filters narrow rather than replace the base set. That composition semantic is the key thing an agent would otherwise get wrong. It leaves the read-only nature implicit in 'Get' and says nothing about size or cost of the response, but an output schema exists to cover the return shape.

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?

Front-loaded: the core purpose is sentence one, the composition rule second, the filter mechanism third, and the Args block last. Nothing is redundant, and the Args listing earns its place given 0% schema description coverage.

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 4-parameter read tool with an output schema and no annotations, the description covers purpose, result composition, and three of four parameters with examples. It is nearly complete; the only shortfall is the under-specified 'phase' filter and the absence of any hint about result size or how filters interact with each other.

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 0%, so the description must compensate, and it largely does: country accepts a name or ISO-style code with three examples, module is optional with two example values, and phase/area are documented as filters with 'all' defaults. The gap is 'phase' — 'Value chain phase filter' gives no example values or enumeration, so an agent cannot construct a valid value from the description alone.

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 opens with a clear verb+resource: 'Get regulatory and configuration rules for a specific country.' It scopes the retrieval to a country and explains the composed result set (foundation rules plus area-specific rules). It does not explicitly distinguish itself from siblings such as get_terminology, get_taxonomy, or search_knowledge, which an agent might reasonably confuse with a rules lookup.

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?

It gives useful implied guidance: foundation rules (GDPR, APPI, data residency) are always returned, and 'area' is the lever for domain-specific rules, with a concrete example ('safety-pv'). However, it never says when to prefer this tool over search_knowledge or get_taxonomy, nor when not to call it.

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