Skip to main content
Glama

独行录 / opcmenu

by io.github.yzlee

用积分兑换今日 +1 次开场

redeem_chat_quota

【需要登录】【何时用】只在开聊额度用尽、用户明确要求今天就多聊一个人时。花 500 积分换今天 +1 次开场，每日限 1 次。这是应急安全阀，不是常规出口。

【必须先征得同意】agent 不许自动兑换。先把「这要花 500 积分」原话念给用户，拿到明确同意再调。撞额度墙时 start_conversation / contact_need 的失败返回体里已经带了这个出口和你的余额，照着念即可。

【组合链】兑换成功 → 立刻 start_conversation 把这一次用掉（额度只加今天，过夜作废）。不想花积分 → get_my_invite 走引荐（那是永久加额度，兑换只加一天）。

【口径/坑】 · 两种失败都是终态，绝不重试：409 insufficient_points（余额不够）/ 409 chat_quota_redeem_limit（今天已经兑换过了）。返回体里会带上当前额度和余额，直接转述。 · 如果你刚调过一次然后超时了，再调撞到 chat_quota_redeem_limit —— 那说明上一次其实成功了（每日上限靠全表唯一键原子兜底）。读返回体里的 quota 确认，不要当失败。 · 额度只拦「新开一个会话」；回复老会话、别人来找你都不受影响。 · 积分体系 2026-07-03 已从用户面下线，这是全站唯一一个还露在 agent 面的积分动作。别去找别的积分工具，没有。

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

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

  1. First observed

TDQS

A4.9/5.0
Behavior5/5

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

Beyond annotations, the description discloses login requirements, mandatory explicit user consent with a specified script, terminal 409 failure modes with no retry, the timeout ambiguity that may mean a previous call actually succeeded, same-day quota expiry, and the fact that points were decommissioned from the user side. Since there is no output schema, this context is essential and is fully supplied.

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

Conciseness5/5

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

The description is long but densely structured into labeled sections, each carrying safety-critical or operational information. Every sentence earns its place, and the most important gating conditions are front-loaded.

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?

With sparse annotations and no output schema, the description carries the full burden. It covers when to use, consent procedure, alternatives, failure/retry handling, side-effect scope, and system status. Nothing needed for correct invocation is missing.

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 has zero parameters, so the baseline is 4. The description adds fixed-cost and daily-limit context, but these are behavioral facts rather than parameter semantics; no additional compensation is required.

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 states a specific action with a concrete resource: spending 500 points to gain +1 chat opener for today. It clearly distinguishes this tool from start_conversation/contact_need and get_my_invite, positioning it as an emergency valve rather than a regular channel.

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 '何时用' section gives an explicit triggering condition: only when chat quota is exhausted and the user explicitly asks to chat with one more person today. It also names the alternative (get_my_invite for a permanent increase) and an exclusion ('不是常规出口').

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
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

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