verify_place

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

With no annotations provided, the description carries the full burden of behavioral disclosure and does so well. It discloses that the return value is a 'verdict/recommend' rather than raw data, warns against trusting 'open_closed' alone, and explicitly notes the cost of 1 credit. This goes beyond the schema and gives the agent important operational context.

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 description is two sentences with no filler. The first sentence states the core purpose; the second adds return behavior, a critical reliability warning, and cost information. Every sentence earns its place, and the description is front-loaded with the primary action.

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 an output schema, so the description need not detail return values; it appropriately mentions 'verdict/recommend' as a preview. It covers cost and the reliability caveat. It does not mention prerequisites like credit checking or typical failure modes, but given the output schema and simple 2-parameter input, this is not a significant gap.

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 0%, so the description must compensate. It indirectly references the parameters ('named place' and 'address') but does not define their format, constraints, or examples. The parameter names themselves are self-explanatory, and the description ties them to the tool's purpose, providing minimal added meaning. A score of 3 reflects that it is adequate but not rich.

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 clearly states a specific verb ('verify') and resource ('a named place at an address'), and defines the scope as checking existence and operating status. This distinguishes it from siblings like call_place or get_call, though not explicitly from verify_places.

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 provides clear context on when to use this tool: whenever one needs a trusted verdict on a place's operating status, since 'never trust raw open_closed alone.' It also mentions a cost (1 credit), implying the agent should consider resource usage. It does not explicitly exclude alternatives or list when-not-to-use scenarios, so it falls short of a 5.

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