Skip to main content
Glama

独行录 / opcmenu

起跑或急停邀请计划

set_guest_invite_plan_status
DestructiveIdempotent

【需要登录·主办方】【何时用】start 起跑、pause 急停。用户说「人齐了别再邀了」时当场按停,不用他去翻 App。 【组合链】get_activity_invites 看候选够不够 → 本工具 start → 随时 pause。 【口径】① start 之后系统会按 intervalMinutes 自动把邀请私信逐个发给候选,起跑前必须把名单念给用户确认;② SPEAKER 候选还在生成、或一个在册候选都没有时 start 会被拒,先 add_guest_candidates;③ 活动没发布或已开场都起不来。

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
roleYes
actionYes
activityRefYes活动 slug 或 id(list_my_activities / get_organizer_activity 的返回里都有)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=false, openWorldHint=true, idempotentHint=true, destructiveHint=true. The description adds meaningful context: after start, the system automatically sends invites one by one per intervalMinutes; start is rejected if SPEAKER candidates are still generating or no registered candidates exist; activity must be published and not started. It also notes login and organizer role required. No contradiction with annotations, and it enriches the agent's understanding of side effects.

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 structured with labeled sections (【需要登录·主办方】【何时用】【组合链】【口径】) that front-load the most critical information: authentication/role, when to use, sequence, and detailed conditions. Every sentence delivers value with no redundancy or fluff, making it easy for an agent to scan and act.

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?

The description covers authentication, when to use, prerequisites, failure conditions, and post-start behavior (automatic invites). It does not explicitly state what happens if the plan is already in the requested state, but the idempotentHint annotation covers that. It also omits mention of setting the plan first (via set_guest_invite_plan), but the chain references get_activity_invites and add_guest_candidates, which is sufficient for invocation. Overall, it is complete enough for correct usage.

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 description coverage is only 33% (activityRef has a description, role and action only have enums). The description clarifies the action semantics (start/pause) and mentions SPEAKER in the rejection condition, giving partial context for role. However, it does not explain the distinction between SPEAKER and ATTENDEE for this tool, nor does it elaborate on activityRef beyond the schema. It partially compensates for low coverage but leaves some ambiguity.

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 verb+resource: 'start 起跑、pause 急停' (start or emergency stop the invite plan), and explicitly distinguishes itself from related tools by naming get_activity_invites and add_guest_candidates in the chain. It also provides the exact user trigger ('人齐了别再邀了') for pause, making the purpose unmistakable.

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 explicit when-to-use conditions (start when ready, pause when user says stop) and the '【组合链】' section specifies the sequence with get_activity_invites and add_guest_candidates. It also states rejection conditions (no candidates, activity not published) and directs to add_guest_candidates in that case, fully guiding selection among siblings.

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.

Resources