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).
Scored across 8 tools
Most tools target distinct actions in the event lifecycle, but create_payment overlaps somewhat with register_event (which already returns payment links), and generate_urllink overlaps with get_activity_card for sharing activities. Descriptions help clarify the intended use, so ambiguity is limited.
All tools follow a consistent snake_case verb_noun pattern: check_in, create_activity, query_activities, register_event, etc. Minor internal capitalization in generate_urllink is not enough to break the overall pattern.
Eight tools cover a focused event-management domain: discovery, creation, registration, payment, check-in, sharing, and venue lookup. The count feels well-scoped and each tool has a reasonable place in the workflow.
The core flow of create → query → register → pay → check-in is covered, but there are notable lifecycle gaps: no update/cancel/delete for activities and no cancellation or refund tool for registrations. These are workable gaps but would require agents to stop mid-workflow.
活动签到。
用户到达活动现场后，通过此工具完成签到。支持手机号/用户ID/签到码三种方式。
Args:
activity_id: 活动 ID
phone: 手机号（用于签到，需与报名时一致）
user_id: 用户 ID（已登录用户）
code: 签到码（现场扫码获取，或主理人提供的签到口令）
Returns:
JSON 字符串，包含签到状态和签到时间
| Name | Required | Description | Default |
|---|---|---|---|
| code | No | ||
| phone | No | ||
| user_id | No | ||
| activity_id | Yes |
| 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 behavioral burden. It states that check-in is completed and returns a JSON string with status/time, but it does not explicitly mention side effects (e.g., marking attendance) or edge-case behavior (e.g., failure on invalid code). The three identification methods are disclosed, but the mutation aspect is implied rather than stated.
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 concise and well-structured: a short purpose statement, a context line, an Args block with per-parameter descriptions, and a Returns line. No fluff or redundancy; every sentence adds value and the key information is front-loaded.
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 low-complexity tool, the description covers the purpose, when to use it, all parameters, and the return format. It could be slightly more explicit that only one identifier (phone/user_id/code) is expected, and it doesn't describe error handling, but the output schema exists and the overall picture is sufficient for an agent to use 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?
Schema description coverage is 0%, so the description fully compensates. Each parameter is explained with meaning and usage context ('phone' must match registration, 'code' is from scan or host, etc.). This is significantly more than the schema provides, and an agent can correctly select the appropriate identifier.
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: '活动签到' (activity check-in), and elaborates that it is used when a user arrives at the event site. It clearly distinguishes this from siblings like create_payment or query_activities by naming the action and context, so an agent can immediately tell what the tool does without opening the 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?
The description gives clear context: use this tool when the user has arrived at the activity. It does not explicitly state exclusions or name alternatives, but the scenario is unambiguous enough that an agent can decide when to invoke it. The lack of a 'when not to use' statement prevents a 5.
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 | ||
| time | Yes | ||
| price | No | 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 carries the full burden of behavioral disclosure. It reveals that the tool creates an activity and returns a JSON string with an activity ID and link, but it does not mention side effects, permission requirements, idempotency, or consequences such as duplicate creation or irreversible publishing. For a mutating operation this is a notable gap.
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 core purpose, followed by a concise Args list and a Returns note. With 9 parameters and no schema descriptions, every line earns its place; there is no filler or redundant restatement of the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the 9-parameter schema, 0% schema description coverage, and no annotations, the description covers the invocation context well: when to use it, what each parameter means with examples, and what the return value looks like. It is slightly incomplete regarding behavioral caveats like authentication or whether max_participants=0 has special meaning, but an agent has enough to call it 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?
Schema description coverage is 0%, so the description fully compensates by documenting every parameter with concrete examples, allowed formats, and special values such as '免费填 "0" 或 0' and '数字字符串或整数均可'. This adds significant meaning beyond the bare schema property names.
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: '主理人在粗趣小程序上发布新活动' and '当用户（主理人）想创建/发布一个活动时调用此工具'. This clearly identifies the operation as creating a new activity and differentiates it from siblings like query_activities, get_activity_card, and register_event by emphasizing the organizer's publishing action.
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 explicitly states when to call the tool: when the user/organizer wants to create or publish an activity. It does not name alternatives or exclusion conditions, but the context is clear enough that an agent would not confuse it with querying or registering for activities.
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 |
| 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 that it returns a JSON string with payment link, QR code URL, payment method, and validity period, but does not mention any side effects (e.g., whether it marks the order as pending payment, creates a payment record, or if it is idempotent). It also doesn't discuss failure behavior (e.g., order not found) or permissions. This is a moderate disclosure but lacks depth expected for a tool without annotation support.
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 well-structured with a clear purpose statement, a usage note, an Args block, and a Returns block. It is front-loaded with the primary function and each section provides necessary information without fluff. It could be slightly more concise in the Args section (e.g., combining activity_id and phone), but overall it is efficient and 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?
Given 3 parameters, no required fields, zero schema coverage, and an output schema (not shown), the description covers the essential calling context: when to call, parameter selection logic, and return format. It lacks explicit error handling or edge-case guidance (e.g., what happens if no order is found), but for a payment link generator, the provided information is sufficient for an agent to invoke it correctly. The mention of obtaining order_id from register_event is a valuable cross-tool hint.
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% (parameters have only default '' and no descriptions). The description compensates by explaining each parameter: order_id (priority, from register_event), activity_id (used with phone), and phone (used with activity_id). It also explains the priority logic and fallback, which adds significant meaning beyond the bare schema. This is strong compensation 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 clearly states a specific verb and resource: '生成活动报名的支付链接和二维码' (generate payment link and QR code for event registration). It explains the purpose (obtain payment link after registration) and distinguishes itself from siblings like register_event (which creates the order) and generate_urllink (likely generic link generation). This is not a tautology and provides clear differentiation.
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 explicitly states when to use: '报名后通过此工具获取支付链接' (after registration, use this tool to obtain the payment link). It also gives parameter precedence (order_id first, fallback to activity_id+phone) and directs the agent to get order_id from register_event results. However, it does not explicitly mention when not to use or name alternatives, though the sibling list and purpose make the context clear. This is solid but not exhaustive.
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 | ||
| query | No | ||
| activity_id | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral disclosure burden. It discloses the generated link domain (https://wxaurl.cn/), the out-of-WeChat opening behavior, the click-through behavior into the mini program, and the precedence rule that activity_id overrides path and query. It does not mention side effects or rate limits, but for a link-generation tool the disclosed behavior is substantive.
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, followed by a compact Args block and a Returns line. The repeated '提供 activity_id 时忽略' note is slightly redundant but serves to reinforce a critical precedence rule in the parameter descriptions. Overall, there is no filler content.
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 the tool's moderate complexity, the description covers purpose, user intent, all three parameters, precedence, the output type, and the generated link's behavior. Since an output schema exists, the exact return keys do not need to be repeated in prose. This is sufficient for an agent to select and correctly invoke the 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%, so the description must explain all parameters, and it does thoroughly. It defines activity_id as mapping to a fixed activity detail page, path with a concrete example, and query as a urlencoded string with an example. It also explains the precedence relationship among parameters, which the schema itself does not convey.
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 opens with a specific verb and resource: '为小程序页面生成 URL Link' and clarifies that the link is a standard link openable outside WeChat. The stated trigger—'用户想获得某个页面（通常是活动详情页）的可分享链接时调用'—clearly separates it from the event/activity management siblings like create_activity or check_in.
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 explicitly says to call when the user wants a shareable link for a mini program page, usually an activity detail page. It does not list exclusions or name alternative tools, but no sibling tool appears to generate URL Links, so the when-to-use guidance is clear and sufficient.
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 |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden. It clearly signals a read-only retrieval action ('获取') and adds useful context about the two URL types (WeChat-external vs H5). However, it does not disclose side effects, permission requirements, failure modes, or the validity/expiry behavior of the generated links.
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 compact and well organized: purpose, trigger condition, returned fields, args, and returns. The bullet list is readable, though the 'C 端工具包核心' phrase contributes little and could be removed.
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 one-parameter retrieval tool with an output schema, the description is mostly sufficient to invoke the tool correctly. The main gaps are lack of sibling differentiation, no guidance on choosing between url_link and h5_url, and no constraints such as whether the activity must be published or currently open.
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?
The single parameter activity_id has 0% schema description coverage, and the Args line only restates '活动 ID', which adds essentially nothing beyond the schema's type and title. It does not explain where to find the ID, its format, or any validation requirements.
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 opens with a specific verb and resource ('获取活动的卡片数据') and lists the card's contents plus the two returned URLs. It is unambiguous what the tool does, but it does not explicitly contrast it with siblings such as generate_urllink, 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?
The description gives a direct trigger condition: call it when the user wants to see an activity's mini-program card with title, cover, time/location, price, and registration link. This is clear context, but it does not mention when-not-to-use or name alternative tools.
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 | ||
| keyword | No | ||
| location | No | ||
| activity_type | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden. It discloses that this is a query operation returning a JSON list with fields such as title, time, location, price, remaining spots, and H5 link. It does not mention read-only guarantees, pagination, sorting, or auth requirements, leaving some behavior implicit.
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 well organized into purpose, usage guidance, Args, and Returns sections. Each parameter line earns its place with examples and empty-value behavior, and the overall text is scannable without unnecessary 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 simple four-optional-parameter query tool, the description covers when to call it, all parameter meanings, and the return shape; the presence of an output schema reduces the need for return-value detail. Minor operational details such as pagination, default date behavior, or result limits are not addressed.
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%, but the description fully documents all four parameters: activity_type with examples, date with a format, location with examples, and keyword semantics. It also explains that empty values mean no filtering, fully compensating for the bare 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?
The description names a specific verb and resource: 'query the activity list on the 粗趣 mini-program' and adds usage intent like finding or filtering activities. It is clear, though it does not explicitly position itself against siblings such as get_activity_card or query_venues.
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 states when to call the tool: when the user wants to find activities, see available activities, or filter activities. It provides clear context but does not mention when not to use it or point to alternatives like get_activity_card for a single activity.
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?
With no annotations provided, the description carries the full behavioral burden. It does add meaningful context: '查询' signals a read-only operation, and the Returns section discloses the output shape (JSON string with name, type, location, capacity, price range, facilities). However, it does not mention authentication requirements, pagination limits, or how filters combine (AND vs OR), leaving some behavioral assumptions to the agent.
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 well-organized with a purpose statement, a usage-trigger sentence, an Args block with one line per parameter, and a Returns block. It is front-loaded and scannable. Minor redundancy exists between the opening sentence and the usage sentence, both conveying the venue-search purpose, but nothing is wasted.
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 simple 3-parameter, all-optional query tool, this description is nearly complete: it covers purpose, when to call, every parameter with semantics and examples, and the return format. The output schema exists per context signals, so return-value explanation is bonus. Remaining gaps (auth, pagination, failure behavior) are minor for a read-only list query.
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 fully compensates. Each parameter gets an explanation beyond the bare schema: venue_type has concrete examples (桌游吧, 运动场地, 露营基地), location has real district examples (南山区, 罗湖区), and min_capacity clarifies the integer-or-string acceptance plus the '0 means no filter' semantic. This is exactly what the dimension rewards.
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 opens with '查询粗趣小程序合作场地列表' — a specific verb (查询/query) plus a specific resource (合作场地列表/partner venue list) with an explicit scope (粗趣小程序). This clearly distinguishes it from siblings like query_activities, which targets activities rather than venues.
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 states an explicit usage trigger: '当用户需要找场地、了解场地信息时调用此工具' (call when the user needs to find venues or learn venue info). This gives the agent a clear decision rule. It does not explicitly name alternatives or exclusion cases, but given the sibling set, the venue-vs-activity contrast is strong enough to route correctly.
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 |
| 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 that registration requires payment to lock the seat, and that the return value contains an order number, payment link, and QR code URL. This goes beyond a simple 'register' statement and informs the agent of the consequential workflow.
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 well-organized and not verbose. It opens with the purpose, then gives the usage condition, then lists arguments with explanations, and closes with the return format. Every section contributes useful information, though the argument list could be more compact.
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 the tool has 4 parameters (3 required), an output schema, and the description explains each parameter and return behavior, it is sufficiently complete for correct invocation. It lacks details on error cases or idempotency, but those are not essential for a first 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 description coverage is 0%, so the description must compensate. It does so thoroughly: each parameter is explained with purpose and source (e.g., activity_id from query_activities, phone for notifications/check-in, note for optional requests). This adds clear meaning beyond the bare 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?
The description states a specific verb ('报名' / register) and resource ('活动' / activity), and includes a trigger condition ('当用户确定要报名某个活动时'). This clearly distinguishes it from siblings like create_activity, check_in, or query_activities.
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 explicitly says when to call the tool ('当用户确定要报名某个活动时'). It also mentions the post-registration payment step, and the argument description for activity_id instructs to get it from query_activities. However, it doesn't explicitly state when NOT to use it or name alternative tools.
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_increate_activitycreate_paymentgenerate_urllinkget_activity_cardquery_activitiesquery_venuesregister_event
Add one secure layer between your agents and this server.