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

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds genuine value by disclosing that DM-only notes are included in the response, which is a meaningful data-exposure warning. It says nothing about behavior when the entity is missing or how large the payload can get, so this is useful but partial.

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?

A single front-loaded clause with zero filler, and the most decision-relevant detail (DM-only notes) is the one thing kept. It is a sentence fragment rather than structured prose, which limits how much it can front-load, but nothing is wasted.

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 three-parameter read with annotations covering the safety profile and no output schema, the description is close to sufficient. However, it leaves the two undocumented identifiers unexplained and gives no hint about lookup failure behavior or response size, which matters for a tool that returns an entire entity.

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 only 33%: entityType has an enumerated description in the schema, but campaignId and entityId are undocumented anywhere. The description adds no meaning to any parameter, not even clarifying that campaignId scopes the lookup or that the entity type must match the stored entity. With low coverage, the description should have compensated and does not.

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 the resource and scope precisely: it returns every field of a single entity, including DM-only notes. The 'one entity' framing implicitly separates it from list_entities, search_entities, and get_related_entities, though no sibling is named. An agent can tell what it does, just not explicitly what it is not.

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?

There is no guidance on when to choose this tool over list_entities, search_entities, or get_related_entities, and no note about required prior knowledge (a known entityId). The only implied usage signal is the singular 'one entity'.

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