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

Annotations already declare this is a read-only, idempotent, non-destructive, closed-world operation. The description adds scope by saying it reads all saved measurements for a single project and clarifies the measurement content. It does not add behavioral details such as permission requirements, pagination, or response 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?

The definition is a single efficient sentence with the core action and scope front-loaded. Every clause adds useful context: what is read, for which project, what the data represents, and an example use case.

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 two-parameter read tool with full schema coverage and annotations covering safety, the description is nearly complete. It explains the returned measurement types and gives a practical use case. It omits only the projectName fallback detail, which is already covered by the schema.

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 projectId and projectName are already documented in the input schema. The description mentions projectId as the lookup key but does not explain the projectName fallback behavior beyond what the schema already states. It therefore adds little meaning beyond 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 uses a specific verb and resource: it reads all saved measurements of one project. It also clarifies the domain term Aufmaß as dimensions, areas, and quantities, making the tool's output understandable. It does not explicitly distinguish itself from addProjectMeasurement, though 'read all saved' implies read-only retrieval.

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 description provides one usage context, 'e.g. to price a quote,' which hints at when the tool is useful. It does not state when not to use it or name alternatives such as fetchProjectDetailContext for broader project data. Usage guidance is therefore implied rather than explicit.

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