xmr_tx_lookup
按 txid 查询【门罗币交易】:是否仍在内存池、是否已上链、所在区块高度与确认数、输入/输出数量、output indices。【何时用】判断“某笔 XMR 交易/原子交换是否已上链、是否超时未确认”。【不要用】比特币交易请用 btc_tx_lookup。
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| txid | Yes | 门罗币交易哈希(64 位十六进制) |
按 txid 查询【门罗币交易】:是否仍在内存池、是否已上链、所在区块高度与确认数、输入/输出数量、output indices。【何时用】判断“某笔 XMR 交易/原子交换是否已上链、是否超时未确认”。【不要用】比特币交易请用 btc_tx_lookup。
| Name | Required | Description | Default |
|---|---|---|---|
| txid | Yes | 门罗币交易哈希(64 位十六进制) |
Changes observed during successful MCP inspections.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral disclosure burden. It clearly states the returned information: mempool presence, on-chain status, block height, confirmations, input/output counts, and output indices. It omits explicit read-only/no-side-effect and rate-limit/permission details, a minor gap for a lookup tool.
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 Chinese description is compact and front-loaded: purpose first, then when to use, then when not to use. Bracketed sections aid scanning, and every sentence contributes useful routing or scope information.
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?
For a single-parameter lookup with no output schema, the description lists the main return fields and gives explicit usage boundaries and the alternative tool. Combined with the complete txid schema, an agent has enough context to call it correctly; missing edge-case notes are acceptable at this complexity.
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 has 100% description coverage for the single txid parameter, including the 64-hex pattern and its meaning. The description does not add format or semantic details beyond the schema, so the baseline score of 3 applies.
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?
States a specific verb and resource: query a Monero transaction by txid, and enumerates returned fields (mempool/on-chain status, block height, confirmations, input/output counts, output indices). It also explicitly excludes Bitcoin transactions, so an agent can distinguish it from the sibling btc_tx_lookup.
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?
Gives explicit when-to-use guidance (determine whether an XMR transaction/atomic swap is on-chain or timed out unconfirmed) and when-not-to-use guidance (Bitcoin transactions -> btc_tx_lookup). The alternative is named, satisfying the highest bar.
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.