Retrieve the plaintext value of a stored credential field when the raw secret is required. This audited action is disabled by default; use short-lived tokens for routine access.
读取凭据的原始密钥明文（危险操作，每次调用都计入审计日志）。默认禁用——需要用户在插件设置中开启 allowReveal。优先使用 get_token 获取临时令牌而非读取原始密钥。
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| field | Yes | 字段名，如 password / apiKey | |
| purpose | Yes |
Changes observed during successful MCP inspections.
v0.2.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does so exceptionally: it flags the operation as dangerous, states that every call is audit-logged, and discloses it is disabled by default with a required setting. This goes beyond a typical mutation warning and gives the agent actionable safety context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences front-load the danger and audit behavior, then state the enablement requirement and the alternative tool. Every clause earns its place with no filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers safety, enablement, and tool selection well, but leaves gaps for a dangerous no-annotation tool: it does not describe the return value (the plaintext secret), what name precisely identifies, or what purpose is expected for the audit log. Given the high risk and low schema coverage, more operational detail would be needed for fully confident invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers only one of three parameters (field), and the description adds no parameter-specific meaning for name or purpose. It does not clarify what name refers to or what should be supplied for purpose, leaving the agent to infer from sibling context. With 33% coverage, the description should compensate but does not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: reading the raw plaintext of credential secrets. It explicitly contrasts with get_token, distinguishing this tool from the closest sibling and making its unique role clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides explicit when-not-to-use guidance by stating that get_token should be preferred for temporary tokens, and it gives a prerequisite condition: the allowReveal setting must be enabled. This leaves no ambiguity about when the tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.