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

Annotations already declare readOnlyHint, idempotentHint, non-destructive, and closed-world, so the safety profile is fully covered. The description adds the filtering behavior but doesn't mention the automatic pagination behavior that the schema hints at, nor result ordering. With annotations carrying the behavioral load, a 3 is appropriate.

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 short sentences, front-loaded with the action and resource, followed by the filtering options. No filler, no redundancy.

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 filtered-list tool with full schema coverage and complete annotations, the description is adequate but nothing more. It omits whether both filters can be combined or what happens with no filter, minor gaps that an agent could reasonably want answered.

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 100%, so both filter params, plus pagination, are already documented in the schema. The description only restates that project_id and building_id act as filters, adding no format or combination semantics beyond the schema. Baseline 3 is correct.

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 and resource ('List building assignments for projects'), making it clear this returns project-building association records rather than buildings or projects themselves. Siblings like list_project_buildings vs list_buildings vs list_projects exist, and the description distinguishes this by naming the 'assignments' concept, though it doesn't explicitly contrast with those siblings.

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 states the two filter options (project_id or building_id), which implies when to use each. But it doesn't say whether filters are required, whether they can combine, or when to reach for this versus get_project_building or list_buildings. Usage is implied, not spelled out.

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