اعتبارسنجی اطلاعات عمومی کیف‌پول

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

No annotations exist, so the description carries the full burden. It correctly narrows scope to format checking (not registration or validation on the TheyPaid side) and adds a safety constraint about never supplying a private key or recovery phrase. It does not state that the call is read-only/side-effect free, nor what the response or failure looks like.

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?

Three short sentences, front-loaded with what is checked, then the sibling routing, then the safety warning. Every sentence carries distinct information and none repeats structured fields.

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 two-parameter, read-only-implied validator with no annotations and no output schema, the description covers purpose, the key alternative, and the critical secret-handling rule. The remaining gap is what a successful versus failed validation yields, which an agent would otherwise have to discover by calling.

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 coverage is 0%, so the description must compensate. It usefully reveals that publicValue accepts either a public address or an xpub, which the bare string schema does not, and ties the value to a supported asset. It says nothing about the asset enum semantics or length/format constraints, leaving real gaps.

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 (checks/validates) and resource (public address or xpub format) scoped to a supported asset, and explicitly separates itself from theypaid_connect_wallet. An agent can tell it is a format pre-check, not an actual wallet connection, without reading any schema.

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?

Explicitly routes the agent to theypaid_connect_wallet when the goal is validating in TheyPaid and connecting to a store, which is a genuine alternative-selection rule. It stops short of spelling out the reverse case (e.g. that this tool is only the pre-check step), so it is strong but not exhaustive.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.