Skip to main content
Glama
Sign In

独行录 / opcmenu

by io.github.yzlee
OverviewDiscussionsAdmin

我的定位（经营阶段、融资阶段与事项）

get_my_positioning

登录;读产品/经营、已完成融资两个独立阶段及有序stageGoals。默认AI判断，显式手选优先；融资不证明上线/收入/盈利。按原序展示目标名/一句话，peopleTool→find_positioning_task_people→get_creator→确认后start_conversation；进展report_positioning_task_outcome。手选set_my_role_profile(venture)，各维null恢复系统。刷新快照勿轮询。nextUp/persona/radar仅兼容，不作阶段事项；禁旧段位分数/AI陪练。历史正文includeGuides+1~5个taskKeys。

Input Schema

NameRequiredDescriptionDefault
taskKeysNo只看这几条任务（1~5 条；配合 includeGuides 取它们的培训正文）
includeGuidesNo是否带回培训正文 guide，默认 false。设 true 时必须同时给 taskKeys；正文只出现在返回体的 tasks[] 里，tracks 里不重复一份

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / includeGuides / description
      Previous value: -"是否带回培训正文 guide，默认 false。设 true 时**必须同时给 taskKeys**；正文只出现在返回体的 tasks[] 里，tracks 里不重复一份"New value: +"是否带回培训正文 guide，默认 false。设 true 时必须同时给 taskKeys；正文只出现在返回体的 tasks[] 里，tracks 里不重复一份"
  2. Changed3 schema fields changed
    • changedInput schema / properties / includeGuides / description
      Previous value: -"是否带回培训正文 guide，默认 false。设 true 时**必须同时给 taskKey**，且只返回那一条的正文"New value: +"是否带回培训正文 guide，默认 false。设 true 时**必须同时给 taskKeys**；正文只出现在返回体的 tasks[] 里，tracks 里不重复一份"
    • removedInput schema / properties / taskKey
      Removed value: -{
-  "description": "只看某一条任务（配合 includeGuides 取它的培训正文）",
-  "maxLength": 60,
-  "type": "string"
-}
    • addedInput schema / properties / taskKeys
      Added value: +{
+  "description": "只看这几条任务（1~5 条；配合 includeGuides 取它们的培训正文）",
+  "items": {
+    "maxLength": 60,
+    "type": "string"
+  },
+  "maxItems": 5,
+  "minItems": 1,
+  "type": "array"
+}
  3. First observed

TDQS

A4.2/5.0
Behavior5/5

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

Annotations only declare destructiveHint=false, while the description adds substantial behavior: login requirement, AI-vs-manual precedence, the rule that funding does not prove launch/revenue/profit, original-order display, no polling for snapshot refresh, and compatibility-only status for legacy fields. These are meaningful behavioral constraints beyond what the annotation supplies.

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 content is packed into a single semicolon-separated paragraph mixing purpose, workflow routing, output ordering, parameter guidance, and deprecation notes. The purpose is front-loaded, but the dense structure makes it harder to scan than necessary.

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?

For a two-parameter read tool with no output schema and minimal annotations, the description supplies return scope, ordering, compatibility caveats, and downstream workflow references. It is broadly complete, though it does not fully specify the returned object shape beyond the two stages and ordered goals.

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 coverage is 100%, so taskKeys and includeGuides are already fully documented, including the 1–5 taskKeys limit and the requirement to pair includeGuides with taskKeys. The final clause repeats the includeGuides+taskKeys pairing for historical main text without adding syntax, format, or return detail 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?

The clause "读产品/经营、已完成融资两个独立阶段及有序stageGoals" states a specific read operation and names the two independent stage dimensions plus ordered stage goals. It also distinguishes the tool from manual selection via set_my_role_profile and progress reporting via report_positioning_task_outcome, though the purpose is somewhat buried in a dense run-on.

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?

The description explicitly says default AI judgment applies but explicit manual selection takes precedence. It routes people exploration through find_positioning_task_people to get_creator to start_conversation, progress through report_positioning_task_outcome, and manual override through set_my_role_profile. It also excludes nextUp/persona/radar as stage items, providing strong when-not guidance.

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
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources