Skip to main content
Glama

独行录 / opcmenu

看产业链链位(以任意节点为锚)

get_chain_anchor
Idempotent

【需要登录】【何时用】「我在产业链的什么位置」「我的上游下游是谁」「这家公司的上下游有哪些」。返回以某个节点为锚的自我中心视图:上游若干环 + 锚点自己的链位 + 下游若干环,每环带成员。

【组合链·多跳】 · 不传 subjectType/subjectId 就直接落在「我」身上(我 + 我的已发布产品里的默认锚点),一次调用就位;返回体里带 myAnchors 告诉你我还有哪些锚点可切。 · 拿链上任意成员的 id 再调本接口就是下一跳(「上游的上游」)——这就是递归展开产业链的全部方法。 · 先 metadataOnly=true 探方向(只出类别和计数,不判成员,快且省),锁定要看的那一类再用 list_chain_group_members 翻它的成员。 · 成员 members[].id(type=user)→ get_creator → start_conversation;members[].claimed===false 表示这条是爬虫抓来的目录条目,背后没有能对话的真人,别去开聊,引导用户看 siteUrl。 · 我自己还没归位(anchor.placed=false)→ set_my_chain_position 用一段自由文本归位。

【口径/坑】 · 这个接口真花钱:成员是 LLM 成对审核判出来的(判完落缓存)。别为了看全而循环翻到底,一屏够用;也别对同一个锚点反复调。 · memberLimit 不对外开放任意数值(照 apps/api chain/anchor 路由的约束),只给 metadataOnly 一个开关:true = 一个成员都不判,只要类别元数据。 · warming=true 表示还有候选没判完、后台在续判——这时候空成员不等于没人,如实说「还没判完,等会儿再看」,不许下「这一环没人」的结论。 · 每组的 supply 字段区分三种空:none(站内确实还没有这类主体)/ gated(有候选但证明不了真实价值流,宁缺毋滥)/ warming(还在判)。三种说法完全不同,别混成一句「没有」。 · profileVersion 是分页游标的绑定版本,翻成员时要原样带上(见 list_chain_group_members)。

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
subjectIdNo锚点 id;与 subjectType 成对给,留空就用我自己的
subjectTypeNo锚点类型 user|product;**留空就用我自己的默认锚点**
metadataOnlyNotrue = 只要类别元数据、一个成员都不判(快、省钱,探方向用)。默认 false = 每类给一屏预览成员

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. First observed

TDQS

A4.7/5.0
Behavior5/5

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

The description discloses traits absent from annotations: it requires login, costs money because members are LLM-pair-reviewed and cached, metadataOnly skips member judgment, warming indicates background processing, supply has three distinct empty states, and pagination needs profileVersion. These enrich the sparse annotations (readOnlyHint=false, openWorldHint=true) without contradicting them.

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

Conciseness5/5

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

The description is long but tightly organized with clear headers (何时用 / 组合链·多跳 / 口径/坑) and bulleted pitfalls. Every section carries load-bearing operational guidance, and the purpose is front-loaded before the details.

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

Completeness5/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 compensates by explaining the response shape: ego-centric rings with members, myAnchors, anchor.placed, members[].id/claimed, supply values, warming flag, and profileVersion cursor. It also covers the main follow-up tools and edge cases, leaving little ambiguity for an agent.

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

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema descriptions already cover all three parameters with 100% coverage, including the default-fallback behavior and metadataOnly semantics. The description adds workflow context (recursive expansion, cost implications) but no new parameter-level meaning, so baseline 3 is appropriate.

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 names a specific verb and resource: it returns an ego-centric supply-chain view anchored at a node ('返回以某个节点为锚的自我中心视图'), and lists concrete user questions it answers. It also differentiates itself by naming sibling tools like list_chain_group_members and set_my_chain_position for follow-up actions.

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

Usage Guidelines5/5

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

A dedicated 【何时用】 section states the exact questions this tool answers, and the workflow guidance explicitly tells when to use metadataOnly=true to probe before switching to list_chain_group_members to inspect members. It also gives exclusions: don't iterate to the end, don't re-call the same anchor, and don't start conversations with unclaimed members.

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.

TDQS

A4.1/5.0
Disambiguation4/5

Each tool has a clearly documented purpose, often with explicit 'when to use' guidance and cross-references, making the vast majority easy to tell apart. A few clusters (get_my_brief, get_my_positioning, get_my_work, get_my_dispatch) and data-overlapping get_my_card vs get_my_profile require careful reading, but descriptions are detailed enough to prevent serious misselection.

Naming Consistency4/5

The overwhelming majority follow snake_case verb_noun conventions (create_product, update_need, list_my_signups). Minor deviations include noun-only feed names (personalized_feed, random_feed), inconsistency between 'prefs' and 'preferences' in notification tools, and a mix of update_* and set_* for mutations, but the pattern remains predictable overall.

Tool Count1/5

137 tools is an extreme mismatch for any MCP server, far exceeding the 50+ threshold for a score of 1. Even with a broad multi-domain platform, this volume makes tool selection and navigation impractical and heavily burdens the agent's context window.

Completeness5/5

The surface covers full lifecycles for needs, products, activities/signups, conversations, collaboration goals/tasks, dispatch, profile/onboarding, and supporting resources like companies, parks, policies, and ratings. Deliberate omissions (no user-post creation, no organizer profile editing via agent) are explicitly documented, so core workflows have no obvious dead ends.

Resources