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

With no annotations, the description carries the full burden, and it does disclose meaningful behavioral traits: unsure answers are never resolved in the direction that manufactures an obligation, and the model can conclude that nothing binds the asker. It also sketches the return content ('which obligations reach it, which do not, and why'). It does not cover authorization needs, limits, or the result's authoritative/legal status.

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 sentences, front-loaded with the core action, and each sentence adds something distinct: what it does, how to answer, and the consequence of uncertainty. No filler.

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 an 8-parameter, fully documented, all-optional tool with no output schema, the description adequately covers purpose, input discipline, and the shape of the result. It stops short of describing how to read or act on the output, which is the main remaining gap given there is no output schema to lean on.

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 100% and every parameter is an enumerated yes/no/unsure with its own explanatory text, so the schema does the heavy lifting. The description adds only the cross-cutting note that every input accepts 'unsure', which is already visible in the enums. Baseline 3 is appropriate.

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 specific verb and resource: it runs Lunara's published applicability model against a described deployment and returns which obligations reach it. It is distinguishable from the sibling lunara_obligations by being the assessment step rather than the obligation listing, though it never names or contrasts with any sibling explicitly.

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 clear guidance on how to supply answers ('answer only what you actually know', every input accepts 'unsure'), but that is input-completion guidance rather than when-to-use-this-vs-alternatives guidance. There is no statement of when an agent should call this instead of lunara_obligations, lunara_verify or lunara_integrity.

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