A permitting app needs Claude to look up parcels reliably. Which tool design fits?
Select an answer to reveal the explanation.
Short Explanation
Give Claude a clean parcel-lookup tool—clear schema, honest errors—like labeling the drawers in the permit office.
Full Explanation
Reliable parcel lookup in a municipal permitting app depends on tools Claude can call predictably: a clear JSON schema for arguments such as parcel ID or address, plus error returns the model can interpret and recover from. That design lets Claude request structured lookups, handle not-found and validation failures, and avoid inventing assessor data. Exposing parcel search through a general web-search tool returning ranked summaries forces Claude to sift through irrelevant results and guess which summary matches the parcel, which is unreliable for exact permitting lookups and offers no structured error handling. Allowing Claude to query parcel tables directly with generated SQL per request risks malformed or unsafe queries, bypasses the controlled tool contract, and can return incomplete or incorrect parcels without structured error recovery. Providing parcel records as complete scanned document bundles for Claude to interpret on demand dumps unstructured images or PDFs into the conversation, making exact parcel data hard to extract and prone to misreading for permit decisions. Exam caveat: a good schema does not replace authoritative GIS sources—Claude must still call the tool rather than invent polygons or ownership from training knowledge. Operational check: invoke the parcel tool with a known-good ID, a malformed ID, and a missing ID; confirm typed successes and structured errors appear in the tool result, and that Claude’s follow-up turns branch correctly on those errors.