Find nearby restaurants and dishes that fit a calorie quota, using location and optional cuisine or radius filters.
额度内能吃什么（跨数据源）。当用户问"我现在能点什么""有什么便宜（低卡）的"时使用。
用户给业态限定时填 industry；用户说"还有吗"时用 nearby_food 的 page 参数。
| Name | Required | Description | Default |
|---|---|---|---|
| quota | No | 本餐额度（卡） | |
| industry | No | 业态限定，同 nearby_food。不填=不限。 | |
| latitude | No | 用户所在纬度，配 longitude 一起传。 | |
| radius_m | No | 搜索半径（米），默认 1500 | |
| longitude | No | 用户所在经度。**传了才能走麦当劳实时** —— 麦当劳 MCP 只吃文字地名，需要用它把坐标翻译成 city+keyword；不传就只能用本地快照。 |
Changes observed during successful MCP inspections.
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 does disclose the cross-datasource aggregation behavior and, indirectly, that coordinate-free calls degrade to a local snapshot — but it says nothing about return shape, ranking, staleness, or failure modes when quota is omitted.
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?
Front-loaded purpose sentence followed by two compact routing sentences; every clause maps to a decision the agent must make. No filler or restatement of the tool name.
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?
All five parameters are optional and there is no output schema, so return values need not be explained. However, the description never states what happens when quota is omitted or how results are ordered, which matters for a cross-source aggregation tool with zero required inputs.
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 baseline is 3, but the description adds conditional semantics the schema lacks: fill industry only when the user constrains the business type, and the pagination follow-up belongs to nearby_food, not this tool's own parameters.
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+resource with scope: what can be eaten within the calorie quota, aggregated across data sources. The parenthetical '(跨数据源)' distinguishes it from a single-source lookup like nearby_food, though the distinction is brief rather than fully drawn.
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?
Explicit trigger phrases ('我现在能点什么', '有什么便宜（低卡）的'), an explicit conditional for filling industry when the user names a business type, and an explicit routing rule to use nearby_food's page parameter on follow-up ('还有吗'). This is close to ideal when/when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.