CUQU (找搭子) is a local offline social activities platform in China (Shenzhen-based, 10+ cities). Its MCP gateway exposes 8 tools: activity search, event booking, payment, check-in, organizer event creation, venue search, and share-link generation, covering 100+ activity categories (board games, frisbee, hiking, badminton, fishing, anime and more).
The last two health checks of this connector failed. If this server requires authentication, missing or expired test credentials may be the cause. A test profile lets Glama authenticate for health checks and discover tools; it is separate from your personal connections.
If you are the author, claim ownership, then add or update a test profile under Admin → Test Profile.
Scored across 8 tools
Most tools have clearly distinct purposes: querying activities/venues, creating activities, registration, check-in, and link generation. However, create_payment overlaps with register_event, which already returns a payment link and QR code, and get_activity_card partially overlaps with generate_urllink since it also returns a URL link.
Tool names consistently use snake_case with a verb-first pattern (check_in, create_activity, query_activities, register_event, etc.). The only minor deviation is 'generate_urllink', where 'urllink' is fused rather than separated, but the overall convention remains predictable.
Eight tools is a well-scoped set for an event management mini-program. Each tool maps to a clear user workflow: discovery, creation, registration, payment, check-in, and sharing.
The core user journey is covered (find activities/venues, create activity, register, pay, check in, share links). However, notable lifecycle operations are missing: there is no update/delete/cancel for activities, no cancel registration or refund, no payment status query, and no way to list a user's registrations or orders.
活动签到。
用户到达活动现场后，通过此工具完成签到。支持手机号/用户ID/签到码三种方式。
Args:
activity_id: 活动 ID
phone: 手机号（用于签到，需与报名时一致）
user_id: 用户 ID（已登录用户）
code: 签到码（现场扫码获取，或主理人提供的签到口令）
Returns:
JSON 字符串，包含签到状态和签到时间
| Name | Required | Description | Default |
|---|---|---|---|
| code | No | 签到码，现场主理人提供 | |
| phone | No | 签到人手机号 | |
| user_id | No | 用户 ID，不传时用当前会话用户身份 | |
| activity_id | Yes | 活动 ID |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It discloses that a return value includes check-in status and time, and that phone must match registration, but it omits important behavior such as whether check-in is idempotent, what happens if already checked in, and what authorization/permission requirements exist.
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 purpose and then structured into Args and Returns sections. It is appropriately sized and has no wasted text, though the Args section partly repeats schema descriptions.
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 check-in mutation with no annotations, the definition covers purpose, methods, parameters, and a basic return shape. However, it lacks important edge-case behavior such as duplicate check-in handling, authorization requirements, and failure modes, leaving gaps for an agent to infer.
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 100%, so baseline is 3. The description adds value beyond the schema by noting that phone must match the registration record and that code can come from an on-site scan or the organizer's check-in token.
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: '活动签到' (activity check-in), and clarifies it occurs after the user arrives at the event. This implicitly distinguishes it from sibling register_event, but it does not explicitly name or contrast with that alternative.
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 clearly says to use this tool when the user has arrived at the event, and it lists three supported methods (phone, user_id, code). It gives clear context but does not state when not to use it or explicitly compare with alternatives like register_event.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
主理人在粗趣小程序上发布新活动。
当用户（主理人）想创建/发布一个活动时调用此工具。
Args:
title: 活动标题，如"周六桌游聚会"
activity_type: 活动类型，如"桌游聚会"、"户外徒步"、"剧本杀/密室"等
date: 活动日期，格式"2026-08-22"
time: 活动时间段，如"14:00-18:00"
location: 活动地点，如"南山区·科兴科学园"
max_participants: 最大参与人数，数字字符串或整数均可，如 "15" 或 15
price: 人均费用（元），数字字符串或整数均可，如 "39" 或 39，免费填 "0" 或 0
description: 活动描述和注意事项
organizer: 主理人名称
Returns:
JSON 字符串，包含活动 ID 和详情链接
| Name | Required | Description | Default |
|---|---|---|---|
| date | Yes | 活动日期，格式 YYYY-MM-DD | |
| time | Yes | 开始时间，格式 HH:MM，如 19:30 | |
| price | No | 单人价格（元），免费填 0 | 0 |
| title | Yes | 活动标题，一句话说清是什么活动，如「周六南山羽毛球新手局」 | |
| location | Yes | 活动地点，尽量写到区或具体场馆 | |
| organizer | No | 主理人（组织者）称呼或昵称 | |
| description | No | 活动详细介绍，包括流程、适合谁、需要带什么 | |
| activity_type | Yes | 活动类型，如：桌游聚会、徒步、飞盘、羽毛球 | |
| max_participants | No | 人数上限（整数） | 0 |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full behavioral burden. It discloses that the result is a JSON string with an activity ID and a detail link, which is useful; however, it says nothing about whether publishing is immediate or visible to others, who is authorized, or how duplicates are handled.
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 purpose is front-loaded in one clear sentence, but the Args block repeats schema descriptions nearly verbatim, so it costs space without adding information. This is acceptable but not tight.
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?
Because an output schema exists, the return-value explanation is not strictly necessary. However, for a 9-parameter mutation tool with no annotations, the description leaves out authorization and visibility behavior, which is a meaningful gap.
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 9 parameters, making 3 the baseline. The Args section largely restates the schema, and its example for time ('14:00-18:00') is a range, while the schema defines time as a start time ('HH:MM'), which adds mild ambiguity rather than clarity.
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 and resource in a specific platform context ('主理人在粗趣小程序上发布新活动'), which is unambiguous. It does not name or differentiate itself from siblings like query_activities or register_event, so it stops 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 a clear trigger condition and an actor (主理人). There are no exclusions or named alternatives, such as when to use query or register instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
生成活动报名的支付链接和二维码。
报名后通过此工具获取支付链接，用户扫码或点击链接完成微信支付。
Args:
order_id: 订单号（优先使用，从 register_event 结果中获取）
activity_id: 活动 ID（无订单号时配合手机号使用）
phone: 手机号（配合活动 ID 查找订单）
Returns:
JSON 字符串，包含支付链接、二维码 URL、支付方式和有效期
| Name | Required | Description | Default |
|---|---|---|---|
| phone | No | 付款人手机号 | |
| order_id | No | 订单号，报名成功后返回 | |
| activity_id | No | 活动 ID |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It discloses that payment is WeChat Pay and that links have an expiry, which is valuable. It does not say whether repeated calls mint new links, what happens if the order/activity+phone lookup fails, or whether the link is one-time use.
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 summary sentence, then a one-line usage sentence, then Args and Returns. No filler, and structure matches a conventional docstring that is easy to scan.
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?
Output schema exists, so return values need not be explained; the Args/Returns here still summarize them. For a 3-param, all-optional payment-link tool with no annotations, what's missing is failure/edge behavior (order not found, expired order), which keeps it from a 5.
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 100%, but the Args block adds real meaning beyond the schema: it declares the precedence relationship (order_id first, fall back to activity_id + phone) and the provenance of order_id from register_event. That is genuinely useful routing information.
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 first line names a concrete verb+resource: generate a payment link and QR code for an event registration. This clearly tells an agent what the tool produces and is distinguishable from sibling create_activity/register_event calls. It stops short of naming which sibling it complements, so it does not 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?
It says to call this after registration to obtain the payment link, and the Args section states order_id is preferred and comes from the register_event result. That is clear usage context, but no explicit when-not call or distractor sibling (e.g., generate_urllink) is mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
为小程序页面生成 URL Link（微信外可打开的标准链接）。
用户想获得某个页面（通常是活动详情页）的可分享链接时调用。
生成的 https://wxaurl.cn/ 链接可在短信、邮件、网页、AI 应用等微信外场景打开，
点击后唤起微信小程序对应页面。
Args:
activity_id: 活动 ID。提供时自动映射到活动详情页（path=pages/activity/detail, query=id=xxx）。
path: 小程序页面路径，如 "pages/index/index"。提供 activity_id 时忽略。
query: 页面参数（urlencode 后的字符串），如 "id=act_001"。提供 activity_id 时忽略。
Returns:
JSON 字符串，包含 URL Link、页面路径和参数
| Name | Required | Description | Default |
|---|---|---|---|
| path | No | 小程序页面路径，默认 pages/home/home（首页）。一般不用传 | |
| query | No | 附加到路径上的查询参数，如 a=1&b=2。一般不用传 | |
| activity_id | No | 活动 ID。传了则生成该活动详情页的小程序链接 |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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 that the result is an https://wxaurl.cn/ link that opens outside WeChat and invokes the mini-program page, plus the return shape. However, it omits important behavioral traits of URL Link generation such as link validity/expiry and API quota consumption, which affect how an agent should use the output.
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, then a usage sentence, then compact Args/Returns blocks. Every line adds information and nothing duplicates the schema defaults verbatim.
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?
An output schema exists, so return values need not be explained further, and the three optional parameters are fully covered with precedence rules. The remaining gap is operational context around link lifetime/quota, which is relevant but secondary for a correctly formed call.
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 100%, so the baseline is 3, but the description adds real semantics: activity_id auto-maps to path=pages/activity/detail with query id=xxx, and path/query are ignored when activity_id is provided. That precedence rule is not expressed in the schema and prevents misuse.
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 first line states a specific verb and artifact: generate a URL Link for a mini-program page, explicitly noting it is a standard link openable outside WeChat. This is unmistakable against siblings (check_in, create_activity, query_activities) which operate on activities/venues, not link generation.
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 trigger condition: call when the user wants a shareable link to a page, usually an activity detail page. It does not state when NOT to use it or name alternatives, but no sibling tool overlaps with this capability, so the guidance is sufficient in practice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
获取活动的"卡片"数据（C 端工具包核心）。
当用户想直接看到某活动的小程序卡片（标题 + 封面 + 时间地点 + 价格 + 报名链接）
时调用此工具。返回的卡片包含：
- url_link: 小程序 URL Link（微信外点击唤起小程序活动页）
- h5_url: H5 活动页地址（AI 应用内直接打开）
Args:
activity_id: 活动 ID
Returns:
JSON 字符串，包含活动卡片数据
| Name | Required | Description | Default |
|---|---|---|---|
| activity_id | Yes | 活动 ID，从 query_activities 返回结果的 id 字段取得。必填 |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It usefully explains that url_link wakes the mini-program from outside WeChat and h5_url opens directly in-app, giving real behavioral context. But it never states the read-only/no-side-effect nature or how card data is sourced, leaving gaps for a no-annotation 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?
The core purpose is front-loaded in the first line, followed by a clear when-to-use sentence and a structured return breakdown. No filler, though the Args/Returns scaffolding is somewhat verbose relative to a single-parameter 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?
An output schema exists, and the description still adds useful semantics for the two key return fields. Combined with the single documented parameter, it is nearly complete, only missing the safety/side-effect profile for a no-annotation 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 coverage is 100% and the schema already documents activity_id's origin (from query_activities). The description only restates 'activity_id: 活动 ID', adding no meaning beyond the schema, 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 specific verb and resource ('get activity card') and enumerates the card contents (title, cover, time/location, price, registration link). It is distinguishable from query_activities, though potential overlap with generate_urllink (both produce URLs) is not addressed.
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 states the triggering context: call when the user wants to directly see the mini-program card. However, it names no alternatives or exclusions, so the agent must infer why this differs from generate_urllink rather than being told.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
查询粗趣小程序上的活动列表。
当用户想找活动、看有什么活动、按条件筛选活动时调用此工具。
Args:
activity_type: 活动类型筛选，如"桌游聚会"、"户外徒步"、"剧本杀"、"飞盘"等。留空则不筛选。
date: 日期筛选，格式"2026-08-22"。留空则不筛选。
location: 区域筛选，如"南山区"、"罗湖区"。留空则不筛选。
keyword: 关键词搜索活动标题和描述。留空则不搜索。
Returns:
JSON 字符串，包含活动列表（标题、时间、地点、价格、剩余名额、H5 链接等）
| Name | Required | Description | Default |
|---|---|---|---|
| date | No | 日期筛选。支持「今天/明天/周末/本周」「2026-11-01」等自然语言与标准日期，不传表示不限日期 | |
| limit | No | 返回条数上限，1-100，默认 50。想看更多就传大一点 | |
| keyword | No | 关键词，在活动标题与描述中模糊匹配，如：露营、新手、女生场。不传表示不过滤 | |
| district | No | 区/县名，如：南山、福田、龙岗、惠东县。与 location 同传时按 城市+区 两级过滤。不传则不过滤区 | |
| location | No | 城市名，如：深圳、广州、惠州、东莞。不传表示不限城市 | |
| activity_type | No | 活动类型，如：桌游聚会、徒步、飞盘、羽毛球、二次元、钓鱼。模糊词请传完整常见说法（如「桌游聚会」而非「桌游」），传错会返回空 |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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 the return shape (title, time, location, price, remaining slots, H5 link), which is useful, but it never states that this is a pure read operation, whether results are paginated/capped, or what happens when filters yield nothing — and the sibling get_activity_card hints that single-activity retrieval is a separate concern this tool does not cover.
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?
Well front-loaded: purpose, then when-to-use, then parameters, then returns. The Args block largely restates schema fields that already have 100% description coverage, so it is somewhat redundant, but the ordering makes it easy to scan and no sentence is pure 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 read-only, zero-required-parameter query tool this covers purpose, invocation triggers, most filters, and return content. The gaps are minor given the schema and output schema exist: no mention of `limit`/result caps or of what an empty result set looks like, and the location-vs-district semantics conflict with the schema.
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 100% so the baseline is 3, and the schema is actually richer than the description in key ways. The description omits the `limit` and `district` parameters entirely, and its `location` entry describes a district-level filter with examples like 南山区/罗湖区, whereas the schema defines `location` as a city (深圳/广州) and puts districts in `district` — a mismatch that could steer an agent to pass a district name to the wrong parameter. It also narrows `date` to the "2026-08-22" format while the schema supports 今天/明天/周末.
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 opening line states a specific verb and resource (query the activity list on the Cuqu mini-program), which is clearly distinct from write-oriented siblings like create_activity and register_event. It does not explicitly contrast itself with get_activity_card (single activity) or query_venues (venues), so differentiation is inferable but not spelled out.
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 second line gives an explicit trigger condition: call this when the user wants to find activities, browse what's available, or filter by conditions. That covers the primary use cases well, but it names no exclusions or alternative tools for overlapping needs (e.g. fetching a single activity's detail).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
查询粗趣小程序合作场地列表。
当用户需要找场地、了解场地信息时调用此工具。
Args:
venue_type: 场地类型，如"桌游吧"、"运动场地"、"露营基地"等。留空则不筛选。
location: 区域，如"南山区"、"罗湖区"。留空则不筛选。
min_capacity: 最少容纳人数，整数或数字字符串均可，如 10 或 "10"。填0则不筛选。
Returns:
JSON 字符串，包含场地列表（名称、类型、位置、容量、价格区间、设施等）
| Name | Required | Description | Default |
|---|---|---|---|
| location | No | 城市或区域名，如：深圳、南山。不传表示不限 | |
| venue_type | No | 场地类型，如：桌游吧、羽毛球馆、咖啡馆、户外草坪、会议室。不传表示不限类型 | |
| min_capacity | No | 最少容纳人数（整数），用于过滤掉太小的场地。不传表示不限 | 0 |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
没有 annotations，描述隐含这是只读查询，并说明返回 JSON 场地列表及包含字段。但未说明权限要求、分页、错误处理或调用限制，行为披露有限。
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?
结构清晰，先说明用途和调用时机，再列出参数与返回。Args 和 Returns 部分略冗长，但整体可读且信息有效。
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?
工具较简单，3 个可选参数，且已有 output schema，描述覆盖了用途、调用时机、参数含义和返回内容。缺少分页或权限等补充信息，但对该查询工具已基本完整。
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 描述覆盖率 100%，参数含义已由 schema 充分说明。描述补充了示例和“填 0 则不筛选”的过滤语义，但大部分信息与 schema 重复，符合基线 3。
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?
明确说明查询合作场地列表，并指出用户找场地或了解场地信息时调用；动词和资源都具体，能与兄弟工具中的活动、支付、签到等区分开。
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?
给出了清晰的调用场景（需要找场地、了解场地信息），但没有说明何时不应使用，也没有列出替代工具或前置条件。
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
用户报名参加活动。
当用户确定要报名某个活动时调用此工具。报名后需要完成支付才能锁定名额。
Args:
activity_id: 活动 ID（从 query_activities 结果中获取）
user_name: 报名人姓名
phone: 手机号（用于接收活动通知和签到）
note: 备注，如饮食禁忌、特殊需求等（可选）
Returns:
JSON 字符串，包含订单号、支付链接和支付二维码 URL
| Name | Required | Description | Default |
|---|---|---|---|
| note | No | 备注，如「带朋友一位」「第一次玩」 | |
| phone | Yes | 报名人手机号，用于活动前联系 | |
| user_name | Yes | 报名人姓名或昵称 | |
| activity_id | Yes | 要报名的活动 ID，从 query_activities 取得。必填 |
| Name | Required | Description |
|---|---|---|
| result | 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 discloses the important consequence that registration alone does not lock a slot and payment must follow, plus the return payload (order number, payment link, QR code). However, it says nothing about behavior when an activity is full, whether duplicate registrations are possible, or whether/cómo a registration can be cancelled.
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 trigger condition is front-loaded, followed by a brief payment caveat and a clean Args/Returns layout. The Args block largely restates the schema, which is minor redundancy but keeps the definition scannable.
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?
Covers when to call, all required inputs, the payment precondition, and the return shape; the presence of an output schema makes the Returns section redundant but harmless. The main gap is edge-case behavior (full activity, duplicate signup, cancellation) for a mutation tool with no annotations.
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 and the baseline is 3. The description adds modest extra meaning — phone is for activity notifications and check-in (schema only says pre-event contact), and note covers dietary restrictions/special needs. Useful but marginal over the schema.
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: '用户报名参加活动' (register a user for an activity), which cleanly distinguishes it from siblings like check_in, create_payment, and query_activities. It doesn't explicitly name which sibling to use instead, but the action is unambiguous.
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 a clear trigger condition, and the Args section points to query_activities as the source of activity_id, implicitly establishing the lookup-then-register flow. No explicit exclusions or when-not guidance.
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.
check_in4 fields changedInput schema / properties / activity_id / descriptionAdded value: +"活动 ID"Input schema / properties / code / descriptionAdded value: +"签到码，现场主理人提供"Input schema / properties / phone / descriptionAdded value: +"签到人手机号"Input schema / properties / user_id / descriptionAdded value: +"用户 ID，不传时用当前会话用户身份"create_activity9 fields changedInput schema / properties / activity_type / descriptionAdded value: +"活动类型，如：桌游聚会、徒步、飞盘、羽毛球"Input schema / properties / date / descriptionAdded value: +"活动日期，格式 YYYY-MM-DD"Input schema / properties / description / descriptionAdded value: +"活动详细介绍，包括流程、适合谁、需要带什么"Input schema / properties / location / descriptionAdded value: +"活动地点，尽量写到区或具体场馆"Input schema / properties / max_participants / descriptionAdded value: +"人数上限（整数）"Input schema / properties / organizer / descriptionAdded value: +"主理人（组织者）称呼或昵称"Input schema / properties / price / descriptionAdded value: +"单人价格（元），免费填 0"Input schema / properties / time / descriptionAdded value: +"开始时间，格式 HH:MM，如 19:30"Input schema / properties / title / descriptionAdded value: +"活动标题，一句话说清是什么活动，如「周六南山羽毛球新手局」"create_payment3 fields changedInput schema / properties / activity_id / descriptionAdded value: +"活动 ID"Input schema / properties / order_id / descriptionAdded value: +"订单号，报名成功后返回"Input schema / properties / phone / descriptionAdded value: +"付款人手机号"generate_urllink3 fields changedInput schema / properties / activity_id / descriptionAdded value: +"活动 ID。传了则生成该活动详情页的小程序链接"Input schema / properties / path / descriptionAdded value: +"小程序页面路径，默认 pages/home/home（首页）。一般不用传"Input schema / properties / query / descriptionAdded value: +"附加到路径上的查询参数，如 a=1&b=2。一般不用传"get_activity_card1 field changedInput schema / properties / activity_id / descriptionAdded value: +"活动 ID，从 query_activities 返回结果的 id 字段取得。必填"query_activities6 fields changedInput schema / properties / activity_type / descriptionAdded value: +"活动类型，如：桌游聚会、徒步、飞盘、羽毛球、二次元、钓鱼。模糊词请传完整常见说法（如「桌游聚会」而非「桌游」），传错会返回空"Input schema / properties / date / descriptionAdded value: +"日期筛选。支持「今天/明天/周末/本周」「2026-11-01」等自然语言与标准日期，不传表示不限日期"Input schema / properties / districtAdded value: +{
+ "description": "区/县名，如：南山、福田、龙岗、惠东县。与 location 同传时按 城市+区 两级过滤。不传则不过滤区",
+ "type": "string"
+}Input schema / properties / keyword / descriptionAdded value: +"关键词，在活动标题与描述中模糊匹配，如：露营、新手、女生场。不传表示不过滤"Input schema / properties / limitAdded value: +{
+ "description": "返回条数上限，1-100，默认 50。想看更多就传大一点",
+ "type": "integer"
+}Input schema / properties / location / descriptionAdded value: +"城市名，如：深圳、广州、惠州、东莞。不传表示不限城市"query_venues3 fields changedInput schema / properties / location / descriptionAdded value: +"城市或区域名，如：深圳、南山。不传表示不限"Input schema / properties / min_capacity / descriptionAdded value: +"最少容纳人数（整数），用于过滤掉太小的场地。不传表示不限"Input schema / properties / venue_type / descriptionAdded value: +"场地类型，如：桌游吧、羽毛球馆、咖啡馆、户外草坪、会议室。不传表示不限类型"register_event4 fields changedInput schema / properties / activity_id / descriptionAdded value: +"要报名的活动 ID，从 query_activities 取得。必填"Input schema / properties / note / descriptionAdded value: +"备注，如「带朋友一位」「第一次玩」"Input schema / properties / phone / descriptionAdded value: +"报名人手机号，用于活动前联系"Input schema / properties / user_name / descriptionAdded value: +"报名人姓名或昵称"query_activities2 fields changedInput schema / properties / districtRemoved value: -{
- "description": "区/县名，如：南山、福田、龙岗、惠东县。与 city 同传时按 城市+区 两级过滤；支持常见别名（area/zone）。不传则不过滤区",
- "type": "string"
-}Input schema / properties / limitRemoved value: -{
- "description": "返回条数上限，1-100，默认 50。想看更多就传大一点",
- "type": "integer"
-}query_activities2 fields changedInput schema / properties / districtAdded value: +{
+ "description": "区/县名，如：南山、福田、龙岗、惠东县。与 city 同传时按 城市+区 两级过滤；支持常见别名（area/zone）。不传则不过滤区",
+ "type": "string"
+}Input schema / properties / limitAdded value: +{
+ "description": "返回条数上限，1-100，默认 50。想看更多就传大一点",
+ "type": "integer"
+}check_increate_activitycreate_paymentregister_eventcheck_increate_activitycreate_paymentregister_eventcheck_increate_activitycreate_paymentgenerate_urllinkget_activity_cardquery_activitiesquery_venuesregister_event
Add one secure layer between your agents and this server.