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

The description contradicts the annotation openWorldHint=false: the description explicitly states 'absence of evidence is UNKNOWN, never CONTRADICTED', which is open-world semantics, while the annotation declares closed-world behavior. This is a serious inconsistency that misleads an agent about how missing data is interpreted. Additionally, the description adds useful context about predicate scope, but the contradiction overrides that value.

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 compact, with the key verdict types front-loaded and the input format described in a single sentence. It avoids redundancy and fits the essential information into two sentences without fluff.

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?

The tool has no output schema, so the description must explain what the tool returns, but it only says 'with the observations' without describing the structure of those observations. It also leaves the dfx_id parameters unexplained and fails to reconcile the open/closed-world contradiction. For a verification tool with no output schema and low parameter coverage, this is incomplete.

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 only 29% (2 of 7 parameters have descriptions). The description mentions 'structured subject / predicate / object / year', which maps to the claim, subject, predicate, object, and year fields, adding some meaning. However, it does not explain how to format the dfx_id parameters or how they relate to the structured fields, leaving most parameters under-documented despite the low schema coverage.

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 states a clear verb (check/verify) and resource (a claim against DFX's evidence), and enumerates the four possible verdicts. It is distinct from the many get/search siblings, which retrieve data rather than evaluate claims, so the purpose is unambiguous.

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?

It gives some scoping context by listing the predicate categories covered and explicitly excluding property facts, which helps an agent know what it can verify. However, it does not explicitly say when to prefer this over a search_* or get_* tool, nor does it contrast with siblings like explain_match or what_can_dfx_answer. Usage guidance is implied rather than explicit.

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