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

No annotations are provided, so the description carries the full burden. It usefully discloses that the wake word (兔兔生活/tutulife) is auto-detected and should be left in the input, but says nothing about whether this is a read-only query, what form the answer takes, latency, or whether the optional location params are honored.

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?

Two short sentences, bilingual by design, with the key instruction (use first, pass verbatim) front-loaded. Slightly redundant across the Chinese/English versions but efficient overall.

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 no annotations and no output schema, the description should explain what the agent gets back (a spoken answer? a suggestion list?) and when location params are needed. It covers routing and input handling but leaves the return behavior and optional-parameter semantics unaddressed, which is a meaningful gap for a 5-param NL tool.

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 80% (lat, lng, near, question all documented), so the schema already does most of the work. The description adds one genuinely non-obvious point for the required 'question' param — pass verbatim and keep the wake word in — but says nothing about lat/lng/city/near or how they interact with the question text.

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 capability: answering natural-language 'what/where to eat' questions by passing the user's words verbatim, with wake-word auto-detection. It is clearly distinguishable from CRUD siblings like get_restaurant, though it never names search_restaurants, the closest alternative, so sibling differentiation is only implied via 'use first'.

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?

It gives explicit precedence guidance ('首选' / 'Use first for any where to eat question'), which tells the agent to route here before other tools. It stops short of stating when NOT to use it or naming the fallback sibling (e.g. search_restaurants, tell_us_your_need).

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