获取活动的"卡片"数据（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 | Default |
|---|---|---|---|
| result | Yes |
Changes observed during successful MCP inspections.
Input schema / properties / activity_id / descriptionAdded value: +"活动 ID，从 query_activities 返回结果的 id 字段取得。必填"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.
Add one secure layer between your agents and this server.