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

Annotations only cover the safety profile; the description adds the substantive behavior: the fee is read from the municipality's official page, coverage is limited to Montréal, Québec City, Laval and Gatineau for now, the legal TAQ cap is included, and other Quebec municipalities return 'not collected' rather than an estimate. This is exactly the operational context annotations cannot convey.

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?

Four sentences, front-loaded with the trigger, and each one carries distinct information (when to call, what is returned and from where, fallback behavior, province routing). No filler or repetition.

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 no output schema, the description does the work of explaining the return value ('not collected', published provincial fees, TAQ cap) and coverage limits. It is nearly complete, though it never states behavior when all optional parameters are omitted or what happens for a Quebec municipality outside the four supported ones.

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%, so the baseline is 3, but the description goes further by explaining that `province` should be passed for non-Quebec jurisdictions and that `valeur` is the assessed roll value. It adds real usage semantics on top of the schema.

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 states a precise verb and resource (returns the filing fee for a request for review of a property assessment), plus the geographic scope (Quebec, with four named municipalities). It does not explicitly distinguish itself from close siblings like fenetre_revision or taxe_mutation, so an agent must still infer the boundary.

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 an explicit trigger ('Call this when the user asks how much it costs to file a request for review') and routes the agent to the province parameter for non-Quebec cases. It never names a sibling tool or states when to prefer an alternative, so the routing guidance stops just short of the top level.

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