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

Beyond the annotations, the description discloses what the server actually does: validates the encrypted intent, current publication and immutable recipient, then atomically records one enquiry and one notification job. It also flags that contact details are unverified and that the tool cannot read existing enquiries or accounts. The retry clause is consistent with idempotentHint=true, and the write semantics match destructiveHint=false being absent, so nothing contradicts the structured metadata.

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?

Four sentences, front-loaded with the 'UI-only' constraint and the user-action precondition, then server behavior, then prohibitions. Every sentence carries content, though the middle validation sentence is dense enough to slow parsing.

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?

An output schema exists, so return values need not be explained, and the annotations already carry the safety profile; the description adds atomicity, validation and retry semantics on top. Remaining gaps are auth/identity model (a guest submission apparently needing no credentials) and any rate limiting, which matter for an agent deciding whether it may ever call this.

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%, so the description must compensate and it only partly does: it conveys 'at least one contact' (explaining why email and phone are individually nullable), that consent to sharing is required, and that the intent token is an encrypted, server-validated artifact tied to an immutable recipient. It says nothing about consentVersion, the preferredAt datetime semantics (explicitly not an appointment confirmation), or message length limits, leaving half the surface undocumented.

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 names a specific verb and resource (an inbound guest contact submission that records one native enquiry plus an owner-notification job), and the scope clause 'UI-only guest inbound' plus 'No access to existing enquiries or private accounts' separates it from read/list siblings. It does not name the sibling that mints the intent token, so the boundary with prepare_findestate_enquiry is only implied.

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?

When-to-use is stated as a precondition chain: only after the person reviews the exact property/recipient, supplies at least one contact, consents, and explicitly presses Send. When-not-to-use is also explicit ('never silently submit, change targets, reserve property or confirm an appointment'), and retry is constrained to reusing the identical intent and payload. The one gap is that the origin of the intent token is not routed to a named sibling tool.

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