Skip to main content
Glama

独行录 / opcmenu

改这场的报名配置

update_organizer_signup_config
Idempotent

【需要登录】【何时用】用户要改报名表的题目、换报名类目、贴外部表单地址、换答疑群二维码时调它。立即生效,不留灰度闸

【组合链】get_organizer_activity(slug) 读现值 → 本工具传要改的那几项(缺省即不动)→ 再读一次确认。改完可以把 signupPageUrl 发给用户去转发。

【口径/坑】① 本工具改不了报名截止时间——截止在活动本体上,改它走 update_activity。而且:「截止绝不能提前封口」是这个产品的红线,把截止改早会把此刻正在填表的人当场挡在外面,任何「提前收口」的请求都必须先跟用户确认清楚后果。② formSchema 是整表覆盖,不是打补丁:传了就以你这份为准,漏写的题会被删掉(而且进「不再学习」名单,客户端以后也不会把它学回来)。稳妥做法是先 get_organizer_activity 拿到现有 formSchema,改完整份传回来。③ hostedEnabled=true 而一道题都不给时,服务层会落基线四项(姓名/手机号/微信号/项目介绍),不会留一张空表。④ 投递通道(adapterKey/deliveryMode)是平台侧基建,主办方改不了,也不该改。⑤ 改 signupUrl 会让投递方式跟着重算(有外链→用户设备代填投递;纯托管→站内收)。

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
kindNo报名类目。取值:HACKATHON(黑客松) | COMPETITION(创业赛事) | INCUBATOR(孵化营) | FUNDING(融资申请) | COMMUNITY(社区入驻) | EVENT(活动报名) | OTHER(其他)
signupUrlNo外部报名表单地址;传 null 清空(改回站内收报名)
formSchemaNo**整表覆盖**的题目表。不传=不动;传了就以这份为全集,漏写的题会被删掉。沿用现有题请把 get_organizer_activity 给你的那一项**原样带回来**(尤其 sensitive / sourceLabel 两个键,丢了会把加密题降级成明文、并让外部表单的自动填写失效)
activityRefYes活动 slug 或活动 id
articleUrlsNo活动图文/推文链接(整体覆盖)
contactNoteNo报名成功页的一句话说明;传 null 清空
contactQrUrlNo报名成功页的答疑/组队群二维码图 URL;传 null 清空
hostedEnabledNo站内是否直接收报名

Schema Changelog

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

  1. First observed

TDQS

A4/5.0
Behavior1/5

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

The description adds genuinely rich behavioral context: immediate effect with no gray release, whole-table formSchema overwrite, omitted fields being deleted and entering a 'no longer learn' list, signupUrl triggering delivery-mode recalculation, and the deadline red line. However, it directly contradicts the destructiveHint=false annotation by documenting that omitted formSchema fields are deleted permanently. Per the rubric, this contradiction forces a score of 1.

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 tightly organized into 'when to use', 'combination chain', and 'pitfalls/quirks'. Each bullet is actionable and earns its place; the length is justified by the high-risk overwrite semantics and an 8-parameter configuration surface.

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?

It covers auth requirement, when to use vs. alternatives, pre-read guidance, destructive overwrite risks, and platform-side constraints. The main gap is that with no output schema, it does not explicitly state what the tool returns; the 'read again to confirm' chain partially compensates by implying the return is not a full config snapshot.

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?

Schema description coverage is 100%, so the baseline is 3. The description adds meaningful semantics beyond the schema: formSchema is whole-table overwrite with sensitive/sourceLabel preservation risks, signupUrl changes cause delivery-mode recomputation, hostedEnabled with zero questions falls back to four baseline fields, and deadline is explicitly out of scope. This is more than the schema alone provides.

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 with a concrete list of user intents: changing signup form questions, signup category, external form URL, or FAQ group QR code. It clearly identifies the resource (signup config for an organizer activity) and distinguishes this tool from update_activity by explicitly saying deadline changes go there.

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 explicitly states when to use the tool ('何时用'), names update_activity as the alternative for deadline changes, and gives a recommended combination chain: read current config, pass only the changed fields, then re-read to confirm. This is excellent routing guidance with no ambiguity.

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