lemma_list_entities

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

With no annotations provided, the description carries the behavioral disclosure burden. It discloses that results are scoped to API-key access and may contain multiple entities, which is useful context. It does not describe pagination or the return envelope, but the schema's limit/cursor parameters partially cover that.

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 dense sentences with no filler. The core action and scope are front-loaded, and the second sentence adds high-value usage context about entity discovery and the possibility of multiple entities.

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?

Given no output schema, the description provides enough context: it names the resource, the access scope, and the fact that IDs collected here feed other tools. It could mention response fields or pagination explicitly, but the schema already documents cursor/limit mechanics and the tool is simple.

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 the baseline is 3; npi, limit, and cursor are all fully documented in the schema. The description adds no parameter-specific details beyond the top-level scope context.

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 the verb 'List' and resource 'legal entities this platform API key has been granted access to', clearly identifying a read-only collection operation. The 'top-level scope' framing distinguishes it from entity-specific sibling tools, though it does not explicitly name an alternative.

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?

Explains when to call it: as the entry point for discovering the entity/account IDs that most other tools require. It gives clear usage context and warns against assuming a single entity, though it does not name exclusions or specific alternative tools.

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