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

Adds substantive behavior beyond the annotations: email matching to an existing person or person creation, downstream agency automations that may email or assign the lead, and a duplicate-prevention mechanism via enquiry_identifier on retry. These are real side effects an agent must know about and are not derivable from the annotation flags.

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?

Front-loaded with the write mode and purpose, then the constraint sentence, then the retry rule, ending with the HTTP endpoint. Four sentences, each carrying distinct information, no repetition of schema text.

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 16-parameter write tool with no output schema, the description covers the critical decision rules and side effects. It stops short of saying what the call returns on success (presumably an enquiry id), which would help an agent chain into street_get_enquiry or follow-up calls.

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, but the description adds the crucial exclusivity rule across property_id / sales_applicant_id / lettings_applicant_id that the schema does not encode (no oneOf/anyOf present). It also explains the semantics of enquiry_identifier as a idempotency key rather than just an id field.

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?

Opens with an explicit mode marker and specific verb+resource: "WRITE: record a new inbound enquiry (a lead) in Street." This clearly separates it from the read-side siblings (street_get_enquiry, street_list_enquiries) and from the other create_* tools by naming the resource precisely.

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?

Gives a hard usage constraint that no sibling offers: the enquiry must be tied to exactly one of property_id / sales_applicant_id / lettings_applicant_id. It also states the retry protocol with enquiry_identifier. It does not explicitly say when to prefer this over, say, street_create_follow_up or street_create_note, but the resource naming makes that inferable.

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