Skip to main content
Glama

独行录 / opcmenu

取分享卡素材

get_share_card_manifest
Read-onlyIdempotent

【需要登录】取shareText、link及图片布局,分享前两者;无公开图片URL,勿外发私有渲染接口。对象不存在found=false;card/onboarding非me403。card.need先读needPick.options,auto最近3条/none隐藏/逗号id最多20;丢弃无效或他人id,全无效或等同默认退auto;按发布时间排序,以selected/custom为准;无needPick=无在架需求,其他kind忽略need。

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
idYesowner/need/activity/product传对象id;card/position/onboarding固定me
kindYesowner主理人主页/need需求/activity活动海报/product产品图;card本人名片/position本人定位/onboarding入驻完成
needNo仅card:auto(默认最近3条)/none(隐藏)/逗号id(1~20);先读needPick.options,结果见selected/custom

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • changedInput schema / properties / id / description
      Previous value: -"对象 id:owner=用户 id;need=需求 id;activity=活动 id;product=产品 id;card/position/onboarding 固定 \"me\""New value: +"owner/need/activity/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\") | activity 活动海报(id=活动 id) | product 产品分享图(id=产品 id)"New value: +"owner主理人主页/need需求/activity活动海报/product产品图;card本人名片/position本人定位/onboarding入驻完成"
    • changedInput schema / properties / need / description
      Previous value: -"仅 kind=card 生效:名片上展示哪些需求。\"auto\"(缺省,最近 3 条)| \"none\"(不展示需求)| 逗号分隔的需求 id(1~20 个,只展示这几条)。可选项见返回的 manifest.needPick.options[].id,实际生效见 manifest.needPick.custom / selected"New value: +"仅card:auto(默认最近3条)/none(隐藏)/逗号id(1~20);先读needPick.options,结果见selected/custom"
  2. 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
  3. 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"
      +}
  4. 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"
      +]
  5. First observed

TDQS

A3.9/5.0
Behavior4/5

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

Annotations already declare readOnly/idempotent/destructive=false, but the description adds meaningful behavior beyond them: login requirement, found=false for missing objects, 403 for card/onboarding non-me, and the absence of a public image URL. That is a strong behavioral disclosure for a read tool.

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?

It is compact with no filler, but the density and clipped tokens (e.g. '非me403', 'need先读needPick.options') make it hard to parse, and the error-code and need-resolution logic are packed into one run-on block. Front-loaded login note is a plus.

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 carries return-value burden and does reasonably: it names returned fields (shareText, link, layout, needPick.options, selected/custom) plus error states. Complete enough for an agent to call and interpret results, though the image layout shape is left vague.

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 enum for kind and the need format are already documented, but the description adds behavioral semantics: how card.need is resolved (discard invalid/others' ids, all-invalid falls back to auto, sorted by publish time, selected/custom wins), which is genuinely beyond the schema.

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

Purpose4/5

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

States a specific verb+resource: retrieves shareText, link and image layout for a share card. This clearly separates it from the write sibling send_share_card. It is specific enough to act on, though it does not explicitly name alternatives.

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?

Gives real usage constraints: requires login, only shareText and link are meant to be shared, and the private image render endpoint must not be exposed externally. This is actionable when-to-use context, though it stops short of naming an alternative tool or exclusion conditions.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources