Skip to main content
Glama

独行录 / opcmenu

更新我的多角色画像

set_my_role_profile
Idempotent

【需要登录】【何时用】用户在对话里透露了角色信息就顺手写进去:在融资(轮次/金额/要求)、我是投资人(类型/关注轮次/单笔规模/赛道)、我代表机构(园区/赛事/企服,能给什么资源)、我是来找人的媒体/HR/采购/合作方、我还在上学、我的创业阶段变了。这些字段决定他出现在首页哪个 tab、被谁搜到。

【组合链】写完 fundraising.active=true → 他就进了 list_funding(side=project) 的池子,可以马上 list_funding(side=investor) 找对口的钱 → get_creator → start_conversation。写完 investor → 反过来出现在别人的 list_funding(side=investor) 里。venture.stage 改完 → get_my_positioning 会给出这一级的新任务清单。

【口径/坑】 · 本工具已做好逐字段合并:只传你确知的那几个字段即可,没传的老值原样保留。(服务层本身是「顶层键整体替换」,直传 fundraising:{round:"A"} 会把 amount/requirements/BP 一次抹掉——这里先读后并挡掉了这个坑。) · 想清空某个字段:传空字符串或跟用户确认后整棵子树重传,不要靠不传来清空。 · venture.stage 走特殊路径:它同时是定位栏的主线阶段,本工具会调专门的写入口(传 null = 撤销自报,系统当场重判一次并把判词带回来)。取值:idea(找想法) | build(开发产品) | launch(产品上线) | revenue(有收入) | profit(有盈利)。 · 主办方资料(orgName/联系人/联系电话)不在这里,本工具写不了也不该写:那是唯一一条带短信验证码的通道,绕过它就是让 agent 能冒名办活动。用户要改主办方资料,请他去 App 里改。 · 自由文本会出现在公开卡片上(等同 UGC 广播面),过敏感词闸,命中报 content_rejected。 · 返回的是变更回执:哪几棵子树被合并了、合并前后各是什么。念给用户听,别只说「已更新」。

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
orgNo机构身份。type 必须有(新建时必给):park(园区) | competition(赛事主办) | service(企业服务);resources 是**字符串数组**(工位/注册地址/政策补贴/算力…),不是一段话
seekerNo来找主理人的那批人:kind = media(媒体) | recruiter(招人) | buyer(采购) | partner(找合作) | other(其它);lookingFor 想找什么、purpose 办成什么事、org 所属机构名(≠自有公司)、timeline 什么时候要
ventureNo创业阶段(同时就是定位栏主线阶段,走专门的写入口)
aspiringNo在校/待入行:education 一句话经历、weeklyHours 每周可投入、gigWilling 愿不愿先接活
investorNo投资人身份。type 必须有(新建时必给):individual(个人投资人) | corporate(产业投资) | institution(投资机构);rounds/sectors 是字符串数组
fundraisingNo融资情况。active=是否在融资(新建这棵子树时必须给);round/amount/requirements 都是自由文本;bpUrl 是已上传的 BP 文件地址
needsOfficeNo主理人:需要办公/注册地址
needsGigHelpNo主理人:需要兼职帮手

Schema Changelog

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

  1. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Beyond the annotations, it discloses login requirement, field-level merge semantics (read-then-write prevents clobbering), how to clear fields, the special venture.stage path and null behavior, sensitive-word gate with content_rejected, and the change receipt returned. None of this is visible in annotations or schema, and it substantially reduces surprise for a mutating tool.

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

Conciseness4/5

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

The description is long, but it is front-loaded with the 'when to use' section and organized into labeled blocks. Each dense caveat (merge, clearing, venture special path, organizer exclusion, content gate, receipt) earns its place for a tool with 8 nested parameter objects and no output schema; a little redundancy with schema enum lists is the only cost.

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?

For a complex multi-subtree mutation with zero required parameters, no output schema, and several non-obvious behaviors, the description covers the essential operating contract: prerequisites, semantics, error on content rejection, return value and how to present it, and exclusions. An agent has enough to call it correctly and explain the result to the user.

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. The description adds meaning on top: which subtrees map to which role, that fundraising.active=true puts the user into list_funding matching, and that venture.stage null means 'withdraw self-report and trigger system re-judgment'. This is genuinely useful semantics not inferable from the schema alone.

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 concrete action — update the user's multi-role profile — and enumerates the exact role fields it covers (fundraising, investor, org representative, seeker, student, venture stage) plus the effect on tabs and search visibility. This is specific enough to distinguish it from siblings like update_my_profile or set_persona without opening schemas.

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?

It gives an explicit trigger ('when the user reveals role info in conversation, write it in'), enumerates the role scenarios, and states a hard exclusion: organizer data is not writable here because it belongs to the SMS-verified channel. The combination-chain section even shows what to call after writing fundraising or investor state, which is more than enough routing guidance.

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