Skip to main content
Glama

独行录 / opcmenu

by io.github.yzlee
OverviewDiscussionsAdmin

给定位任务打勾（线下动作自报，可一次一批）

mark_positioning_task
Idempotent

【需要登录】【何时用】用户完成了平台观测不到的线下动作：注册了公司、拿到商标 / 软著 / ICP 备案、收到第一笔钱、开始盈利……由他自报，平台不审核（可以顺手把备案号/注册号填进 note）。一句话报了好几件就一次全传进来——「公司注册了、商标软著都下来了、备案也过了」是 tasks 里四条，不是调四次。

【组合链】打完返回体自带一份合并的涨分回执（前后总分与段位、本次新完成了哪些、「证照与备案」这一组的进度）——只念一遍，别每条都念一遍涨分话术，也别再调 get_my_positioning 前后各拉一次自己减。段位变了就顺势给下一步：nextUp[].suggestedTool 直接接着做。

【口径/坑】 · 只有 manual 类任务能打勾，auto 类（发产品、聊过多少人、发过几条需求）是平台记录算出来的，打不了勾——那不是 bug，是防止分数变成自助填空。 · 合法 taskKey（从服务层的 manual 任务集合生成）：build.company（公司注册） | build.trademark（商标注册） | build.copyright（软件著作权登记） | build.copyright_ec（电子软著（电子证书）） | build.icp（ICP 备案） | build.police（公安备案） | build.app_filing（App 备案） | build.mp_filing（小程序备案） | build.llm_filing（大模型 / 算法备案） | build.security_assessment（互联网信息服务安全评估） | build.patent（专利申请） | revenue.first_pay（拿到第一笔收入） | revenue.repeat（有第二个不认识的付费客户） | profit.covered（收入覆盖成本） | seed.cap_table（理清股权结构，留好期权池） | seed.one_bet（定下种子钱要验证的那一件事） | angel.investor_update（每月给投资人发一封进展简报） | angel.next_round_bp（按下一轮的标准重写 BP） | series_a.finance（财务规范化：月度报表 + 年度审计） | series_a.playbook（把获客打法写成可复制的手册） | series_b.second_engine（打开第二个市场或第二条产品线） | series_b.board（建立董事会和季度汇报机制） | series_c.strategic_deal（谈成一笔战略合作或并购） | series_c.data_compliance（做一次数据安全与合规体检） | series_d_plus.listing_team（选定上市地，组建中介团队） | series_d_plus.pay_forward（投一个早期项目，或带一位新 OPC） | growth.ad_basics（学会：一条广告只干一件事） · done=false 是取消打勾（连 note 一起删）。同一个 key 在数组里重复出现取最后一条。 · 一批是串行写的：中途失败会返回已经写成功的那几条 + 还没写的，照着补发剩下的，别整批重来。

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
tasksYes要打勾/取消的任务，一次最多 27 条（= manual 任务总数）。只报了一件就传一条

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • changedInput schema / properties / tasks / description
      Previous value: -"要打勾/取消的任务，一次最多 15 条（= manual 任务总数）。只报了一件就传一条"New value: +"要打勾/取消的任务，一次最多 27 条（= manual 任务总数）。只报了一件就传一条"
    • changedInput schema / properties / tasks / items / properties / taskKey / description
      Previous value: -"要打勾的任务 key。合法值：build.company（公司注册） | build.trademark（商标注册） | build.copyright（软件著作权登记） | build.copyright_ec（电子软著（电子证书）） | build.icp（ICP 备案） | build.police（公安备案） | build.app_filing（App 备案） | build.mp_filing（小程序备案） | build.llm_filing（大模型 / 算法备案） | build.security_assessment（互联网信息服务安全评估） | build.patent（专利申请） | revenue.first_pay（拿到第一笔收入） | revenue.repeat（有第二个不认识的付费客户） | profit.covered（收入覆盖成本） | growth.ad_basics（学会：一条广告只干一件事）"New value: +"要打勾的任务 key。合法值：build.company（公司注册） | build.trademark（商标注册） | build.copyright（软件著作权登记） | build.copyright_ec（电子软著（电子证书）） | build.icp（ICP 备案） | build.police（公安备案） | build.app_filing（App 备案） | build.mp_filing（小程序备案） | build.llm_filing（大模型 / 算法备案） | build.security_assessment（互联网信息服务安全评估） | build.patent（专利申请） | revenue.first_pay（拿到第一笔收入） | revenue.repeat（有第二个不认识的付费客户） | profit.covered（收入覆盖成本） | seed.cap_table（理清股权结构，留好期权池） | seed.one_bet（定下种子钱要验证的那一件事） | angel.investor_update（每月给投资人发一封进展简报） | angel.next_round_bp（按下一轮的标准重写 BP） | series_a.finance（财务规范化：月度报表 + 年度审计） | series_a.playbook（把获客打法写成可复制的手册） | series_b.second_engine（打开第二个市场或第二条产品线） | series_b.board（建立董事会和季度汇报机制） | series_c.strategic_deal（谈成一笔战略合作或并购） | series_c.data_compliance（做一次数据安全与合规体检） | series_d_plus.listing_team（选定上市地，组建中介团队） | series_d_plus.pay_forward（投一个早期项目，或带一位新 OPC） | growth.ad_basics（学会：一条广告只干一件事）"
    • changedInput schema / properties / tasks / maxItems
      Previous value: -15New value: +27
  2. Changed5 schema fields changed
    • removedInput schema / properties / done
      Removed value: -{
-  "description": "true=打勾（默认），false=取消打勾",
-  "type": "boolean"
-}
    • removedInput schema / properties / note
      Removed value: -{
-  "description": "备忘，比如备案号 / 注册号，可选",
-  "maxLength": 200,
-  "type": "string"
-}
    • removedInput schema / properties / taskKey
      Removed value: -{
-  "description": "要打勾的任务 key。合法值：build.company（公司注册） | build.trademark（商标注册） | build.copyright（软件著作权登记） | build.copyright_ec（电子软著（电子证书）） | build.icp（ICP 备案） | build.police（公安备案） | build.app_filing（App 备案） | build.mp_filing（小程序备案） | build.llm_filing（大模型 / 算法备案） | build.security_assessment（互联网信息服务安全评估） | build.patent（专利申请） | revenue.first_pay（拿到第一笔收入） | revenue.repeat（有第二个不认识的付费客户） | profit.covered（收入覆盖成本） | growth.ad_basics（学会：一条广告只干一件事）",
-  "type": "string"
-}
    • addedInput schema / properties / tasks
      Added value: +{
+  "description": "要打勾/取消的任务，一次最多 15 条（= manual 任务总数）。只报了一件就传一条",
+  "items": {
+    "additionalProperties": false,
+    "properties": {
+      "done": {
+        "description": "true=打勾（默认），false=取消打勾",
+        "type": "boolean"
+      },
+      "note": {
+        "description": "备忘，比如备案号 / 注册号，可选",
+        "maxLength": 200,
+        "type": "string"
+      },
+      "taskKey": {
+        "description": "要打勾的任务 key。合法值：build.company（公司注册） | build.trademark（商标注册） | build.copyright（软件著作权登记） | build.copyright_ec（电子软著（电子证书）） | build.icp（ICP 备案） | build.police（公安备案） | build.app_filing（App 备案） | build.mp_filing（小程序备案） | build.llm_filing（大模型 / 算法备案） | build.security_assessment（互联网信息服务安全评估） | build.patent（专利申请） | revenue.first_pay（拿到第一笔收入） | revenue.repeat（有第二个不认识的付费客户） | profit.covered（收入覆盖成本） | growth.ad_basics（学会：一条广告只干一件事）",
+        "type": "string"
+      }
+    },
+    "required": [
+      "taskKey"
+    ],
+    "type": "object"
+  },
+  "maxItems": 15,
+  "minItems": 1,
+  "type": "array"
+}
    • changedInput schema / required
      Previous value: -[
-  "taskKey"
-]New value: +[
+  "tasks"
+]
  3. First observed

TDQS

A4.9/5.0
Behavior5/5

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

Beyond annotations (readOnlyHint=false, idempotentHint=true), the description discloses login requirement, no platform review, response shape (merged score receipt with nextUp), cancellation semantics (done=false deletes note), and partial-failure behavior for serial batch writes. This gives the agent operational expectations that the annotations alone do not cover, and nothing contradicts the annotations.

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 dense and clearly sectioned with front-loaded when-to-use guidance, then response-handling, then pitfalls. The main redundancy is that it repeats the full taskKey enumeration already present in the schema, which lengthens the description, though the structured headers keep it navigable.

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?

Given one parameter, no output schema, and the complexity of valid task keys and failure modes, the description is remarkably complete: it covers auth, batching limits, cancellation, partial failures, response receipt handling, and follow-up via nextUp. An agent has enough information to invoke correctly and adapt to the response, with no obvious missing operational detail.

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

Parameters5/5

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

Although schema coverage is 100%, the description adds real meaning to the tasks parameter: how to batch multiple self-reported actions, that duplicate keys take the last entry, that done=false cancels and deletes the note, and that a failed serial batch returns already-written plus remaining items. It also clarifies the note field's purpose (备案号/注册号) and reinforces legal taskKey constraints, going well beyond the bare schema.

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 opens by specifying the exact action — marking positioning tasks as done for offline self-reported actions — and explicitly contrasts with auto tasks ('只有 manual 类任务能打勾，auto 类...打不了勾'), which differentiates it from sibling task-status tools. The title is reinforced with concrete examples (company registration, trademark, ICP filing), so an agent can identify both the resource and the operation without opening the schema.

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 provides an explicit '何时用' section describing when the tool applies (platform-invisible offline actions, self-reported, no audit) and when it does not (auto tasks are platform-calculated). It also tells the agent not to call get_my_positioning before/after and how to handle multi-item reports in one batch ('一句话报了好几件就一次全传进来'), making routing and orchestration unambiguous.

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
Pay for results, not tokens.Fund a bounty. Let AI agents compete and collaborate to solve your problems.agentbounties.appAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources