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

With no annotations provided, the description fully carries the behavioral disclosure burden. It transparently states that outputs are Ed25519-signed raw observations, facts only, method disclosed per field, and that it never asserts 'legit' or 'scam'. Also discloses the cost ($0.25 USDC, tier: premium) and the integrity guarantee via signature. This is exemplary transparency for a tool of this nature.

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 concise, front-loaded, and every sentence earns its place. It conveys purpose, input, output, behavioral constraints, and pricing in three tightly packed sentences. The parenthetical pricing at the end is a nice touch. No fluff or redundancy.

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?

Despite having no output schema, the description fully explains what the tool returns: domain registration age, registrar, TLS cert age/issuer, reachability, off-domain redirects, brand similarity score, lookalike tokens, and observed price vs expected. It also explains the signature's purpose and the tool's stance. It covers usage context, limitations, and cost, making it complete for a complex tool with no annotations.

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 input schema already provides 100% description coverage for all four parameters. The description adds semantic value by explaining the optional brand enables brand-similarity observation and expected_price enables price deviation reporting. It does not explicitly mention product_url, but the schema covers it. This extra context justifies a 4, slightly above baseline 3.

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 opens with 'Pre-checkout merchant fact oracle', a specific verb+resource that clearly conveys the tool's role. It then enumerates precise observation types (domain registration age, TLS cert age, brand similarity, price deviation) which distinguishes it from siblings like onyx_retail_price_check or onyx_agent_verify. The 'never asserts legit/scam' clarification further sharpens its unique positioning.

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 gives clear context by specifying 'pre-checkout' and explaining optional inputs (brand, expected price) that enable certain observations. It does not explicitly name alternatives or exclusions ('use this instead of...'), but the detailed scope and mention of what it returns imply its appropriate use. Lacks explicit when-not-to-use guidance, hence 4 rather than 5.

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