Skip to main content
Glama

Search building inspections

search_inspections
Read-onlyIdempotent

Search inspection logs by place, permit, type, result and date. Summaries and future scheduled inspections are excluded by default; upcoming and summaries opt in. Sources report data_through. Coverage varies by source and place; an empty result does not establish that no record exists. Up to 25 results per call. total_capped marks a lower bound; total_unknown means the total is unknown. Pagination guidance is in _notes.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "search_inspections"
  }
}

Input Schema

NameRequiredDescriptionDefault
cityNoCity name (matches the address city or the issuing jurisdiction)
pageNoPage number, 1-based (default 1)
scopeNopermit (default): inspections of permitted work. existing / occupancy: occupancy inspections of existing buildings that no permit asked for; all.permit
startNoInstead of page: 1-based position of the first result to return, e.g. start=24 continues after result 23 (as named in `_notes`)
stateNo2-letter state code
tradeNo
parcelNoParcel / APN / folio (formatting ignored)
resultNoPASS, FAIL, PARTIAL, CANCELLED, SCHEDULED or OTHER
addressNoStreet address, partial, case-insensitive
per_pageNoResults per page (default 25, max 25)
upcomingNoFuture-dated (still scheduled) inspections: exclude (the default, except with result=SCHEDULED), include, or only (soonest first).
zip_codeNo5-digit ZIP
permit_idNoA permit id from /v1/permits
summariesNo'Last inspection' summaries copied from permit records (not inspection logs). Default exclude.exclude
date_afterNoinspection_date on or after (undated inspections never match)
final_onlyNoOnly final / certificate-of-occupancy inspections
date_beforeNoinspection_date on or before
permit_numberNoThe permit number, as the city publishes it or as /v1/permits returns it
inspection_typeNoNormalised inspection type, e.g. FRAMING, ROUGH, FINAL
jurisdiction_idNoA jurisdiction id from /v1/jurisdictions (narrows permit_number)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4/5.0
Behavior4/5

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

Annotations already establish read-only, non-destructive, idempotent behavior, so the description is free to add operational context — it does: source data_through, variable coverage by source/place, the warning that an empty result is not proof of absence, the 25-result cap, and the meaning of total_capped vs total_unknown. These are genuine behavioral disclosures not derivable from the schema. It does not describe the shape of individual result records, which is the remaining gap.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with purpose, then defaults, then caveats, then result semantics, then a pointer to _notes for pagination. It is telegraphic but every sentence carries distinct information; nothing is redundant padding.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 20-parameter, zero-required tool with no output schema, the description covers the things an agent most needs: default exclusions, coverage unreliability, empty-result non-conclusiveness, page size limit, and total_* sentinel meanings. Full completeness would also explain where data_through appears and what a returned record contains.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 95%, so parameter meaning is already carried by the schema. The description's filter list (place, permit, type, result, date) restates enum-backed parameters without adding syntax, format, or interaction detail, so the baseline of 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

Opens with a specific verb+resource ('Search inspection logs') and enumerates the filterable dimensions (place, permit, type, result, date). It implicitly distinguishes itself from get_permit_inspections by scoping to logs with limits and pagination, but never explicitly contrasts the two, so sibling differentiation is left to inference.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives concrete default behaviour and opt-in conditions: summaries and future scheduled inspections are excluded unless upcoming/summaries are set, and scope defaults are documented. It stops short of naming the sibling get_permit_inspections as the alternative for a single permit's inspections or explaining when to prefer it.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources