Skip to main content
Glama

独行录 / opcmenu

写我的自动开场语

set_my_chat_opener
Idempotent

【需要登录】确认后设置新会话自动开场语,非普通私信;只在新建时发送。禁止手机号/邮箱/QQ/微信/URL,chat_opener_has_contact或content_rejected勿重试;最多120字,超限chat_opener_too_long。写真事,勿编对方需求或自动发送提示;null/空白恢复默认。【组合链】get_my_card→set→get_my_chat_opener→start_conversation。

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
openerYes自定义开场语;传 null 或空串 = 恢复全站默认。最长 120 字

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Annotations already cover the safety profile (idempotentHint, non-destructive), but the description adds substantial context beyond them: login required, the effect is limited to new sessions and not retroactive, content-moderation failure modes with named error codes, non-retry guidance, and that null/blank restores the global default. This is exactly the behavioral detail annotations cannot express.

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

Conciseness4/5

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

It is dense but front-loads the most important gate (login required) and groups constraints, error codes, and the chain into distinct bracketed segments, so each clause carries actionable information. Slightly cluttered, but there is essentially no filler sentence.

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?

No output schema exists, but the description covers the mutation's scope (new sessions only), failure modes, content rules, and default-restore behavior, which is everything an agent needs to invoke it correctly. Given a single-parameter, non-destructive setter, nothing material 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 coverage is 100% and the single parameter already documents the 120-char max, null/blank default behavior, and anyOf typing. The description repeats the 120-character limit and the null/blank restore semantics rather than adding new meaning, so the baseline 3 for high-coverage schemas is appropriate.

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 (set the auto-opener for new sessions) and explicitly disambiguates it from what it is not: '非普通私信' (not a regular private message). It also distinguishes itself from the downstream start_conversation tool via the chain, so an agent can place it precisely among 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?

Provides explicit when (only fires on newly created sessions), when-not (do not retry on chat_opener_has_contact or content_rejected), and constraints (login required, banned contact types). The 【组合链】 line names the exact sequence get_my_card→set→get_my_chat_opener→start_conversation, giving concrete routing rather than inference.

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