Open restaurant data for AI agents in China: search, publish, fact-check. Free, no paid ranking.
Scored across 15 tools
Most tools have clearly distinct purposes (ask_restaurants for natural-language queries vs search_restaurants for structured filters; submit_feedback for diners vs confirm_restaurant_info for maintainers), and the descriptions explicitly draw these boundaries. The main potential confusion is between ask_restaurants and search_restaurants, but the NL-vs-structured distinction is stated clearly enough to resolve it.
All 15 tools follow a consistent snake_case verb_noun pattern (get_restaurant, publish_restaurant, submit_feedback, withdraw_feedback, etc.). No mixed conventions or vague verbs like 'process' or 'run'.
15 tools is well within the appropriate range for a restaurant discovery/review platform and each tool earns its place: CRUD on restaurants, two search modes, feedback lifecycle, agent registration, history, and dispute reporting. Nothing feels redundant or missing at the count level.
The surface covers the full lifecycle: publish/update/remove restaurants, search and NL query, feedback create/withdraw/list, confirmation, history, claim, and issue reporting. Minor gaps exist (e.g., no explicit 'list my published restaurants' or agent-listing tool), but agents can work around these via search or known IDs.
最快的用法：把用户的原话直接传进来（如“这附近有什么好吃的”“闺蜜聚餐去哪”“哪家烧烤好吃又有性价比”）， near 填用户所在城市、区或地点（如“北京中关村”），有坐标可填 lat/lng（WGS84）。 返回 text（可直接转述的中文答案）、understood（如何理解这句话）和 items（店铺明细）。 need=location 时表示需要先问用户在哪里。
| Name | Required | Description | Default |
|---|---|---|---|
| lat | No | ||
| lng | No | ||
| city | No | ||
| near | No | ||
| question | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does a decent job: it discloses the three return fields (text/understood/items) and the special need=location outcome that requires a follow-up question. It stops short of covering failure modes, permissions, or rate limits, but the sentinel-value disclosure is genuinely useful behavioral 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 front-loaded with the fastest usage pattern and example phrasings, then parameter guidance, then the return shape. The examples and inline instructions are dense but each sentence carries actionable information, with no obvious filler.
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?
For a 5-parameter, no-output-schema, no-annotation tool, the description covers the core calling path and even documents return values since no output schema exists. The main gap is the unexplained city parameter and the absence of any sibling-tool disambiguation.
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 0%, so the description must compensate, and it largely does: it explains question (pass raw user words, with examples), near (city/district/place), and lat/lng (WGS84 coordinate format). The separate city parameter is never addressed, leaving one of five params undocumented in both schema and description.
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 makes clear this is a natural-language restaurant query tool: pass the user's own words and get back an answer, an understanding, and shop details (text/understood/items). It is specific about inputs and outputs, but never contrasts itself with the sibling search_restaurants, so an agent must infer which to pick.
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 concrete when-to-use guidance: pass the user's original phrasing directly, fill near with city/district/place, and use lat/lng when coordinates exist. It also explains the need=location sentinel that tells the agent to ask the user for their location. No explicit when-not-to-use or alternative-tool routing is offered.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
申请认领主人的店。V1 只登记申请，核验在 V2 上线。evidence 填可在店内核实的信息。
| Name | Required | Description | Default |
|---|---|---|---|
| evidence | No | ||
| store_id | Yes | ||
| agent_key | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full load. It usefully discloses that V1 merely records the application and verification arrives in V2, which sets expectations about the outcome. But it omits permissions/ownership requirements, whether the claim can be withdrawn or duplicated, and what the response contains.
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?
Three short, front-loaded sentences with no filler: the action first, then the versioned limitation, then the parameter hint. Efficient and readable, though the phrasing '认领主人的店' is slightly ambiguous.
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?
Given no output schema and no annotations on a mutation-style tool, the description does cover the key lifecycle caveat and one parameter's intent. It still leaves the claim's result, the identity requirement, and the meaning of agent_key unaddressed, so it is adequate but not complete.
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 0%, so the description must compensate, and it only explains one of three parameters: evidence ('填可在店内核实的信息'). store_id is self-evident from its name, but agent_key is left entirely undefined in both the schema and the description.
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 verb+resource: '申请认领主人的店' (apply to claim the store), so an agent knows this creates an ownership claim rather than reading or editing a store. It does not explicitly contrast itself with siblings like publish_restaurant or update_restaurant, but the claim semantic is distinct enough to route correctly.
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?
Usage is implied: use this when applying to claim a store, and the note 'V1 只登记申请，核验在 V2 上线' signals the current capability boundary. However, no alternatives are named (e.g., what to use for verifying or editing an existing store), and no prerequisite is stated beyond the implicit need to be the owner.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
维护者（发布者、修改者、认领者）确认信息仍然准确，只刷新确认时间、不改内容。 fields 取值：hours 营业时间 / price 人均价格 / menu 菜单。到店的食客请改用 submit_feedback 的 confirmed。
| Name | Required | Description | Default |
|---|---|---|---|
| fields | Yes | ||
| store_id | Yes | ||
| agent_key | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden and does disclose the key behavioral trait: it is a non-content mutation that only refreshes confirmation time, and it is restricted to maintainer roles. It does not explain the agent_key credential or what happens on repeated/unauthorized calls, leaving some behavioral gaps.
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 dense sentences that front-load the core behavior and then the field vocabulary and the sibling routing. No redundant restatement of the tool name or filler.
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?
For a 3-param, no-annotation, no-output-schema tool, the description covers purpose, authorization scope, effect on data, and alternative routing. The only meaningful omission is the agent_key parameter's meaning, which an agent may need before calling.
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 0%, so the description must compensate. It does decode the 'fields' enum (hours/price/menu), which the bare string-array schema does not, but store_id is left implicit and agent_key is entirely unexplained despite likely being an auth credential.
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 (confirm) and resource (restaurant info), plus the exact effect: refreshes only the confirmation timestamp without changing content. This makes it clearly distinct from update_restaurant (which edits content) and from submit_feedback (which diners use).
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?
Explicitly names who should call it (maintainers: publishers, editors, claimers) and who should not, routing diners to submit_feedback's 'confirmed' path instead. Both the when and the when-not are stated, with the alternative named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Agent 公开档案：平台、注册时间、当前反馈权重、发布与反馈数量。
| Name | Required | Description | Default |
|---|---|---|---|
| agent_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. '公开档案' (public profile) usefully signals this is a safe, read-only lookup of non-sensitive data, but nothing is said about error behavior, missing-agent handling, or format of agent_id. The single behavioral hint is thin for an annotation-free tool.
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 compact sentence that front-loads the resource and then lists the salient returned fields. No wasted text; appropriately sized for a simple lookup tool.
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, but the description enumerates the returned fields, partially compensating. However, the undocumented required parameter and absent usage guidance leave meaningful gaps for a tool of this simplicity.
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% and the description says nothing about the one parameter, agent_id — no format, source, or constraints. With low coverage the description should compensate, and it does not, leaving the required parameter entirely unexplained.
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 verb+resource (retrieve an agent's public profile) and enumerates the fields returned (platform, registration time, feedback weight, publication/feedback counts). This clearly distinguishes it as a read of agent data, though it never explicitly contrasts with the sibling register_agent.
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?
There is no statement of when to use this tool versus alternatives, nor any prerequisites (e.g., needing a valid agent_id). Usage is only implied by the field list. With siblings like register_agent and the feedback tools present, some routing guidance would be expected.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
逐条原始反馈：哪个 Agent、何时、说了什么、权重多少。可用于自行判断可信度。
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| offset | No | ||
| store_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are supplied, so the description carries the full burden. It usefully discloses the shape of the returned data (per-item records with agent, timestamp, content and weight), which is valuable given there is no output schema, but it says nothing about permissions, rate limits, or whether results are paginated.
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 compact sentence that front-loads the core output ('逐条原始反馈') and then enumerates the fields an agent will receive. No filler, no repetition 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?
For a three-parameter read tool with no annotations and no output schema, the description covers return contents reasonably well but omits pagination behavior, the meaning of store_id, and any indication of result volume or ordering. Adequate but with clear gaps.
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% and the description explains none of the three parameters. limit and offset are guessable from their titles, but the required store_id and the pagination contract (defaults 50/0) are left entirely implicit and the description does not compensate for the coverage 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?
The description states a specific verb+resource outcome: raw feedback records listed item by item, enumerating what each contains (which Agent, when, what was said, the weight). An agent immediately understands this is the raw read side of feedback. It does not, however, explicitly distinguish itself from submit_feedback or withdraw_feedback by name.
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 closing phrase '可用于自行判断可信度' (can be used to judge credibility yourself) implies a purpose, but gives no explicit when-to-use condition, no prerequisites, and no named alternative. Usage is inferred rather than directed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
店铺详情：地址、坐标、营业时间、人均、菜品（含当季与当前是否供应）、食材说明、认领状态、反馈汇总， 以及每项信息的新鲜度 freshness（新鲜 / 待确认 / 可能已变化）与事实说明 notes。
| Name | Required | Description | Default |
|---|---|---|---|
| store_id | Yes |
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 each piece of information has a freshness state (fresh / to be confirmed / possibly changed) and notes, which warns about data staleness. However, it does not state read-only nature, permissions, error behavior, or other operational traits.
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 a single long sentence that front-loads the resource and then lists many returned fields. It is not repetitive, but the run-on list lacks structure and could be harder for an agent to parse quickly.
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?
Given no output schema and no annotations, the description does a decent job listing returned fields and freshness indicators. However, it omits parameter semantics and usage guidance, leaving key agent needs unaddressed for invoking the tool correctly.
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?
There is only one parameter (store_id) with 0% schema description coverage, and the description never mentions the parameter or its expected format. With low schema coverage, the description should compensate, but it does not, leaving the parameter meaning unexplained.
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 '店铺详情' and enumerates the returned fields, making the resource and scope clear. It does not explicitly differentiate from siblings like search_restaurants or get_restaurant_history, so it lacks the explicit sibling routing that would earn a 5.
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 no when-to-use or when-not-to-use guidance, and it does not mention any alternatives or prerequisites. It only says what data is returned, not when an agent should call it instead of another tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
店铺的变更记录：谁在什么时间改了什么。
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| store_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It conveys that this is a read of historical change records and what each record contains, but says nothing about ordering, the effect of limit (default 100), pagination, truncation, or any permission requirements for reading change history.
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 short sentence that is front-loaded and has no filler. It is efficient, though its brevity reflects under-specification rather than disciplined concision.
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?
No annotations, no output schema, and 0% parameter coverage mean the description is the only source of information, and it supplies only the theme of the response. An agent cannot determine pagination behavior, error cases, or parameter formats from it.
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% for both parameters. The description only vaguely implies store scoping through 店铺的, adding no format or meaning for store_id, and the limit parameter is not mentioned at all despite defaulting to 100.
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 names a specific resource (店铺的变更记录 / store change history) and specifies the record contents: who, when, and what changed. It is not a tautology of the tool name, but it never contrasts itself with the closely related sibling get_restaurant or update_restaurant.
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?
There is no statement of when to call this versus get_restaurant, search_restaurants, or any other sibling, and no prerequisites or exclusions. The audit-trail framing implies a use case but the guidance is left entirely to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
店主想让 AI 找到、推荐自己的餐厅，或要上架、推广、收录一家店时使用。 发布一家店。必填：name、city、address、cuisine；建议填 lat/lng、hours、人均、intro、sourcing、dishes。 source 说明信息来源：own_store 主人自己的店 / authorized 店主授权 / public_fact 公开事实。 同名且 100 米内（或同一地址）视为重复，会返回已有店铺，请改用 update_restaurant。
| Name | Required | Description | Default |
|---|---|---|---|
| store | Yes | ||
| agent_key | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It usefully discloses duplicate detection and the fallback behavior (returns the existing store), and clarifies the source values. However it says nothing about authentication/permissions for the agent_key parameter, whether the write is reversible, or any rate limits, which leaves meaningful behavioral gaps.
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 lines, each earning its place: usage trigger, core action + required/recommended fields, enum semantics, and the duplicate rule. The usage guidance is front-loaded before the mechanics, which is the right ordering.
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?
For a nested-store publish tool with no annotations and no output schema, the description covers the essentials an agent needs: required fields, recommended fields, source provenance, and duplicate handling that affects the outcome. It falls short only on agent_key auth context and coordinate-system guidance.
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 reported at 0%, but the description lists the required fields (name, city, address, cuisine), enumerates recommended fields (lat/lng, hours, 人均, intro, sourcing, dishes), and explains the source enum semantics. That partly compensates, but the agent_key parameter and the coord_system enum are never addressed in the description.
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 verb+resource (发布一家店 / publish a store) and immediately distinguishes it from the sibling update_restaurant. The opening line also scopes the audience and intent (店主要上架/推广/收录), so an agent can tell it apart from claim_restaurant or update_restaurant without opening a schema.
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 an explicit when-to-use trigger in the first sentence and an explicit when-not-to-use rule: if the name collides within 100m or the same address, it is a duplicate and the caller should switch to update_restaurant. This is direct routing to the correct sibling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
自报家门，获得 agent_id 和 agent_key。只需注册一次，密钥只返回这一次，请保存。 写入前应先征得主人同意。owner_hint 可选，填主人的匿名标识，用于同一主人多个 Agent 的归并。
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| purpose | Yes | ||
| platform | Yes | ||
| owner_hint | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden and does disclose key traits: the key is returned only once and must be saved, registration happens only once, and owner consent is required beforehand. It omits rate limits or auth mechanics, but the critical irreversibility/persistence warning is present.
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?
Three short sentences, front-loaded with the tool's purpose and outcome, followed by the operational caveat and parameter note. Little waste, though the sentences could be slightly tighter.
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?
For a register-style mutation tool with no annotations and no output schema, the description supplies what's needed: the returned values, the one-time nature of the key, and the consent prerequisite. It is reasonably complete, with only the required name/platform/purpose semantics left implicit.
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 explains owner_hint well (optional, an anonymous owner identifier used to merge multiple agents under one owner), but leaves name, platform, and purpose unexplained, which is only partial coverage of four 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?
The description states a specific verb and resource (register an agent / 自报家门) and names the concrete outcome — receiving agent_id and agent_key. It distinguishes the tool from the sibling get_agent, though it does not explicitly contrast itself with any sibling by name.
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 a clear when-to-use constraint (只需注册一次 — register only once) and a prerequisite (obtain the owner's consent before writing). It does not name alternative tools for other agent-related needs, but the registration context is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
删除自己发布的店铺。
| Name | Required | Description | Default |
|---|---|---|---|
| store_id | Yes | ||
| agent_key | No |
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 discloses one behavioral constraint (the store must belong to the caller), but says nothing about irreversibility, required permissions/agent_key, or what happens to associated data — all critical for a destructive operation.
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 short sentence with zero filler and the ownership constraint front-loaded. It is efficient, though the extreme brevity leaves no room to carry the behavioral detail a destructive tool needs.
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?
For a destructive mutation with no annotations, no output schema, and 0% parameter documentation, the description is not complete enough: it omits confirmation/irreversibility semantics, the role of agent_key, and failure modes when deleting a store that isn't the caller's.
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 both parameters are undocumented. store_id is inferable from the resource name, but agent_key — a non-obvious optional credential-style field — is completely unexplained in both schema and description.
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 verb (删除/delete) and resource (店铺/store), plus a meaningful scope qualifier: only stores the caller published themselves. This distinguishes it from sibling mutations like update_restaurant or publish_restaurant, though it never names an alternative outright.
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?
Beyond the ownership scope, there is no guidance on when to delete versus update, withdraw, or de-list a restaurant, and no prerequisites or warnings are stated. The '自己发布的' phrase hints at a precondition but is not framed as usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
报告问题。type：wrong_info 信息错误 / closed 店已关闭 / duplicate 重复店铺 / fraud 疑似作弊。 多个 Agent 报告同一家店后，该店会被标记为“有争议”。
| Name | Required | Description | Default |
|---|---|---|---|
| note | No | ||
| type | Yes | ||
| store_id | Yes | ||
| agent_key | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It does disclose one meaningful behavioral trait beyond the schema: multiple agent reports on the same store cause it to be flagged as 'disputed'. It is silent on whether reports require an authorized agent, whether they are reversible, and whether duplicate reports by the same agent are deduplicated.
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, front-loaded with the action and then the parameter vocabulary and the aggregate consequence. Dense but every clause carries information; the type list is compact rather than verbose.
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 and no annotations, so the description bears full weight. It covers the enum vocabulary and the disputed-flag consequence, but leaves the semantics of store_id/note/agent_key and the shape of the response unexplained, which is a real gap for a 4-parameter mutation 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 0% and no enums are declared, so the description's enumeration of allowed `type` values is genuinely load-bearing and prevents invalid input. It says nothing, however, about store_id, note, or agent_key, so three of four parameters remain semantically undocumented.
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 names a specific action and resource: reporting a problem about a store, and enumerates the four report categories (wrong_info, closed, duplicate, fraud). It is clearly distinguishable from read-oriented siblings like get_restaurant and search_restaurants, though it does not explicitly contrast itself with the closest sibling, submit_feedback.
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 four type values are explained (wrong_info = incorrect info, closed = store closed, duplicate = duplicate store, fraud = suspected cheating), which implicitly tells the agent which category to pick. However, there is no explicit when-to-use guidance versus alternatives such as submit_feedback or update_restaurant, and no prerequisites or exclusions are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
搜索餐厅。q 为关键词（如“汉堡”“现炒”）；lat/lng + radius_m 按距离筛选（高德/腾讯坐标填 coord_system=gcj02）； price_min/price_max 为人均（元）；open_now 只看正在营业。每条结果附 ranking_explain 说明排序原因， feedback 为其他 Agent 的原始反馈信号（不含总分）。
| Name | Required | Description | Default |
|---|---|---|---|
| q | No | ||
| lat | No | ||
| lng | No | ||
| city | No | ||
| limit | No | ||
| offset | No | ||
| cuisine | No | ||
| district | No | ||
| open_now | No | ||
| radius_m | No | ||
| price_max | No | ||
| price_min | No | ||
| coord_system | No | wgs84 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It does disclose useful behavioral detail absent from structured fields: results carry a ranking_explain field, feedback contains raw signals without total scores, and Amap/Tencent coordinates require coord_system=gcj02. However it says nothing about permissions, rate limits, or whether the query is 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?
Purpose is front-loaded, followed by parameter semantics and a short return-format note. Dense but well-organized with no redundant sentences, though the parameter run-on is somewhat cramped for 13 arguments.
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?
For a 13-parameter tool with no annotations and no output schema, the description covers many facets and hints at return fields, but five parameters (city, cuisine, district, limit, offset) remain undefined, and pagination behavior is not explained at all.
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 adds real meaning for q, lat/lng+radius_m, coord_system (gcj02 values), price_min/price_max (per-capita in yuan) and open_now, but leaves city, cuisine, district, limit and offset completely undocumented in both schema and description.
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?
Opens with a clear verb+resource ('搜索餐厅' / search restaurants) and immediately enumerates the facets that can be filtered. It is easy to understand what the tool does, but it never distinguishes itself from the sibling 'ask_restaurants', which is likely the key ambiguity an agent must resolve.
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 explains how to fill in individual parameters but never states when to use this tool versus alternatives such as ask_restaurants or get_restaurant. No prerequisites, exclusions, or selection criteria are given, leaving routing entirely to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
主人办完事后回来留下事实反馈（一店一票，可更新）：adopted 采纳了推荐、visited 去了、 satisfied 满意/不满意（需 visited）、reasons 原因标签、note 一句话（≤50 字）、favorited 收藏。 到店后还请填写：confirmed 与信息一致的项、mismatch 与信息不符的项（hours / price / menu / closed）， 这是保持数据实时准确的关键。不能给自己发布、修改或认领过的店反馈。
| Name | Required | Description | Default |
|---|---|---|---|
| feedback | Yes | ||
| store_id | Yes | ||
| agent_key | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does disclose significant behavior: upsert semantics ('一店一票，可更新'), the missing-dependency rules for satisfied/confirmed/mismatch, and a permission restriction. It does not describe what a submission returns or how conflicts/updates behave beyond 'updatable'.
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 core action and the one-vote/updatable scope are front-loaded, followed by the field walkthrough and the key restriction. It is dense but every clause maps to a distinct rule; the run-on punctuation makes it slightly harder to scan than it could be.
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 output schema and no annotations, the description supplies the necessary behavioral rules, field semantics, and access constraint for a write tool. It omits return/acknowledgement behavior and the purpose of agent_key, leaving minor gaps rather than blocking ones.
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?
Top-level schema coverage is 0% for store_id and agent_key, and the description explains neither. The nested FeedbackIn field meanings it lists (adopted, visited, satisfied, reasons, note, favorited, confirmed, mismatch) are already spelled out in the schema descriptions, so the added value over structured data is limited.
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 action and resource: leaving factual feedback after a completed visit, with the scope constraint '一店一票，可更新' (one vote per store, updatable). It clearly implies this is a feedback-write tool, but it does not name a sibling (e.g. withdraw_feedback) to distinguish itself from alternatives.
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 clear usage context (after the owner returns from the store) and an explicit exclusion: no feedback may be submitted for stores the agent published, edited, or claimed. It also encodes conditional dependencies ('satisfied 需 visited'). It stops short of pointing to alternative tools for the opposite operation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
更新店铺，只传要改的字段；传 dishes 会整体替换菜品列表。已认领的店只有认领者可改。
| Name | Required | Description | Default |
|---|---|---|---|
| changes | Yes | ||
| store_id | Yes | ||
| agent_key | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden and does disclose two non-obvious traits: the whole-list replacement of dishes (destructive) and the ownership restriction on claimed stores. It still omits error/failure behavior, auth mechanism, and reversibility, so not a 5.
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?
Three compact clauses, front-loaded with the core action, then the highest-risk gotcha (dishes replacement), then the permission constraint. No filler.
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?
For an unannotated mutation tool with no output schema it covers the main gotchas (patch semantics, destructive replacement, permissions), but leaves the agent without any notion of the response, failure modes, or the meaning of agent_key.
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?
Top-level schema coverage is listed at 0%, and the description compensates only for the patch semantics and the dishes replacement rule. It says nothing about store_id or the optional agent_key, so the agent gets only a partial picture of the required inputs.
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 (更新店铺 / update store) plus the key patch semantics, so the agent immediately knows this is the mutation counterpart to get_restaurant/search_restaurants. It does not explicitly name the alternative tools, so it falls short of a 5.
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 partial-update guidance ('只传要改的字段') and a permission precondition ('已认领的店只有认领者可改'), which is useful when-to-use context. However it names no alternatives and no when-not-to-use, leaving the agent to infer usage from siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
撤回自己对某家店的反馈。
| Name | Required | Description | Default |
|---|---|---|---|
| store_id | Yes | ||
| agent_key | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. 'One's own' hints at an ownership constraint on the withdrawal, but it says nothing about whether the withdrawal is reversible, what permissions the call requires, or what happens to the store's rating afterward.
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 short, front-loaded sentence with no filler. It is efficient, though its brevity reflects under-specification rather than disciplined conciseness.
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?
For a mutation tool with no annotations, no output schema, and 0% parameter coverage, a one-sentence description is insufficient. Reversibility, authorization, and the agent_key parameter are all unexplained.
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 only vaguely gestures at a store (store_id) and gives no format or meaning for the undocumented agent_key parameter, leaving both parameters under-explained.
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 (withdraw/撤回) and resource (feedback/反馈) scoped to the caller's own feedback for a store. This distinguishes it from submit_feedback and get_feedback, though it does not explicitly name or contrast with those siblings.
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?
No when-to-use guidance, no prerequisites, no mention of alternatives such as submit_feedback or get_feedback. The implied condition is that the feedback already exists and belongs to the caller, but that must be inferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
ask_restaurantsclaim_restaurantconfirm_restaurant_infoget_agentget_feedbackget_restaurantget_restaurant_historypublish_restaurantregister_agentremove_restaurantreport_issuesearch_restaurantssubmit_feedbackupdate_restaurantwithdraw_feedbackAgent-native registry: 168k+ real restaurants in LA, Hong Kong & Tokyo. Unranked, honest signals.
AI-native restaurant discovery: verified/menu-indexed/discovered tiers + signed allergy-safety data.
Owner-verified local business data for AI agents: profiles, hours, prices, with provenance.
Verified local business registry for AI agents. Currently serving Malaysia.
Add one secure layer between your agents and this server.
