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

The annotations already declare readOnlyHint=true and openWorldHint=true, so the safety and open-world profile is covered. The description adds genuine behavioral context about what comes back (summary, structured facts, 60-day trend data), which is useful since no output schema exists. It says nothing about rate limits, entity-not-found behavior, or data freshness, so it is solid but not rich.

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 opening sentence is duplicated verbatim and both copies are cut off with an ellipsis, so the text is both redundant and incomplete. The intended content is front-loaded reasonably, but the truncation and repetition make the definition feel broken rather than tight.

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?

There is no output schema and the input schema is a placeholder pointing at an external URL, so the description must carry the load. It partially compensates by naming the fact categories, but the truncation leaves the trend feature and the input contract undefined, which is inadequate for a tool with a nested-object parameter.

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 reported at 100%, which sets the baseline at 3, but the single 'input' object's schema text is only a pointer to the Apify listing URL rather than a real parameter description. The prose adds no parameter detail beyond that. Nested-object input with one prop and no enums means the description should ideally explain the input shape, and it 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 a specific verb and resource: 'Look up any company, person, product or topic across Wikipedia and Wikidata,' and enumerates the output shape (clean summary, structured facts such as founded, industry, HQ, key people, 60-day trends). That is enough for an agent to identify it without opening the schema, though it never distinguishes itself from adjacent enrichment tools like company_due_diligence or ai_company_enrichment.

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 when-to-use guidance, no prerequisites, and no named alternatives. The only hint is the permissive 'any company, person, product or topic,' which is scope, not selection guidance. An agent cannot tell from this text when Wikipedia/Wikidata lookup is preferable to the sibling enrichment tools.

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