Free self-check list first, or pay a real person in China to go look and report what they saw.
Scored across 5 tools
Each tool targets a clearly distinct action: creating an ask vs. verifying a place (explicitly contrasted in the descriptions), two separate status readers keyed to different IDs, and one free informational tool. The ask-vs-verify distinction is spelled out in detail, leaving little room for misselection.
Two status tools follow a clean get_<noun> pattern, but the others mix conventions: verb_phrase (ask_someone_there), verb_noun (verify_place), and a full question sentence (what_can_i_check_myself). Readable and loosely grouped, but not a single predictable scheme.
Five tools neatly cover the two paid flows (create + check) plus the free pre-check, with nothing redundant or missing at the count level. Well-scoped for the service's purpose.
Both paid lifecycles have create-read coverage and the free path is present, so core workflows are complete. However, there is no way to cancel/refund an order, list past orders, or query the account balance that both paid tools charge against.
Pay one real person who happens to be nearby to walk over and answer a question about right now, on the spot. A few yuan, a few hours. Good for: is this shop open right now, does this charger work, how busy is that street today, is the item still on the shelf — things you cannot search for, that only someone standing there this minute knows. Cheaper and faster than verify_place, but one person and no report. 让一个正好在附近的真人去看一眼，回答一个当下、现场的问题，几块钱、几小时内。适合：这家店现在开着吗、这个充电桩能不能用、这条街今天什么样、货架上还有没有货——这类你搜不到、只有此刻站在那儿的人才知道的事。 跟 verify_place 的区别：这个是一个人、便宜、快，给的是一句现场描述；verify_place 是三个互不相识的人、几十块、出一份可以拿去给别人看的核实报告，适合"这家供应商到底存不存在"这种要留证据的场合。拿不准就用这个，便宜。下单会从账户余额扣款。
| Name | Required | Description | Default |
|---|---|---|---|
| city | No | 城市，例如「芜湖」。填了更容易找到附近的人 | |
| question | Yes | 你想知道什么，一句话。越具体越好——「金鹰对面那家兰州拉面现在还开着吗」比「那家店怎么样」有用得多 | |
| place_hint | Yes | 去哪儿看。地址、店名、路口都行，能让人找到就够 | |
| price_yuan | No | 愿意出多少钱（5–30 元），不填按 5 元。给得多，有人接的更快 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations, so the description carries the full burden, and it discloses real traits: it costs a few yuan, takes a few hours, draws from the account balance, returns a single on-site description, and involves only one person with no report. It omits edge cases such as what happens if nobody accepts or whether the charge is refunded.
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?
Each language version is well front-loaded, leading with the core value proposition before examples and the sibling comparison. The full bilingual duplication means the content appears twice, which is repetitive, but it appears deliberate for a Chinese-market audience.
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 does the needed work: it states the cost, timing, that only one person is involved, and that the result is a one-line on-site description rather than a report. Return format is characterized qualitatively, which is enough for an agent to set expectations.
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 the schema already documents all four parameters including the 5–30 yuan price range and the 'pay more, get accepted faster' dynamic. The description's '几块钱/a few yuan' only loosely echoes the schema and adds no new syntax or format detail, so baseline 3 applies.
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: pay one real nearby person to walk over and answer an on-the-spot question. It explicitly names and contrasts the sibling verify_place, so an agent can distinguish the two without opening either 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?
Gives concrete when-to-use examples (is the shop open, does the charger work, is the item on the shelf) and an explicit when-not: use verify_place when you need evidence from three strangers in a report. Ends with a tie-breaker ('when unsure, use this, it's cheap').
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check the status of one ask by ask_id. Until someone has actually gone and answered, answer is null — do not invent an answer in its place. Tell the user it is still waiting for a person. The entire point of this service is that nothing is made up.
按 ask_id 查一单到哪一步了。没人答之前 answer 是 null——这时候不要替他编一个答案，如实告诉用户还在等人。
| Name | Required | Description | Default |
|---|---|---|---|
| ask_id | Yes | 下单时返回的 ask_id |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden, and it does the most important part: it discloses that `answer` stays null until a real person responds and warns the agent not to fabricate one. That is a genuine, non-obvious behavioral trait a schema cannot express. It stops short of covering invalid ask_id errors or polling/caching behavior.
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 English block is front-loaded and tight: status check first, then the null-answer warning. The description is then mirrored in Chinese, which doubles the length, but the content is short overall and every clause in the English half is load-bearing.
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 must explain return semantics itself, and it does communicate the one critical state (answer null until answered). Error behavior for an unknown ask_id and whether the call is a pure safe read are left unstated, but for a one-parameter lookup this is close to sufficient.
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 a single parameter at 100% schema coverage; the schema already explains ask_id as '下单时返回的 ask_id'. The description only restates that lookup is by ask_id without adding format, constraints, or examples, so it sits at the baseline for fully documented params.
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 ('Check the status of one ask by ask_id'), so the agent knows exactly what it retrieves and by which key. It does not, however, differentiate itself from the sibling get_verification_result, which is also a status getter, leaving the agent to infer the distinction.
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 — call it after an ask has been placed to see whether anyone responded. There is no explicit when-not guidance and no naming of alternatives among the four siblings, so an agent choosing between get_ask_answer and get_verification_result gets no routing help.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check progress of one verification by the order_id you got when ordering. Once the report is ready, returns what each of the three people saw, separately — not a merged verdict. We do not tell you what to conclude. 按下单时拿到的 order_id 查这一单到哪一步了；已经出报告的话，返回三个人各自看到的内容。
| Name | Required | Description | Default |
|---|---|---|---|
| order_id | Yes | 下单时返回的 order_id |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does genuinely useful work: it discloses that the call can be made mid-flight ('check progress') and after completion, and critically that the return is three people's separate accounts rather than a merged verdict, with the explicit stance 'we do not tell you what to conclude.' Gaps remain around failure/not-ready behavior and the exact response shape.
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 compact, front-loaded sentences lead with the action and then the important return semantics; nothing is padded. The appended Chinese translation duplicates the English rather than adding information, but it is plausibly a deliberate bilingual convention rather than noise.
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 does describe what comes back (each of the three people's views, separately) and the ordering/prerequisite context. It stops short of covering not-ready/error states, polling cadence, or result format, which leaves a small but real gap for a result-fetching 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?
There is a single parameter with 100% schema coverage, so the baseline is 3. The description's phrase 'the order_id you got when ordering' mirrors the schema text rather than adding format, source-of-truth, or validation detail beyond it.
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 verb and resource — checking the progress/result of one verification via order_id — and clarifies the scope (one verification, three people's separate reports). It is clear on its own, but it never names or contrasts with the siblings (e.g. verify_place, get_ask_answer), so the agent must infer the routing from the resource word alone.
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 rather than stated: 'by the order_id you got when ordering' and the progress-vs-ready framing tell the agent this is the follow-up call after ordering a verification. There is no explicit when-to-use/when-not guidance and no reference to alternatives such as get_ask_answer, so the agent must infer the boundary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Send three strangers — people who have never met — to a physical address in China (factory, shop, or office) on different days, unannounced. Each photographs the storefront, asks one question inside, and writes down what they saw in their own words. You get all three accounts in one report. Use this when the question is "does this supplier actually exist / is it actually operating / does the sign match the address" — things only someone standing there can answer. Charges the account balance. 派三个互不相识的真人去中国境内的某个实际地点（工厂、门店、公司办公地）实地核实，拍门头照、进店问一句、各自独立写下判断，出一份报告。适合回答"这家供应商是不是真的存在/真的在营业/招牌和地址对不对得上"这类只有到过现场的人才知道的问题。下单会从账户余额扣款。
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | 对方的网店/主页链接。地址和网址至少要有一个 | |
| name | Yes | 要核实的对象名称，例如「某某精密机械有限公司」 | |
| claim | Yes | 你想让真人帮你确认的那句话，例如「这个地址真的有一家在营业的工厂」 | |
| address | No | 详细地址。地址和网址至少要有一个 | |
| budget_yuan | 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 well: it discloses the multi-observer method, visits on separate days, unannounced arrival, the three independent written accounts returned, and that the account balance is charged. It omits operational specifics such as delivery time, what happens if the address is unreachable, or pricing/refund behavior, which keeps it short of 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?
The English and Chinese halves each front-load the mechanism and end with the use case and the billing note, so the reader gets the essentials immediately. The content is fully duplicated across languages, which doubles length, but the bilingual form is appropriate for this audience and no sentence within a language is 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?
With no annotations and no output schema, the description must stand alone, and it covers what the tool does, when to use it, what the result contains, and the cost implication. The remaining gaps — turnaround time, failure handling, and concrete pricing — are secondary for a selection decision but keep it from being fully 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 description coverage is 100%, so every parameter (url, name, claim, address, budget_yuan) is already documented, including the address-or-url rule and the budget trade-off. The description adds no parameter-level syntax or format beyond what the schema provides, so the baseline 3 applies.
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 concrete verb and resource with unusual specificity: sends three unacquainted real people to a physical address in China on different days, unannounced, to photograph, ask a question, and write independent accounts. The mechanism (three independent observers, one report) clearly separates it from data-only verification siblings like get_verification_result.
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 an explicit decision rule: use when the question is whether a supplier truly exists, is operating, or whether the sign matches the address — i.e., things only a person on site can answer. It does not, however, name or exclude the closest-looking sibling (ask_someone_there), leaving the agent to infer the boundary between the two.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
FREE. No API key, no balance, nothing is ordered. Call this FIRST whenever someone asks how to tell if a Chinese supplier, factory or company address is real. Returns the five checks they can do themselves from a desk for nothing — and, for each one, what it proves and what it does not prove — plus the three questions that only someone standing on that street can answer. Suggesting a paid site visit before the free checks wastes the user's money. 免费、不需要密钥、不会下任何单。有人问"怎么确认一家中国供应商/工厂/地址是不是真的"时先调这个：返回他自己坐在电脑前就能免费做的五件事，每件都写清楚证明了什么、证明不了什么，以及剩下哪三个问题只有到现场的人能答。
| Name | Required | Description | Default |
|---|---|---|---|
| subject | No | Optional. The company name or address being checked, used only to address the answer to it. **Nothing is looked up** — that is why this tool is free. 可选。只用来让这段话有个主语，我们不会去查它。 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does so: it declares the tool is free, needs no API key, orders nothing, and critically that 'Nothing is looked up' — establishing it is a side-effect-free informational read. It also previews the return shape (five checks plus three questions).
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 English portion is tightly front-loaded ('FREE. No API key...') and every sentence earns its place. However, the full Chinese translation duplicates the same content, roughly doubling length for a single-language reader, which is a modest structural cost.
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 zero-required-param informational tool with no output schema, the description fully explains what is returned and that no external lookup occurs. Nothing an agent needs in order to call it correctly is missing.
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% and the single optional 'subject' param is fully documented in the schema, so the baseline is 3. The description body adds no new syntax or format detail about the parameter beyond what the schema already states.
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 resource (a set of free self-serve checks) and what it returns: five checks with what each proves and does not prove, plus three questions requiring a street visit. It also draws the boundary against the paid siblings (verify_place, ask_someone_there) by declaring itself free and lookup-free.
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 ('Call this FIRST whenever someone asks how to tell if a Chinese supplier, factory or company address is real') and an explicit negative ('Suggesting a paid site visit before the free checks wastes the user's money'), which routes the agent to this tool before the paid verification siblings.
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.
what_can_i_check_myselfask_someone_thereget_ask_answerget_verification_resultverify_placeChina sourcing, inspection and supplier verification: published rates, scope and fee estimates.
Supplier scoring, AQL sampling plans and factory audit checklists for cross-border sourcing.
Verify a Chinese supplier before you pay: company identity, status, risk signals. x402 per call.
Ecommerce sourcing, inspection and fulfillment planning. Base-cost estimates; no private data.
Add one secure layer between your agents and this server.