get_my_profile【需要登录】返回当前用户的完整资料：昵称 / 简介 / 介绍 / 所在地 / 全部链接（含 friends/private 等所有可见范围）/ 身份 persona。
【何时用】agent 要帮用户「把资料填到别的平台」「检查我留了哪些联系方式」「改我的链接」之前，先用它把现状读出来。比 get_creator 多了私有链接和 persona（get_creator 是公开视角，只吐 public）。
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Changes observed during successful MCP inspections. Dates show when Glama detected each change.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
注解已声明 readOnlyHint、openWorldHint、idempotentHint，描述在此基础上补充了“需要登录”这一认证前提，并说明返回内容包含私有链接和 persona，这些是对注解之外有意义的行为披露。没有与注解矛盾之处。
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?
描述分为“功能说明”和“何时使用”两部分，每句话都有实际价值。需要登录、返回内容、使用场景和与替代工具的对比均在一段简洁文字中完整呈现，没有冗余。
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?
该工具无参数，注解已覆盖只读、幂等、非破坏性等安全属性，描述则补充了认证要求和返回数据的详细范围，并给出了与 get_creator 的对比。在无输出 schema 的情况下，描述列出的字段类别足以让 agent 理解调用结果。
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 为空，描述不需要解释参数。描述通过列出返回资料的字段类别，补充了输入 schema 无法提供的语义信息，符合 0 参数场景的基线水平。
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?
描述以具体动词“返回”明确说明该工具的功能是获取当前用户的完整资料，并列出昵称、简介、介绍、所在地、链接和 persona 等具体内容。它明确区分了与 get_creator 的差异（get_creator 仅公开视角），使 agent 能清楚识别此工具用途。
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?
描述明确给出使用场景：在帮助用户填写资料到其他平台、检查联系方式、修改链接之前，先读取此工具的数据。还明确指出当需要公开视角时应选用 get_creator，提供了替代工具的选择依据。
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.
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.
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.
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.
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.