Free, certified Oklahoma records: property insurance, roofing, and permits (Norman, OKC).
Scored across 5 tools
Each tool has a clearly distinct purpose: get_record fetches by globally unique id, search_records handles filters/free text/permit-number lookup, get_record_history walks revision lineage, list_changes_since polls a delta feed, and list_collections enumerates the roster. The descriptions explicitly cross-reference each other to route the agent (e.g. use search_records for permit-number lookups), leaving no meaningful misselection risk.
All five tools follow a clean verb_noun pattern (get_record, get_record_history, list_collections, list_changes_since, search_records) in snake_case with no camelCase or stylistic mixing. The verb choice also signals intent consistently: get for id lookup, list for enumeration, search for querying.
Five tools is a well-scoped surface for a read-only certified-records registry: discovery, search, direct retrieval, lineage, and incremental sync. Nothing looks redundant or bolted on, and there is no thin single-tool mismatch.
The read-only lifecycle is essentially covered — find collections, search records, fetch a record, trace its revisions, and poll for changes — which matches a publication/certification service with no write operations expected. Minor gaps remain, such as no bulk export or aggregate/count endpoint for a full collection pull.
Get one certified record by record_id, from either collection (ids are globally unique), e.g. "OK-PERMIT-2026-04835" (a permit) or "OK-ROOF-2026-0003" (an insurance/roofing fact). Includes sources and certification. To look a permit up by its permit number instead, use search_records with permit_number.
| Name | Required | Description | Default |
|---|---|---|---|
| record_id | Yes | e.g. "OK-PERMIT-2026-04835" or "OK-ROOF-2026-0003" |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are supplied, so the description carries the full disclosure burden. It does add useful behavioral content – ids are globally unique across collections and the result includes sources and certification – but says nothing about what happens when the id is unknown, whether access is restricted, or how large/heavy the response is.
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?
Three tight sentences, front-loaded with the core action and scope, then examples, then the disambiguation rule. No filler or restated boilerplate.
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 single-parameter read tool with no output schema, the description covers the id contract, cross-collection scope, and roughly what the payload contains (sources, certification). It would be complete with a note on not-found behavior or pagination, but nothing essential to correct invocation is missing.
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% and the single parameter already has an example, so the baseline is 3. The description earns above baseline by decoding the id prefixes (OK-PERMIT = permit, OK-ROOF = insurance/roofing fact), which is semantic meaning the schema does not supply.
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?
Specific verb (Get) plus resource (one certified record) with explicit scope (by record_id, across either collection since ids are globally unique). Concrete id examples and the parenthetical label of each id family make it immediately distinguishable from search_records and the history siblings.
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?
It names a concrete alternative and the condition that selects it: 'To look a permit up by its permit number instead, use search_records with permit_number.' That is an explicit when-to-use-else routing instruction, not an implied one.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the full revision lineage for a record -- every certified record it supersedes or was superseded by, oldest first. Use after get_record or search_records to see how a rule or permit record changed over time.
| Name | Required | Description | Default |
|---|---|---|---|
| record_id | Yes | e.g. "OK-ROOF-2026-0003" |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden, and it does disclose meaningful traits: deterministic ordering ("oldest first") and the content shape (certified revisions linked by supersedes). However, it omits whether the call is read-only by contract, what happens for a record with no revision history, and any pagination or size limits.
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 tight sentences with no waste; the return semantics are front-loaded and the usage hint follows. Every clause earns its place.
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?
No output schema exists, so the description must describe the return, and it does so usefully (lineage, supersedes relations, ordering). It is complete enough to invoke correctly for a 1-param read tool, though edge cases like empty history are 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 100% and there is a single required record_id param, so the schema already documents the parameter (including an example). The description adds no syntax or format detail beyond it, making the baseline 3 correct.
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?
States a specific verb and resource ("Get the full revision lineage for a record") and immediately distinguishes it from siblings by describing exactly what it returns (superseded/supersedes relationships, oldest first). An agent can tell this apart from get_record or search_records without opening a schema.
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?
Explicitly routes usage with "Use after get_record or search_records to see how a rule or permit record changed over time," naming the alternative tools and the scenario. It covers when to use but offers no exclusion (e.g., when this yields nothing and get_record is sufficient).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Poll for what changed since a date instead of re-pulling everything: newly certified records, superseded (old->new) pairs, and reconfirmed records. Example: {"since":"2026-10-01","collection":"ok_property_permits"} returns permits certified after that date (new weekly Oklahoma City reroofing permits). Sources are re-checked weekly (Sundays, 00:00 UTC). Omitting collection scopes to ok_roofing_insurance only. Free, no API key.
| Name | Required | Description | Default |
|---|---|---|---|
| city | No | ok_property_permits only: "Norman" or "Oklahoma City" (alias jurisdiction_city accepted). | |
| since | Yes | ISO 8601 date or datetime, e.g. "2026-10-01" | |
| state | No | Two-letter state code, e.g. "OK". | |
| topic | No | Exact topic / permit type, same values as search_records. | |
| county | No | ok_property_permits only: "Cleveland" or "Oklahoma" (alias jurisdiction_county accepted). | |
| subject | No | Exact category, same values as search_records. | |
| collection | No | Which collection to poll; default ok_roofing_insurance. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does well: it discloses the refresh cadence (weekly, Sundays 00:00 UTC), the default scoping when `collection` is omitted, and that access is free with no API key. It does not describe pagination or ordering of results, and does not need a destructive/safety note for a poll operation.
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 core purpose and value proposition before the example and operational notes. It is dense but each sentence does work; the parenthetical 'new weekly Oklahoma City reroofing permits' is slightly verbose but grounds the example usefully.
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?
Given no output schema and no annotations, the description covers the essentials: return categories, freshness cadence, default scope, and auth/cost model. It is complete enough to call correctly, with only result ordering/pagination left unspecified.
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 value beyond the schema: it clarifies the default value for `collection` (ok_roofing_insurance when omitted) and provides a concrete example payload with its expected output. The `since` semantics are illustrated concretely rather than merely restated.
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?
States a specific verb and resource ('poll for what changed since a date') and enumerates the three return categories: newly certified records, superseded old->new pairs, and reconfirmed records. It explicitly frames itself against re-pulling everything, so an agent can tell it apart from search_records without opening either schema.
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?
The opening clause 'instead of re-pulling everything' clearly signals the incremental-sync use case versus a full re-pull via search_records. It gives an example invocation and default-scope behavior, but does not state explicit when-not conditions or name the sibling alternative directly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List Oracle's record collections with id, label, description, live record count, certification basis, jurisdiction scope and an example query. Call this FIRST: it shows that Oracle holds both Oklahoma insurance/roofing-regulation facts and 8,000+ Norman and Oklahoma City building/reroofing permit records. Free, no API key.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does disclose key behavioral facts: it is a free, no-API-key read operation and the counts are 'live.' It does not describe pagination or ordering behavior, but for a zero-parameter listing the auth and cost disclosures are the material ones.
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?
Three sentences, front-loaded with what is listed, then the call-first directive, then supporting evidence of coverage. The Oklahoma/Norman content sentence borders on promotional but serves selection purposes, so waste is minimal.
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?
There is no output schema, and the description compensates by enumerating the fields returned, which is exactly what an agent needs. For a no-param, read-only list tool this is nearly complete; only pagination/ordering hints are absent.
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?
The tool takes no parameters, so the schema baseline of 4 applies. The description adds nothing on parameters because there is nothing to add.
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?
States a precise verb+resource ('List Oracle's record collections') and enumerates the returned fields (id, label, description, live record count, certification basis, jurisdiction scope, example query), which clearly separates it from get_record/search_records. It does not explicitly contrast with any named sibling, but the catalog-listing scope is unambiguous.
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?
'Call this FIRST' gives an explicit invocation ordering with a stated reason (it reveals what the data set contains), which is strong guidance for an agent starting a task. No when-not condition or named alternative is given, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search certified Oklahoma records. Find reroofing and building permits (Norman 2015-present; Oklahoma City weekly residential reroofing), contractor activity, permits by address or street, a permit by number, plus Oklahoma insurance and roofing rules (contractor licensing, building code, carrier ratings, FORTIFIED roof grants). Examples: {"collection":"ok_property_permits","city":"Oklahoma City","q":"reroofing"}; {"collection":"ok_property_permits","q":"CAVINS ROOFING"}; {"collection":"ok_property_permits","permit_number":"ROOF-2026-04057"}; {"subject":"contractor_licensing","state":"OK"}. Free text goes in q; all other filters are exact-match, case-insensitive and combinable. Omitting collection searches ONLY ok_roofing_insurance (15 records) -- pass collection=ok_property_permits for permits (the response also points to it). Free, no API key. Call list_collections to see the roster.
| Name | Required | Description | Default |
|---|---|---|---|
| q | No | FREE-TEXT search (case-insensitive substring). Permits: matches permit category/type, address, contractor and permit number, e.g. "roofing", "CAVINS ROOFING", "W MAIN ST", "ROOF-2026-04057". Insurance: matches summary, detail and topic, e.g. "FORTIFIED", "Allstate", "continuing education". | |
| tag | No | Exact tag. Insurance examples: "FORTIFIED", "contractor licensing", "agency M&A". Permit examples: "norman", "okc", "reroofing", "storm_shelter", "solar", "pool". | |
| city | No | ok_property_permits only (CANONICAL name; `jurisdiction_city` is accepted as an alias). Exact city: "Norman" or "Oklahoma City". | |
| limit | No | Max records returned (default 50, max 200). | |
| state | No | Two-letter state code. All records are "OK". | |
| topic | No | Exact topic. Insurance: e.g. "fortified_roof_program_milestone", "roofing_contractor_annual_renewal_requirement". Permits: the permit type, e.g. "Residential Reroofing Permit". | |
| county | No | ok_property_permits only (canonical; `jurisdiction_county` accepted as an alias). "Cleveland" (Norman) or "Oklahoma" (Oklahoma City). | |
| offset | No | Skip this many matches, for paging. | |
| status | No | Insurance: record status, one of active, superseded, expired, proposed, rescinded (all current records are "active"). Permits: the permit status, e.g. "issued". | |
| carrier | No | Insurance collection only. Exact carrier name, e.g. "Allstate Corp." or "Triangle Insurance Company". Most records have no carrier. | |
| subject | No | Exact category. Insurance collection: underwriting, claims_handling, contractor_licensing, building_code, market_conduct, regulatory_filing, insurance_industry. Permits collection: the permit category, e.g. "Residential Reroofing" (Oklahoma City), "Residential", "Single Family", "Commercial Addition/Alteration", "Demolition" (Norman). `category` is accepted as an alias. | |
| collection | No | Which collection to search. "ok_property_permits" = 8,484 Norman/Oklahoma City permit records (reroofing, construction, contractors, addresses). "ok_roofing_insurance" = 15 hand-certified insurance/roofing-regulation facts; this is the default when omitted. | |
| permit_number | No | ok_property_permits only: exact permit number, e.g. "ROOF-2026-04057" (Oklahoma City) or "PRSF202305769" (Norman 2024+). Case-insensitive. Also shown as permit.permit_number on each record. | |
| jurisdiction_city | No | Alias of `city`; prefer `city`. | |
| jurisdiction_county | No | Alias of `county`; prefer `county`. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden and does well: it discloses cost ("Free, no API key"), matching semantics (free text in `q`, other filters exact-match/case-insensitive/combinable), and default-collection behavior. It does not describe return shape or pagination interaction between limit/offset, but coverage is otherwise strong.
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 purpose, then scope, examples, and defaults. The four JSON examples are dense but each demonstrates a distinct query pattern (collection+city+q, contractor, permit_number, subject+state). Slightly long but nearly every clause earns its place.
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 15-parameter, zero-required search tool with no output schema and no annotations, the description supplies the missing behavioral context: default collection, matching rules, and cost. Only return-format/pagination detail is left implicit, which the schema's limit/offset partially cover.
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% (baseline 3), and the description adds genuine meaning on top: the free-text-vs-exact-match split and filter combinability rules, plus the default collection when omitted. These clarify how to drive the 15 parameters beyond what the schema repeats.
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?
States a specific verb+resource ("Search certified Oklahoma records") and enumerates the concrete domains searched: permits, contractor activity, permit-by-number, and insurance/roofing rules. An agent can immediately distinguish this retrieval tool from the get_record/list_collections siblings.
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?
Explicitly explains the default behavior ("Omitting `collection` searches ONLY ok_roofing_insurance (15 records)") and the alternative ("pass collection=ok_property_permits for permits"), plus routes the agent to list_collections to see the roster. This is exactly the when/when-not/alternative guidance the dimension rewards.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
get_record1 field changedInput schema / properties / record_id / descriptionAdded value: +"e.g. \"OK-PERMIT-2026-04835\" or \"OK-ROOF-2026-0003\""get_record_history1 field changedInput schema / properties / record_id / descriptionAdded value: +"e.g. \"OK-ROOF-2026-0003\""list_changes_since8 fields changedInput schema / properties / cityAdded value: +{
+ "description": "ok_property_permits only: \"Norman\" or \"Oklahoma City\" (alias jurisdiction_city accepted).",
+ "type": "string"
+}Input schema / properties / collection / descriptionPrevious value: -"See search_records — same default/roster."New value: +"Which collection to poll; default ok_roofing_insurance."Input schema / properties / collection / enumAdded value: +[
+ "ok_roofing_insurance",
+ "ok_property_permits"
+]Input schema / properties / countyAdded value: +{
+ "description": "ok_property_permits only: \"Cleveland\" or \"Oklahoma\" (alias jurisdiction_county accepted).",
+ "type": "string"
+}Input schema / properties / since / descriptionPrevious value: -"ISO 8601 date or datetime"New value: +"ISO 8601 date or datetime, e.g. \"2026-10-01\""Input schema / properties / state / descriptionAdded value: +"Two-letter state code, e.g. \"OK\"."Input schema / properties / subject / descriptionAdded value: +"Exact category, same values as search_records."Input schema / properties / topic / descriptionAdded value: +"Exact topic / permit type, same values as search_records."search_records16 fields changedInput schema / properties / carrier / descriptionAdded value: +"Insurance collection only. Exact carrier name, e.g. \"Allstate Corp.\" or \"Triangle Insurance Company\". Most records have no carrier."Input schema / properties / city / descriptionPrevious value: -"Jurisdiction city — relevant to ok_property_permits (e.g. \"Norman\", \"Oklahoma City\")"New value: +"ok_property_permits only (CANONICAL name; `jurisdiction_city` is accepted as an alias). Exact city: \"Norman\" or \"Oklahoma City\"."Input schema / properties / collection / descriptionPrevious value: -"Which collection to search, e.g. \"ok_roofing_insurance\" (default) or \"ok_property_permits\". See list_collections for the current roster."New value: +"Which collection to search. \"ok_property_permits\" = 8,484 Norman/Oklahoma City permit records (reroofing, construction, contractors, addresses). \"ok_roofing_insurance\" = 15 hand-certified insurance/roofing-regulation facts; this is the default when omitted."Input schema / properties / collection / enumAdded value: +[
+ "ok_roofing_insurance",
+ "ok_property_permits"
+]Input schema / properties / county / descriptionPrevious value: -"Jurisdiction county — relevant to ok_property_permits"New value: +"ok_property_permits only (canonical; `jurisdiction_county` accepted as an alias). \"Cleveland\" (Norman) or \"Oklahoma\" (Oklahoma City)."Input schema / properties / jurisdiction_cityAdded value: +{
+ "description": "Alias of `city`; prefer `city`.",
+ "type": "string"
+}Input schema / properties / jurisdiction_countyAdded value: +{
+ "description": "Alias of `county`; prefer `county`.",
+ "type": "string"
+}Input schema / properties / limit / descriptionAdded value: +"Max records returned (default 50, max 200)."Input schema / properties / offset / descriptionAdded value: +"Skip this many matches, for paging."Input schema / properties / permit_numberAdded value: +{
+ "description": "ok_property_permits only: exact permit number, e.g. \"ROOF-2026-04057\" (Oklahoma City) or \"PRSF202305769\" (Norman 2024+). Case-insensitive. Also shown as permit.permit_number on each record.",
+ "type": "string"
+}Input schema / properties / q / descriptionPrevious value: -"Free-text search over claim summary/detail, or over permit type/address/contractor"New value: +"FREE-TEXT search (case-insensitive substring). Permits: matches permit category/type, address, contractor and permit number, e.g. \"roofing\", \"CAVINS ROOFING\", \"W MAIN ST\", \"ROOF-2026-04057\". Insurance: matches summary, detail and topic, e.g. \"FORTIFIED\", \"Allstate\", \"continuing education\"."Input schema / properties / state / descriptionAdded value: +"Two-letter state code. All records are \"OK\"."Input schema / properties / status / descriptionAdded value: +"Insurance: record status, one of active, superseded, expired, proposed, rescinded (all current records are \"active\"). Permits: the permit status, e.g. \"issued\"."Input schema / properties / subject / descriptionAdded value: +"Exact category. Insurance collection: underwriting, claims_handling, contractor_licensing, building_code, market_conduct, regulatory_filing, insurance_industry. Permits collection: the permit category, e.g. \"Residential Reroofing\" (Oklahoma City), \"Residential\", \"Single Family\", \"Commercial Addition/Alteration\", \"Demolition\" (Norman). `category` is accepted as an alias."Input schema / properties / tag / descriptionAdded value: +"Exact tag. Insurance examples: \"FORTIFIED\", \"contractor licensing\", \"agency M&A\". Permit examples: \"norman\", \"okc\", \"reroofing\", \"storm_shelter\", \"solar\", \"pool\"."Input schema / properties / topic / descriptionAdded value: +"Exact topic. Insurance: e.g. \"fortified_roof_program_milestone\", \"roofing_contractor_annual_renewal_requirement\". Permits: the permit type, e.g. \"Residential Reroofing Permit\"."list_changes_since1 field changedInput schema / properties / collectionAdded value: +{
+ "description": "See search_records — same default/roster.",
+ "type": "string"
+}list_collectionssearch_records4 fields changedInput schema / properties / cityAdded value: +{
+ "description": "Jurisdiction city — relevant to ok_property_permits (e.g. \"Norman\", \"Oklahoma City\")",
+ "type": "string"
+}Input schema / properties / collectionAdded value: +{
+ "description": "Which collection to search, e.g. \"ok_roofing_insurance\" (default) or \"ok_property_permits\". See list_collections for the current roster.",
+ "type": "string"
+}Input schema / properties / countyAdded value: +{
+ "description": "Jurisdiction county — relevant to ok_property_permits",
+ "type": "string"
+}Input schema / properties / q / descriptionPrevious value: -"Free-text search over claim summary/detail"New value: +"Free-text search over claim summary/detail, or over permit type/address/contractor"get_recordget_record_historylist_changes_sincesearch_recordsOfficial US-address public records: zoning, flood, parcel, permits, taxes. Free look, x402 paid.
US parcels, owners, sales, zoning rules, building permits and zoning cases.
Official US and UK records: licenses, NPI, carriers, contracts, inspections, permits, house prices
Source-linked building-permit search across 34 US states and DC, with county-level coverage.
Add one secure layer between your agents and this server.