drawing_info

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

Since no annotations are provided, the description carries the full burden. It includes the response format 'OK n=<count>', which gives some transparency about the output, but it doesn't disclose potential side effects (likely none), specifics on what is counted (e.g., all model space entities), or error behavior. This is minimal but not absent.

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 a single, front-loaded phrase: 'Total entity count (OK n=<count>)'. Every word earns its place, providing the core purpose and expected response format without any redundancy. It is appropriately sized for a tool with no parameters.

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 tool with no parameters and a simple output, the description is mostly complete. It conveys the purpose and the return format. However, it could clarify what 'entity' includes (e.g., all entities in the drawing) and whether any filtering applies, but the simplicity of the tool makes this a minor gap. An output schema exists, but its details are not shown, so the description partially compensates.

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 tool has zero parameters, so the baseline is 4. The description doesn't need to add parameter information since none exist. The schema is empty and fully covers parameter requirements.

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 'Total entity count' clearly states the tool returns the count of all entities in the drawing. It is specific about the resource (entities) and the metric (count), though it lacks an explicit verb like 'get' or 'return'. It distinguishes from siblings like get_entity_counts by focusing on the overall total, but doesn't explicitly differentiate.

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?

No guidance is provided about when to use this tool versus alternatives such as get_entity_counts or entity_length. The description simply states what it returns and doesn't mention other tools or the context in which this is the preferred choice.

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