MCP and API Access for Construction Cost Data

Construction cost data should not be trapped inside one interface. Estimators may work in Omnicost, but agents, procurement tools, internal dashboards, and external applications also need access to reliable price intelligence.

Omnicost exposes the catalog through public read APIs and an MCP server. The API supports search, item detail, feeds, and pricing endpoints. MCP makes the same data available to AI clients that can call tools instead of scraping pages or guessing from a prompt.

The read endpoints are concrete and stable. GET /api/v1/items returns canonical items with a vendor breakdown and a median price, so you see both the spread and a single number you can put in an estimate. GET /api/v1/items/{id} adds a 90-day price history and accepts Accept: text/markdown, which means an agent can pull a clean, human-readable summary without parsing JSON. GET /api/v1/search?q=... runs semantic search over the catalog via Vectorize, so "movement of earth" and "excavation" land on the same items. Delta feeds at /api/v1/feeds/items.atom and .rss let you poll for changes instead of re-crawling, and region feeds like /api/v1/feeds/region/ES or /region/US narrow that stream to a single market. The full contract lives at /api/v1/openapi.json if you want to generate a client.

The MCP surface is intentionally focused. Tools can search the catalog, fetch item details, list categories, and inspect decompositions. Responses include readable text and structured content so agents can summarize for humans while still preserving machine-usable fields. Discovery follows the standard path: a client reads /.well-known/mcp.json and connects to the server at /api/mcp. From there an assistant calls a tool, gets back structured prices with their sources, and answers the question — no brittle page scraping, no hallucinated numbers.

A worked example makes the shape clear. Ask the API for US equipment rental rates and you get real records, not guesses. A search for excavator rentals returns Caltrans-sourced rates such as a CAT 320 L excavator at $49.59/hour and a CAT 312 at $28.60/hour. Each item carries its unit, currency, source, and the timestamp when the rate was recorded — so a procurement bot can compare classes, an estimator can defend a line, and an auditor can trace where the number came from.

Guardrails matter. Authenticated keys get higher rate limits, monthly caps protect the service, and private app routes remain outside the public crawl and agent surface. Public catalog access is a feature, but uncontrolled access is not. In practice the public read endpoints need no auth and allow 60 requests per minute per IP — enough to explore and prototype. When you need more, POST /api/v1/keys/signup issues a free developer key that lifts the limit to 200 requests per minute. You then send it on every call as Authorization: Bearer omc_pub_xxxx. The same key is what keeps automated clients accountable without putting a paywall in front of basic lookups.

The long-term product is a construction cost network. APIs and MCP are how that network becomes useful beyond Omnicost's own UI. A canonical item with a median, a vendor breakdown, and a traceable source is the unit of value; the feeds keep downstream systems current; and the developer key makes all of it auditable. Build a takeoff tool on top of it, wire it into an agent, or just poll a region feed into a spreadsheet — the data is the same underneath, and it stays honest because every price points back to where it came from.