What can you build with local government data?

A contractor wants to know which infrastructure projects deserve a closer look. A property manager wants to know whether a city is considering a change that affects their rentals. A reporter needs the history behind an item on next week's agenda.

These are different products, but they have a common starting point: find the relevant public records and turn them into something a particular person can use.

The interesting part is the output. A useful service might deliver a project timeline, a short research brief, a business-development queue, or an update inside software the customer already uses. It does not have to be a public-records search engine.

Here are five directions worth prototyping, followed by the AICD API requests that help you get started.

A development tracker people can follow

Picture a page for a proposed shopping center. It explains the location, links the planning case, shows the public meetings in which it appeared, and identifies the latest documented change. A subscriber follows that project rather than receiving every planning item from the entire city.

The initial audience could be commercial brokers, residents following nearby development, or a local publisher. Each would need a different presentation of the same underlying evidence. A broker might want applicant and project details. A resident might want the location, proposed use, and next meeting.

There is more to this than meeting records. McKinney's Development Services site links a Housing Hub, a Development Snapshot, planning maps, and infrastructure projects. Those are examples of official sources a tracker could investigate and connect. Their existence does not mean they are all ingested by AICD API.

A first version could combine supported agenda search with manually verified project links. Property boundaries, permit history, and construction updates can be added when those sources are actually available. The product's unit of organization is the project, not the PDF.

A construction-research queue for one trade

An electrical contractor and a drainage contractor should not receive identical alerts. Start with a trade, a service area, and the kinds of projects the business can perform.

The product could identify relevant discussions, retrieve the supporting material, and give an estimator a short research card: what the work concerns, where it is, what stage the source establishes, and where to check the official procurement information.

A discussion about a future project belongs in a different queue from an open solicitation or a contract that has already been awarded. That distinction lets the customer decide whether to investigate, monitor, or move on. A workable first release could be a reviewed email digest and a saved watchlist, without a large sales platform around it.

Policy monitoring tied to a business's actual locations

Consider a property-management company operating in several cities. Its useful question is not “What happened in local government?” It is “Which developments might require someone on our team to review an operating procedure?”

A proposed product could connect each business location to its jurisdiction, monitor a narrow set of subjects, and produce a source-linked review task. For short-term rentals, the subjects might include registration, inspections, occupancy, and operating requirements.

The application would keep proposed changes separate from verified requirements already in effect. It would also keep official code and department guidance alongside meeting evidence, rather than asking an agenda summary to serve as a complete compliance answer.

A research assistant for a local newsroom

A reporter investigating a street project might need earlier staff reports, related meeting items, the original authorization, and later changes. The deliverable could be an interview brief with a timeline and unanswered questions.

This is a useful role for an agent: search, read promising records, follow identifiers, and assemble a draft the reporter can inspect. The product should make it easy to move from a sentence in the brief to the exact source that supports it.

The first interface could be as simple as a project name, a jurisdiction, and a date range. The result should help the reporter prepare the next question, not present an automatically written article as finished reporting.

Contract intelligence for suppliers and service firms

A vendor could use historical contract records to understand which agencies purchase its category of work, which firms appear in those records, and what kinds of projects recur.

Dallas County's 2024 bid-tabulation page, for example, links procurement entries to court orders and supporting bid or scoring documents. Those records suggest a product organized around buyers, procurements, and suppliers rather than isolated keyword matches.

The implementation would need verified award evidence and a way to connect amendments to the original contract. An award ceiling is not the same measurement as money actually paid. A supplier profile can still be useful without claiming to measure the entire market.

Start with source discovery

AICD API's public research coverage endpoint helps you investigate source availability across data families. This request asks for the first page of jurisdictions associated with Collin County:

curl --fail-with-body --silent --show-error --get \
  'https://aicdapi.com/api/v1/public/coverage' \
  --data-urlencode 'county=collin' \
  --data-urlencode 'limit=20'

The response includes data and research metadata such as meta.researchDate, meta.catalogVersion, meta.statusDefinitions, and meta.ingestionVerified. Read those alongside the source evidence. The endpoint describes research findings and gaps, not a guarantee that the records are flowing into production.

For a narrower investigation, the documented family filter accepts identifiers such as city.permits and county.property_tax. Follow the returned pagination information using the same filters and limit. A catalog-version change invalidates the coverage cursor.

To examine operational evidence for supported meeting sources, use the separate source-status endpoint:

curl --fail-with-body --silent --show-error \
  'https://aicdapi.com/api/v1/public/source-status'

Its records include the jurisdiction, public body, status, last successful check, and agenda-text evidence. This helps you choose a demonstrable starting scope instead of selecting cities solely because they appear in the research catalog.

Get a small example into your application

The public recent agenda hits endpoint is a straightforward way to examine an actual response shape:

curl --fail-with-body --silent --show-error \
  'https://aicdapi.com/api/v1/public/agenda-hits?limit=3'

For each returned hit, your prototype can display title, jurisdictionName, bodyName, meetingAt, summary, evidenceQuote, and sourceUrl. Keep the evidence and original link visible beside the summary. This endpoint returns at most three recent hits and has no pagination; it is a sample surface, not a complete importer.

For targeted research, the documented MCP tools are get_coverage, search_agenda, and get_agenda_item. An enabled client could search for a phrase, narrow by jurisdiction and dates, then read a returned itemId. For an application maintaining its own supported civic-data dataset, the snapshot and change-feed interfaces serve a different job: initial import followed by durable updates.

The reference marks customer data endpoints as Limited availability. The MCP HTTP route and its tool section are also marked Limited availability. Authenticated examples therefore require enabled access and the appropriate key scopes. They should not be mistaken for a promise of unrestricted public access.

Build the output before expanding the scope

Choose one person and produce one useful result for them. For a contractor, that might be a reviewed project card. For a reporter, a background brief. For a property manager, a policy-review task linked to the properties it may concern.

Show the result to someone who does that work. Ask what they would do with it, which source they would open, and what information is still missing. Those answers tell you more about the next feature than a longer list of cities.

Use the AICD API reference to connect the available records to that output. The product opportunity is in the specific job you help the customer finish.