Skip to main content
Glama

独行录 / opcmenu

by io.github.yzlee
OverviewDiscussionsAdmin

取分享卡素材

get_share_card_manifest
Read-onlyIdempotent

【需要登录】返回某对象的分享卡 manifest：shareText（现成的分享文案）+ link（落地页链接），外加单张完整图片的尺寸/版式元数据。agent 帮用户「把我的主页/需求分享出去」时用它拿文案和链接，可直接转发到任何渠道。

【kind 取值】owner（主理人主页卡，id=用户 id，自己或他人皆可）| need（需求卡，id=需求 id）| card（我的个人名片卡，仅本人，id 固定传 "me"）| position（我的定位卡，仅本人，id 固定传 "me"；定位栏唯一的分享出口）| onboarding（入驻完成卡，id 固定传 "me"）| activity（活动海报，id=活动 id）| product（产品分享图，id=产品 id）。

【名片上展示哪些需求】kind=card 时可传 need：给不同的人看不同的需求，可多选。先不传（或传 "auto"）拿一次，返回的 manifest.needPick.options 就是本人全部在架需求（id 原样回传，label 是给用户看的名字，hint 是需求类型）。need 取值："auto"=默认最近 3 条、"none"=名片上不展示需求、逗号分隔的需求 id（如 "id1,id2"，最多 20 个）=只展示这几条（此时 shareText 会带上「正在找：…」）。顺序无所谓，服务端按需求发布时间重排；失效或不属于本人的 id 会被丢掉，全部失效、或恰好就是默认那 3 条时按 auto。实际生效看返回的 manifest.needPick：custom=false 是默认、custom=true 时 selected 就是名片上实际展示的需求 id。manifest 没有 needPick 字段 = 本人没有在架需求，无需选择。其余 kind 忽略 need。

【注意】返回里没有图片 URL——卡片图片的渲染接口是登录态 + private 缓存的站内接口，不要自己拼 image URL 当公开资源发给第三方；对外分享一律用 shareText + link。

【失败语义】对象不存在返回 found=false；kind=card / onboarding 而 id 不是 "me" 报 403。

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
idYes对象 id：owner=用户 id；need=需求 id；activity=活动 id；product=产品 id；card/position/onboarding 固定 "me"
kindYes分享卡类型：owner 主理人主页（id=用户 id） | need 需求（id=需求 id） | card 我的个人名片（id 固定 "me"） | position 我的定位卡（id 固定 "me"） | onboarding 入驻完成（id 固定 "me"） | activity 活动海报（id=活动 id） | product 产品分享图（id=产品 id）
needNo仅 kind=card 生效：名片上展示哪些需求。"auto"（缺省，最近 3 条）| "none"（不展示需求）| 逗号分隔的需求 id（1~20 个，只展示这几条）。可选项见返回的 manifest.needPick.options[].id，实际生效见 manifest.needPick.custom / selected

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • changedInput schema / properties / need / description
      Previous value: -"仅 kind=card 生效：名片上展示哪条需求。\"auto\"（缺省，最近 3 条）| \"none\"（不展示需求）| 需求 id（只展示这一条）。可选值见返回的 manifest.needs.choices[].value"New value: +"仅 kind=card 生效：名片上展示哪些需求。\"auto\"（缺省，最近 3 条）| \"none\"（不展示需求）| 逗号分隔的需求 id（1~20 个，只展示这几条）。可选项见返回的 manifest.needPick.options[].id，实际生效见 manifest.needPick.custom / selected"
    • changedInput schema / properties / need / maxLength
      Previous value: -64New value: +900
  2. Changed1 schema field changed
    • addedInput schema / properties / need
      Added value: +{
+  "description": "仅 kind=card 生效：名片上展示哪条需求。\"auto\"（缺省，最近 3 条）| \"none\"（不展示需求）| 需求 id（只展示这一条）。可选值见返回的 manifest.needs.choices[].value",
+  "maxLength": 64,
+  "type": "string"
+}
  3. Changed3 schema fields changed
    • changedInput schema / properties / id / description
      Previous value: -"对象 id：owner=用户 id；need=需求 id；onboarding 固定 \"me\""New value: +"对象 id：owner=用户 id；need=需求 id；activity=活动 id；product=产品 id；card/position/onboarding 固定 \"me\""
    • changedInput schema / properties / kind / description
      Previous value: -"分享卡类型：owner 主理人主页（id=用户 id） | need 需求（id=需求 id） | card 我的个人名片（id 固定 \"me\"） | position 我的定位卡（id 固定 \"me\"） | onboarding 入驻完成（id 固定 \"me\"）"New value: +"分享卡类型：owner 主理人主页（id=用户 id） | need 需求（id=需求 id） | card 我的个人名片（id 固定 \"me\"） | position 我的定位卡（id 固定 \"me\"） | onboarding 入驻完成（id 固定 \"me\"） | activity 活动海报（id=活动 id） | product 产品分享图（id=产品 id）"
    • changedInput schema / properties / kind / enum
      Previous value: -[
-  "owner",
-  "need",
-  "onboarding",
-  "card",
-  "position",
-  "activity"
-]New value: +[
+  "owner",
+  "need",
+  "onboarding",
+  "card",
+  "position",
+  "activity",
+  "product"
+]
  4. First observed

TDQS

A4.4/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Beyond the readOnly/idempotent/non-destructive annotations, the description adds several critical behavioral facts: login is required, no public image URL is returned and the internal rendering endpoint must not be used as a public resource, failure semantics (found=false for missing object; 403 when card/onboarding id is not 'me'), and detailed needPick side-effect behavior. This is exactly the kind of extra context annotations cannot provide.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the return contract and use case, then organized under labeled sections, which helps scanning. However, the 【kind 取值】 section duplicates the enum descriptions already fully present in the schema, and the overall length is longer than necessary for a 3-parameter tool.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description does well to explain the key return values (shareText, link, image layout metadata) and the needPick structure, plus failure modes. It stops short of fully describing every possible manifest field, but it gives enough for an agent to invoke the tool and interpret the response correctly given the complexity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

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 substantial meaning beyond the schema for the 'need' parameter: auto/none/custom ID-list semantics, max 20 IDs, how invalid or non-owned IDs are dropped, how order is reordered server-side, and how manifest.needPick.custom/selected signals actual effect. The kind and id descriptions largely repeat the schema, which keeps this from being a 5.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: returns a share-card manifest with shareText, link, and image layout metadata. It clearly distinguishes the tool's use case (fetching copy/link for sharing) from sending actions, so an agent can tell it apart from nearby siblings like send_share_card or create_cooperation_share.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives explicit usage context ('agent 帮用户「把我的主页/需求分享出去」时用它拿文案和链接') and detailed per-kind when-to-use rules, including which id to pass and that other kinds ignore need. It does not name alternative sibling tools or state when not to use this tool, so it falls short of a 5.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All 独行录 / opcmenu toolsInspect
Try in Browser
Pay for results, not tokens.Fund a bounty. Let AI agents compete and collaborate to solve your problems.agentbounties.appAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources