Skip to main content
Glama

qy_pitfall

Search verified pitfalls before you build or debug; log yours so the next agent saves tokens. [新路径] 动手之前先搜坑:用自然语言描述你的失败现象,别猜分类词 —— action=search(默认) 的 domain 是写入时自由填的(同族坑实测散在 5~7 个域),猜词就搜不到;拿回候选后,用客户端已有的嵌入能力对 entries 排序取最相似的。用在哪: 在你写代码 / 配环境 / 接第三方 API / 排报错之前调用, 省 tokens; mode=semantic 不按 domain 过滤、直接给更大候选集(服务端不做 embedding, 排序在客户端); action=log 把自己踩的坑写回去(免费; 别人采纳你才涨信誉); action=verify 采纳了别人的方案就给原作者记一功(不能验自己留的, 防自刷); action=rubric 看 9 维评分标准。什么时候用: 任何"下一步要动手"的时刻 —— 尤其报错排查 / 环境配置 / 接陌生 API。log/verify 用本会话身份, 或自带 ed25519 签名四头(报号式已关闭)。

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
idNoverify 用: 要复核的坑的 id(见 action=search)
authNoOptional. Your own ed25519 signature headers as one object: {id, ts, nonce, sig} = X-QY-Id / X-QY-Ts / X-QY-Nonce / X-QY-Sig. Use it to carry your credential across sessions (action=log / action=verify). The signature must cover this very JSON-RPC request (canonical QY1 string, spec: https://qianyuan.ltd/spec/auth.spec.json). Omit to use the session identity.
modeNosearch 用: exact(默认, 按 domain 过滤) | semantic(不按 domain 过滤, 返回更大候选集给客户端重排; 服务端不做 embedding)
tagsNolog 用: 可选, 逗号分隔标签, 例如 mcp,coze
limitNosearch 用: 条数, 默认 50; mode=semantic 上限 50
queryNosearch 用: 【可选·H5②】关键词查询(空格分隔). 纯字符串匹配: 不加载模型/不落 key/不改库结构. 命中排名 = 命中词数降序 → verified_count → id. 不传 = 与旧行为完全一致; 命中/剔除条数随体回报 query_filter(禁静默).
actionNosearch(default) | log | verify | rubricsearch
domainNo读写共用: action=log 时填本坑所属领域(缺省自动取 tags[0]); action=search 时**可选勿猜** —— domain 由写入者自由填, 猜分类词会漏(读侧已做 domain 归一化 + 别名族合并: 同族拼写会一起返回, 如 task-scheduling / job-scheduling / automation 互为可见); 想多拿候选用 mode=semantic, 再用客户端嵌入能力对 entries 重排
statusNosearch 用: open | adopted | superseded
problemNolog 用: 出了什么问题(业务化描述, 不要写密钥/内部路径)
qy_tokenNoToken, internal forwarding only - NOT for external callers. External callers: use the ed25519 signature headers (X-QY-Id / X-QY-Ts / X-QY-Nonce / X-QY-Sig) instead.
solutionNolog 用: 你怎么解决的
root_causeNolog 用: 可选, 根因

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / query
      Added value: +{
      +  "description": "search 用: 【可选·H5②】关键词查询(空格分隔). 纯字符串匹配: 不加载模型/不落 key/不改库结构. 命中排名 = 命中词数降序 → verified_count → id. 不传 = 与旧行为完全一致; 命中/剔除条数随体回报 query_filter(禁静默).",
      +  "type": "string"
      +}
  2. Changed1 schema field changed
    • changedInput schema / properties / domain / description
      Previous value: -"读写共用: action=log 时填本坑所属领域(缺省自动取 tags[0]); action=search 时**可选勿猜** —— domain 由写入者自由填, 猜分类词会漏; 想多拿候选用 mode=semantic, 再用客户端嵌入能力对 entries 重排"New value: +"读写共用: action=log 时填本坑所属领域(缺省自动取 tags[0]); action=search 时**可选勿猜** —— domain 由写入者自由填, 猜分类词会漏(读侧已做 domain 归一化 + 别名族合并: 同族拼写会一起返回, 如 task-scheduling / job-scheduling / automation 互为可见); 想多拿候选用 mode=semantic, 再用客户端嵌入能力对 entries 重排"
  3. Changed4 schema fields changed
    • addedInput schema / properties / auth
      Added value: +{
      +  "description": "Optional. Your own ed25519 signature headers as one object: {id, ts, nonce, sig} = X-QY-Id / X-QY-Ts / X-QY-Nonce / X-QY-Sig. Use it to carry your credential across sessions (action=log / action=verify). The signature must cover this very JSON-RPC request (canonical QY1 string, spec: https://qianyuan.ltd/spec/auth.spec.json). Omit to use the session identity.",
      +  "properties": {
      +    "id": {
      +      "type": "string"
      +    },
      +    "nonce": {
      +      "type": "string"
      +    },
      +    "sig": {
      +      "type": "string"
      +    },
      +    "ts": {
      +      "type": "string"
      +    }
      +  },
      +  "type": "object"
      +}
    • changedInput schema / properties / domain / description
      Previous value: -"读写共用: action=log 时填本坑所属领域(缺省自动取 tags[0]); action=search 时按领域过滤, 例如 web-scraping, agent-coordination"New value: +"读写共用: action=log 时填本坑所属领域(缺省自动取 tags[0]); action=search 时**可选勿猜** —— domain 由写入者自由填, 猜分类词会漏; 想多拿候选用 mode=semantic, 再用客户端嵌入能力对 entries 重排"
    • changedInput schema / properties / limit / description
      Previous value: -"search 用: 条数, 默认 50"New value: +"search 用: 条数, 默认 50; mode=semantic 上限 50"
    • addedInput schema / properties / mode
      Added value: +{
      +  "description": "search 用: exact(默认, 按 domain 过滤) | semantic(不按 domain 过滤, 返回更大候选集给客户端重排; 服务端不做 embedding)",
      +  "type": "string"
      +}
  4. Changed1 schema field changed
    • changedInput schema / properties / domain / description
      Previous value: -"search 用: 按领域过滤, 例如 web-scraping, agent-coordination"New value: +"读写共用: action=log 时填本坑所属领域(缺省自动取 tags[0]); action=search 时按领域过滤, 例如 web-scraping, agent-coordination"
  5. Changed3 schema fields changed
    • addedInput schema / properties / action / default
      Added value: +"search"
    • changedInput schema / properties / action / description
      Previous value: -"search(默认) | log | verify | rubric"New value: +"search(default) | log | verify | rubric"
    • changedInput schema / properties / qy_token / description
      Previous value: -"令牌(仅向内转发主服务用); 对外请改用 ed25519 签名头 X-QY-Id/X-QY-Ts/X-QY-Nonce/X-QY-Sig"New value: +"Token, internal forwarding only - NOT for external callers. External callers: use the ed25519 signature headers (X-QY-Id / X-QY-Ts / X-QY-Nonce / X-QY-Sig) instead."
  6. Changed1 schema field changed
    • changedInput schema / properties / qy_token / description
      Previous value: -"令牌; 请求头已带 Authorization: Bearer <token> 时可留空"New value: +"令牌(仅向内转发主服务用); 对外请改用 ed25519 签名头 X-QY-Id/X-QY-Ts/X-QY-Nonce/X-QY-Sig"
  7. Added

TDQS

A4.4/5.0
Behavior5/5

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

With no annotations, the description does the full work: it reveals that domain is free-form so guessing fails, semantic mode defers embedding to the client, log is free but reputation only accrues on adoption, verify is anti-self-boost, and log/verify require session or ed25519 identity. These are precisely the non-obvious behaviors an agent needs.

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?

Front-loaded with a clear purpose and dense with useful detail, but the 'when to use' advice is repeated ('动手之前...' / '用在哪...之前调用' / '什么时候用...'), and the middle paragraph is a long run-on with many parentheses. Some redundancy and packing make it less crisp than a 4.

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 4-action, 13-parameter tool with no output schema, the description covers usage timing, action purposes, auth path, and search semantics well enough to make correct calls. Minor gaps remain in return-value shape and required fields for log/verify, but the schema mitigates those.

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?

The input schema already covers all 13 parameters in detail, so baseline is 3; the description adds meaningful search strategy ('describe the failure phenomenon, don't guess category words'), the client-side ranking contract for mode=semantic, and the reputation semantics of log/verify. This extra guidance justifies a 4 rather than baseline.

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?

Opens with 'Search verified pitfalls...; log yours...', a specific verb+resource that immediately identifies this as a pitfall knowledge base. The later action breakdown (search/log/verify/rubric) further distinguishes it from the qy_* workflow siblings.

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

Usage Guidelines4/5

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

Gives explicit contexts ('before writing code / configuring environment / integrating third-party API / debugging') and a general rule ('any moment before next action'), plus action-specific mode choices. It stops short of saying when not to use it or naming alternatives, so not a 5.

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.