Skip to content

Integrate with QuickLookup

Use REST for applications and the MCP endpoint for compatible agent clients. Both enforce the same bearer identity, catalogue visibility, saved-context ownership, paging, and delivery code.

REST clients

  1. List visible services with GET /v1/catalog/services.
  2. Cache the selected detail response using its private ETag.
  3. Build controls from contract.inputs, inputAlternatives, and choices.
  4. Send a returned example to queryUrl, then change only the required values.
  5. Page by returning nextCursor unchanged.

Do not hard-code database relations or FDW parameters. Treat service and contract revisions as part of the response provenance.

MCP clients

POST https://quicklookup.com/mcp, with your API key as the bearer token, is a sessionless, read-only MCP v2 endpoint using protocol version 2026-07-28. Authenticate every request with the same bearer token used by REST.

The endpoint exposes ten read-only tools:

Tool Use
list_data_services Search access-filtered service summaries.
get_data_service Inspect one contract, its alternatives, limits, and examples.
query_data_service Run the inspected service and continue with its cursor.
search_nearby_events Search occurrences across every visible event feed near a runtime location.
list_time_series_families Find each semantic time series once, with source/resolution/quality filters.
get_time_series_family Inspect authorized variants and choose a concrete recommendation.
list_saved_context Search account and personal context, optionally by context type.
get_saved_context Inspect one reusable selection and its health.
resolve_saved_context Resolve data-service or time-series context into catalogue items.
query_saved_event_context Apply saved event filters to a runtime period and optional location.

Start with server/discover. Send the protocol version in both MCP-Protocol-Version and the request _meta; send Mcp-Method for every call and Mcp-Name for tools/call. Use the returned tool schemas rather than duplicating them in client code.

When saved context exists, start with list_saved_context. Use its contextGid with get_saved_context, then either resolve_saved_context for data-service/time-series context or query_saved_event_context for event context. Event context always needs runtime from and to; time and location are not stored in the context definition.

For new time-series discovery, use list_time_series_families, then get_time_series_family. The family detail contains the authorized variants, selection reasons, and a concrete recommended queryUrl; pass that concrete service to query_data_service. This preserves the same family-first presentation as the web catalogue.

query_data_service also takes $apply, the OData aggregation expression the REST query accepts, and answers with the same groups (Aggregate).

query_data_service and search_nearby_events wait for their sources by default, which can take seconds for data nobody has asked about yet. Pass "respondAsync": true to be answered at once instead: what is ready comes back, and anything still being fetched is named under pending (or feedsPending) with retryAfterMs. Call the tool again with the same arguments after that for the rest — the same behaviour REST gives Prefer: respond-async (Answer now, fill in later).

MCP tools are annotated as read-only, non-destructive, and idempotent. Create, replace, and archive context through REST or the authenticated API console; agent clients use the same context without gaining mutation authority.

Connect an MCP client to https://quicklookup.com/mcp with your API key as the bearer token.

Semantic consumers

GET /v1/semantic/manifest returns the published time-series and event definitions visible to the caller. It is intended for semantic engines that need relations, contracts, predicates, mappings, and custom aggregations.

The response is private. Cache it with the returned ETag or remember manifestRevision; send If-None-Match or sinceRevision on the next request. A 304 means the visible manifest has not changed.

Browser security

The documentation explorer stores its token in sessionStorage, limits requests to the same origin, and discards the token when the tab session ends or you select Change token. Production applications should keep tokens out of URLs, logs, persistent browser storage, and shared error reports.