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

Annotations declare readOnlyHint=false, idempotentHint=true, destructiveHint=false and openWorldHint=false, and the description never explains why a 'lookup' is not read-only — the 'started' phrasing suggests it enqueues a job, but this is left for the agent to infer. Positively, it discloses the cost profile ('costs nothing') and the data prerequisite, which the annotations do not.

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?

Four short sentences, front-loaded with the outcome the agent gets. Nothing is padded, though the final sentence about 'started' is terse enough to be confusing rather than efficient.

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, so the description bears responsibility for hinting at return shape. It gestures at a 'started' state but never says what a completed answer looks like or how long to wait before the follow-up call, leaving notable gaps for a tool with an async path.

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?

The tool takes zero parameters, so there is no schema semantics to add; the baseline applies. The description still contributes meaningful context by stating that results depend on the business having at least one place registered, which is a precondition no parameter encodes.

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 and resource: look up real searches people type for the business and its places. That is concrete and distinct from generic siblings like activity or places, but the relationship to searches_people_make is only hinted at, so the boundary between the two is not fully clear.

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?

Gives a real prerequisite ('needs at least one place listed') and a follow-up instruction ('if the answer says started, call searches_people_make shortly after'), which implies an async start-then-poll flow. However, it never explains why this tool is preferred over searches_people_make, or whether that sibling could be called first, so the routing guidance stays implicit.

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