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

The description discloses far beyond the annotations: payment requirements, the 402 challenge flow, the free unsigned preview behavior, the NOT_DEPLOYED fallback, and the limitation that watermarks are UNCHECKABLE when no public detector exists. This gives an agent realistic expectations for success and failure modes, with no contradiction against the annotations.

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 dense and jargon-heavy, but each sentence carries a distinct operational fact: payment, detection scope, preview behavior, 402 handling, and deployment fallback. It is front-loaded with the PAID gate and avoids filler, though the opening endpoint URL could arguably be omitted without losing value.

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 complex paid tool with a 402 flow, the description covers the essential invocation behaviors: payment, free preview, unsigned output, and honest failure modes. An output schema exists, so return-value documentation is not required. The only notable gap is explicitly guiding which of url, bytes_b64, or manifest_b64 to provide, but the schema's 'Alternatively' labels already cover that distinction.

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 100%, so the baseline is 3. The description adds meaningful semantics for x_payment (it is the signed challenge response required to proceed) and preview (free and returns the same measurement unsigned), which are not fully captured by the schema field descriptions alone. Other parameters remain schema-level but are already well described there.

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 clearly identifies the resource (Article 50 marking-evidence pack) and the core operation: detecting whether a machine-readable mark is present in given bytes, along with Art 50(2) and Art 99(4) hashes. It is distinguishable by its explicit point-in-time detection scope, though it does not explicitly contrast itself with sibling tools like rwa_evidence or verify_inclusion.

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 strong usage context: the tool is paid, requires x402 or an invoice, preview=true provides a free unsigned path, and omitting x_payment triggers a 402 challenge. It also states what the tool will never do (conformity opinion/compliance word), but stops short of naming alternatives or saying 'use this when you need X instead of Y'.

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