美食神仙籤筒：今天吃什麼？依神明、餐別、美食種類與預算抽籤，回傳原創籤詩、料理；提供臺灣座標時，另從附近營業中的店家抽一間（附 Google 地圖與 Uber Eats 連結）。
| Name | Required | Description | Default |
|---|---|---|---|
| lat | No | ||
| lon | No | ||
| meal | No | ||
| deity | No | 神明 id 或名稱：mazu(媽祖)、guangong(關聖帝君)、tudigong(福德正神)、yuelao(月下老人)、wenchang(文昌帝君)、guanyin(觀世音菩薩)、baosheng(保生大帝)、xuantian(玄天上帝)、chenghuang(城隍爺)、caishen(財神爺) | |
| budget | No | 總預算（新臺幣） | |
| people | No | ||
| radius | No | 公尺，預設 1500，最大 5000 | |
| category | No | 美食種類 id 或名稱，auto＝神明決定 |
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 behavioral burden. It does disclose meaningful output behavior: an original fortune poem plus a dish, and a conditional branch where Taiwan coordinates trigger a nearby-open-restaurant pick with Google Maps and Uber Eats links. However, it says nothing about the no-coordinates case, what happens when no open restaurants exist, or whether the draw is randomized/read-only.
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 dense sentence that front-loads the core purpose ('美食神仙籤筒：今天吃什麼？') before the mechanics and the conditional behavior. Nearly every clause earns its place, though the length makes it slightly clausal-heavy.
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 8 parameters, no annotations, and no output schema, the description carries a lot of weight. It covers purpose, draw inputs, return values, and the coordinate branch reasonably well, but leaves the 'people' parameter and the behavior when coordinates are absent unspecified.
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 coverage is 50%, so the description must compensate. It meaningfully explains that deity/meal/category/budget drive the draw and that coordinates (lat/lon) switch on the restaurant lookup, which adds value over the raw schema. But the 'people' parameter is unexplained in both schema and description, leaving a gap.
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 (抽籤/draw a fortune) and resource (what to eat today), plus the inputs it draws from (deity, meal, category, budget) and what it returns (original fortune poem, dish). The tool's divination nature makes it inherently distinguishable from its siblings, but the description never explicitly names or contrasts them.
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?
Describes what the tool does but gives no guidance on when to prefer it over find_nearby_restaurants, list_deities, or list_food_categories, nor any when-not conditions. Usage is only implied by the playful framing, not stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.