Reviews

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

No annotations are provided, so the description carries the full burden, yet it only implies a read via 'Get'. It says nothing about pagination being cursor-driven, rate limits, auth requirements, or what the response contains, leaving behavior largely unexplained.

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 short sentence with no filler, and the purpose is front-loaded. It is efficient, though the extreme brevity leaves the definition thin rather than genuinely 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?

With six parameters, no required fields, no annotations, and no output schema, the description does too little: it never explains which of the two lookup parameters to prefer, that results are paginated via end_cursor/hasNextPage, or what a review record looks like.

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. The phrase 'by url or id' corresponds to business_url/business_id but adds no syntax or format detail beyond what the schema already documents.

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 ('reviews') scoped to a business, and clarifies the two addressing modes ('by url or id'). It is clearly distinguishable from siblings like business_details or get_menus_beta, though it never names them explicitly.

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 only usage hint is 'by url or id', which maps loosely to the two addressing parameters. There is no statement of when to use this over business_details or get_menus_beta, and no prerequisites or exclusions are given.

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