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 the tri-state outcome (allow/deny/indeterminate) and the rule that denials are immutable to payment — genuine behavioral facts not available in structured fields. It omits whether the call is read-only, latency, error behavior, and what 'indeterminate' means operationally, so the disclosure is partial.

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?

Two short sentences, front-loaded with the core question and the possible verdicts, with no filler. The closing sentence about payment is terse to the point of being under-contextualized, which slightly weakens the structure.

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 six-parameter decision tool with no annotations and no output schema, the description should explain the verdict semantics, the role of us_person and purpose, and at least the shape of the response. Instead it leaves half the inputs and the entire response contract unaddressed.

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 0% across six parameters, so the description must compensate and largely does not. It implies the roles of party_id, action, region, and passport_id, but says nothing about purpose or us_person, nor about identifier formats or expected string values.

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 concrete decision question (may a party do an action in a region under a passport policy) and names the three possible verdicts, which lets an agent recognize this as a policy-evaluation tool rather than a credential lookup. It does not explicitly contrast itself with siblings such as trust_check or verify_passport, so the differentiation is inferred rather than stated.

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?

There is no guidance on when to call this instead of trust_check, verify_passport, or verify_badge, nor any stated prerequisites (e.g., whether a passport must be verified first). The clause 'Payment cannot change a denial' hints at a payment-related scenario but is too cryptic to serve as routing guidance.

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