Skip to main content
Glama

独行录 / opcmenu

处置一个报名者

review_signup_submission
Idempotent

【需要登录】【何时用】用户对某一个人下结论(入围/候补/未通过)时调它。处置结果报名者在「我的报名」里看得见,reviewNote 是直接给他看的一句话。

【组合链】list_signup_submissions 定位 → get_signup_submission 看清这个人 → 本工具处置。一次要处置很多人用 bulk_review_signup_submissions(那边有 preview 可以先过目)。

【口径/坑】① 执行前把「谁 → 改成什么」念给用户确认——报名者那头会看到。② reviewNote 缺省=不动之前写的留言,传空串会清空它。③ 只动报名结果,不碰投递状态(那是「有没有投到源表单」,两码事)。④ 取值:PENDING(待初审) | REVIEWING(初审中) | SHORTLISTED(已入围) | WAITLIST(候补) | REJECTED(未通过) | WITHDRAWN(已撤回)。

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
slugYes活动 slug
reviewNoteNo给报名者看的一句话(如「初审通过,请在 9 月上旬填入围确认表」)。不传=不动之前的留言;传空串=清空它
reviewStatusYes报名结果。取值:PENDING(待初审) | REVIEWING(初审中) | SHORTLISTED(已入围) | WAITLIST(候补) | REJECTED(未通过) | WITHDRAWN(已撤回)
submissionIdYes报名单 id

Schema Changelog

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

  1. First observed

TDQS

A4.7/5.0
Behavior5/5

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

Annotations already mark this as read-write, non-destructive, and idempotent. The description adds essential behavioral detail: login is required, the outcome is visible to the applicant in 'My Applications', reviewNote is shown directly to the applicant, and the default vs empty-string behavior for reviewNote is clarified. No contradiction with annotations.

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?

Well structured into labeled sections (需要登录/何时用/组合链/口径/坑) with bolded key warnings and a numbered list. It is dense but every sentence carries high-value information, and the most important scoping and side-effect details 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?

Even without an output schema, the description covers the login requirement, exact trigger condition, routing among sibling tools, the visible side effect to the applicant, all enum values, reviewNote semantics, and the boundary vs delivery status. Nothing an agent needs to select or invoke this tool correctly is missing.

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 100%, so all four parameters, the enum labels, and the reviewNote default/clear semantics are already documented in the schema. The description repeats this information rather than adding new parameter-level meaning. Baseline 3 applies due to full schema coverage.

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?

States a specific verb and resource: decide one applicant's review outcome (SHORTLISTED/WAITLIST/REJECTED, etc.) for a single signup submission. Explicitly distinguishes from bulk_review_signup_submissions and positions itself inside a list -> get -> review chain, so an agent can tell it apart from its siblings.

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?

Gives explicit when-to-use context ('when the user reaches a conclusion on one person'), a recommended combination chain (list_signup_submissions -> get_signup_submission -> this tool), and an explicit alternative for many people (bulk_review_signup_submissions with preview). Also states what the tool does NOT touch (delivery status).

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.

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