对一项决定做「魔鬼代言人」反方质检：返回最强反对论点、3 条风险、一个尖锐反问。用于 AI 在重大决策前自查漏洞。crypto 付费模式下需先付 USDT 并带 tx_hash。
| Name | Required | Description | Default |
|---|---|---|---|
| caller | No | 调用方 agent 标识（可选） | |
| tx_hash | No | crypto 模式下必填：先付 USDT(TRC20) 的交易哈希 | |
| decision | Yes | 要被质检的决定，如『辞掉工作做一人公司』 |
Changes observed during successful MCP inspections. Dates show when Glama detected each change.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the paid crypto requirement ('crypto 付费模式下需先付 USDT 并带 tx_hash'), which is a critical behavioral trait. It also implies a multi-step process (pay first, then provide tx_hash). However, it doesn't mention what happens if tx_hash is missing or invalid.
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?
The description is front-loaded with the core function and outputs, then adds usage and payment context. Every sentence carries distinct information without redundancy. It is economical yet complete.
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?
Given the complexity (crypto payment layer, 3 parameters, no output schema), the description does a good job covering the main points. It could add a note about fallback if tx_hash is omitted, but since the schema makes it optional, the description correctly flags it as conditionally required.
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?
Schema description coverage is 100%, so baseline is 3. The description adds value by explaining that 'tx_hash' is required specifically in crypto mode ('crypto 模式下必填'), which is not fully captured in the schema's generic description. It also gives a concrete example for 'decision' ('如『辞掉工作做一人公司』').
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 uses a specific verb ('做反方质检') and resource ('决定'), and clearly differentiates itself as a '魔鬼代言人' (devil's advocate) tool. It also lists concrete outputs: 最强反对论点, 3 条风险, 一个尖锐反问, 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool: '用于 AI 在重大决策前自查漏洞' (for AI to self-check flaws before major decisions). It does not provide explicit exclusions or alternatives (sibling tools are null), but the usage context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Only one tool exists, so there is no need for disambiguation. However, a single tool means no distinctions are possible, which prevents any choice among tools.
The single tool name 'decision_qc' uses a lowercase, snake_case format, which is consistent and readable. However, with only one tool, the concept of naming consistency across a set is not truly tested—it is neither inconsistent nor clearly patterned.
A single tool for a 'Devil's Advocate' service seems overly thin. While one endpoint could be sufficient for a simple adversarial check, the scope implies multiple possible operations (e.g., evaluate, review risks, ask questions), making one tool feel insufficient.
The tool only provides a single adversarial analysis output. Missing basic lifecycle steps such as browsing past decisions, customizing analysis depth, or iterating on feedback—gaps that likely limit agent effectiveness for thorough decision validation.