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

With no annotations provided, the description carries the full burden. It discloses the complete returned payload, the 20-per-page pagination, the 10-page cap, and all filtering dimensions, making the read-only nature and scope obvious. It does not cover error handling or rate limits, but those are secondary for a retrieval tool.

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?

Three dense sentences: first states purpose and return contents, second lists per-review fields, third covers filters and pagination. All information is front-loaded and no word 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?

The tool has 10 parameters and no output schema, so the description must substitute for the missing return-structure documentation. It does so by explicitly listing profile fields (TrustScore, star rating, review counts, per-star breakdown, categories, claimed/verification status, reply behaviour, contact details) and per-review fields (rating, title, text, dates, verification level, likes, author info, company reply). Pagination, filters, and sort/sentiment options are also addressed, leaving an agent with enough detail to invoke the tool correctly.

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 100%, so the baseline is 3. The description adds the important operational detail that each page returns up to 20 reviews and that one call can span up to 10 pages, which is not present in the schema's '1-10' range. Filter names in prose map cleanly onto the schema properties.

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 a specific verb ('Get') and resource ('a company's Trustpilot reviews plus its full profile'), then enumerates the returned fields (TrustScore, star rating, review counts, per-star breakdown, etc.). This clearly separates it from sibling search_* and category tools that find companies or categories rather than fetch a specific company's reviews.

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 gives clear context: provide a company domain to retrieve that specific company's reviews and profile. It does not explicitly name alternatives or exclusion conditions (e.g., use search_trustpilot_companies first to find the domain), so it stops short of a full when/when-not statement.

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