monitoring_categories
ChatGPTList the intel taxonomy that classifies developments and events. Call this before passing intelCategories or intelSubcategories to monitoring_developments or monitoring_events. Those filters take slugs, and a slug that is not in this taxonomy matches nothing. Do not guess a slug from a category's name. Takes no arguments and returns every top-level category with its subcategories, each as {slug, name, description}. ACCESS: this reads Blockworks' monitoring product, which an account is entitled to separately. A FORBIDDEN result means this session cannot read it — either the account is not entitled, or its credential type is not accepted — and the error says which. Either way, relay it and stop: do not retry, and do not try the other monitoring_* tools for the same user, because they go through the same gateway and will refuse too.
monitoring_developments
ChatGPTRead developments from Blockworks' monitoring coverage of the crypto industry. A development is one thing that happened — an exploit, a listing, a funding round, a governance vote — assembled from the source documents reporting it and carrying its own title, summary, taxonomy and editorial flags. Related developments are grouped into an event; use monitoring_events to read the story rather than its parts. Use this tool for "what happened" over a window, for an asset, or in a category, and for the source documents behind it. Use search_documents instead for explanation and background out of the research corpus, and tabular_data or timeseries_data for numbers. THREE WAYS TO READ, chosen by what you pass: - Nothing extra: the whole corpus, narrowed by the filters you pass. - monitoringViewId: only what one saved monitoring view matches. The view's own predicates always apply; your filters narrow further and can never widen past it. Call monitoring_views for the ids. - monitoringViewId "all": the deduplicated union across every view the caller can see. This route applies a smaller filter set — minimumImportance, actionable, assetSectors, assetSubsectors, assetPreTge, assetEcosystemNetworkIds and search — and rejects the rest rather than ignoring them. - developmentId: that one development by UUID or slug, filters ignored. FILTERS combine with AND. intelCategories and intelSubcategories take slugs from monitoring_categories, not names. assetIds takes a UUID, slug or symbol, and a symbol can expand to several assets. start and end bound the development's own window, not its creation time, and accept YYYY-MM-DD, RFC3339 or unix seconds — always state a window when the question is time-sensitive. Returns at most 50 developments, 10 by default, plus totalRows and totalPages for the whole filtered set: check totalRows before concluding you have seen everything. Each development carries its source documents as title and url. Cite those, not this tool. ACCESS: this reads Blockworks' monitoring product, which an account is entitled to separately. A FORBIDDEN result means this session cannot read it — either the account is not entitled, or its credential type is not accepted — and the error says which. Either way, relay it and stop: do not retry, and do not try the other monitoring_* tools for the same user, because they go through the same gateway and will refuse too.
monitoring_events
ChatGPTRead events from Blockworks' monitoring coverage of the crypto industry. An event is a story over time: a group of related developments, with rollups over its children — importance, category, asset coverage, a start and end, and how many developments and documents it spans. Read events when you want the arc of something; read monitoring_developments when you want the individual things that happened. THREE WAYS TO READ, chosen by what you pass, matching monitoring_developments exactly: - Nothing extra: the whole corpus, narrowed by the filters you pass. - monitoringViewId: only what one saved monitoring view matches, narrowed further by your filters. - monitoringViewId "all": the deduplicated union across every view the caller can see. This route applies a smaller filter set — minimumImportance, actionable, assetSectors, assetSubsectors, assetPreTge, assetEcosystemNetworkIds and search — and rejects the rest rather than ignoring them. - eventId: that one event by UUID or slug, filters ignored. A list read answers in events, each carrying slim summaries of its developments. An eventId read answers in event instead, with every development hydrated with its source documents and assets — so fetch the event by id when you need to cite the reporting behind a story. Filters combine with AND and behave as they do in monitoring_developments: category slugs come from monitoring_categories, start and end bound the event's own window, and a filter on a development property selects events with a matching development. Returns at most 50 events, 10 by default, plus totalRows and totalPages for the whole filtered set. ACCESS: this reads Blockworks' monitoring product, which an account is entitled to separately. A FORBIDDEN result means this session cannot read it — either the account is not entitled, or its credential type is not accepted — and the error says which. Either way, relay it and stop: do not retry, and do not try the other monitoring_* tools for the same user, because they go through the same gateway and will refuse too.
monitoring_views
ChatGPTList the saved monitoring views this user can see, or describe one in full. A monitoring view is a saved predicate set — assets, categories, minimum importance, editorial flags — that developments and events are continuously matched against. It is what a user has told Blockworks to watch. Views are personal or shared with the user's team; this tool shows both, and shows only this user's, never anyone else's. Call it to answer "what am I watching", to report what a view has matched recently, or to get the id that scopes a monitoring_developments or monitoring_events read. Those two tools also accept monitoringViewId "all" to read across every view at once, which needs no id from here. Each view returns its predicates, matchStats (total and 24-hour match counts at both development and event level, and the last time it matched), and whether the user owns it or it is team-shared. A predicate that reads null is one the view does not constrain, which is not the same as constraining it to false. A view with a prompt is an agentic view, matched by that prompt rather than by predicates alone, and evaluationProgress reports how far its evaluation has got. This tool is read-only: it cannot create, edit or delete a view. ACCESS: this reads Blockworks' monitoring product, which an account is entitled to separately. A FORBIDDEN result means this session cannot read it — either the account is not entitled, or its credential type is not accepted — and the error says which. Either way, relay it and stop: do not retry, and do not try the other monitoring_* tools for the same user, because they go through the same gateway and will refuse too.
search_documents
ChatGPTRetrieve source documents from Blockworks' research and news corpus. This tool runs Blockworks' Search agent on its own. It returns the documents it found. It does NOT write an answer: read the documents and write the answer yourself. Most documents come from an indexed corpus: research, news, governance, diligence and transcripts, plus curated collections of third-party news and X (Twitter) posts that are ingested ahead of time. The tool does not query X or news sites when called. When the question names a project, the agent may also run a live web search limited to that project's own sites. USE THIS TOOL FOR: - Explanations and background: "What is EigenLayer's restaking model?" - News and events: "What happened to Balancer in November?" - Governance proposals, diligence findings, project narrative, conference transcripts - Any question that needs text evidence you can cite USE tabular_data OR timeseries_data INSTEAD FOR: - Numbers, rankings, aggregates, and time series: price, volume, TVL, fees, revenue, supply, funding amounts, unlock schedules - Any question a query over a dataset answers better than a document INPUT: query, one natural language question. Ask one thing per call. Several focused calls beat one loaded query. The corpus spans years and the agent reads the time window out of your wording, so name concrete dates whenever the question is time-sensitive: "in August 2026" or "since 2026-08-01", not "latest" or "recently". A query with no date returns the best matches from the whole corpus, most of which will be old. OUTPUT: - sources: the retrieved documents. Each has domain, title, url, published_at (absent when the corpus carries no date), and content. domain names the indexed collection the document came from (research, news, external_news, diligence, governance, twitter, video_transcript, and others); web marks a live web search result. - error: set only when the run finds no usable document. It explains why. Cite the title and url of every document you use. State no fact the documents do not support.
tabular_catalog
ChatGPTList the tabular datasets this server serves, or describe one in full. Tabular models are row-and-column datasets — assets, exchanges, funding rounds, funds, ETF holdings — as opposed to metrics over time, which timeseries_catalog covers. Call this before tabular_data. It returns the exact model slug, the exact column field names, which columns are sortable, and which filter operators each column accepts. tabular_data rejects any field or operator that does not match the catalog exactly. With no arguments it returns one compact entry per model. Pass a model slug for that model's full column list, or search to narrow the list. This catalog lists only the models Blockworks publishes to the public API; any model it does not publish is omitted here and cannot be discovered through this tool. Publishing is separate from data access: a listed model still carries an access tier, so reading a paid, unpaid or permissive model needs an API key with the matching entitlement, while a public model needs none.
tabular_data
ChatGPTRead rows from one tabular dataset, filtered, sorted and paginated. Use this for row-oriented records: entity lists, rankings, attributes, comparisons and point-in-time snapshots. Do NOT use it for values over time such as price, TVL, fees, volume or supply history — use timeseries_data — or for written or qualitative questions — use search_documents. Call tabular_catalog with this model's slug first. Every string passed in model, selections, filters and sortBy must match the catalog exactly. Filters are objects of the form {field, operator, values}, combined with AND. A column only accepts the operators listed in its catalog entry. Values are written as strings and coerced to the column's type; dates accept YYYY-MM-DD, RFC3339 or unix seconds. Includes and IncludesAnyOf apply to columns holding arrays. Returns at most 200 rows, 25 by default, plus totalRows and totalPages for the whole filtered set — check totalRows before concluding you have seen everything. To answer a question about a large model, filter and sort on the server rather than paging through it.
timeseries_catalog
ChatGPTList the time-series datasets this server serves, or describe one in full. Timeseries models are metrics observed over time — prices, supply, revenue, volumes, mindshare — split into named series, usually one per asset, protocol, exchange or sector, and available at fixed granularities. Call this before timeseries_data. It returns the exact model slug, the granularities the model supports, the exact metric field names, and whether the model can return every series at once (allowAllSeries true) or requires you to name the series keys. With no arguments it returns one compact entry per model. Pass a model slug for that model's full metric list, or search to narrow the list. Series keys are the model's own identifiers, usually opaque ids rather than tickers or names. To turn a name or symbol into a series key, read the matching tabular model with tabular_data and take the key from the matching row.
timeseries_data
ChatGPTRead points from one time-series dataset over a time window. Use this for numeric values that change over time: price, volume, TVL, fees, supply and similar metrics. Do NOT use it for written or qualitative questions such as news, research, governance or explanations — use search_documents — or for entity lists, rankings or snapshots — use tabular_data. Call timeseries_catalog with this model's slug first: the slug, the valid granularities, the metric field names, and whether every series can be read at once all come from there. Series keys are the model's own identifiers — if you have only a name or a ticker, resolve it through the matching tabular model with tabular_data. Points are positional arrays, not objects: position 0 is a unix timestamp in seconds and the remaining positions follow point_schema in order. Read point_schema before interpreting any point. Choose a window with either timeframe (relative: 30d, 12h, 4w, or ytd, qtd, mtd, dtd; or calendar: 2024, 2024-06, 2024-06-01) or start and end — never both. With none of them the window defaults to the last 90 days. Set bounds true to get only the first and last point of the window for each series, which is the cheap way to compute a change over a period. One call returns at most 5000 points across all series. If a call is rejected for exceeding that, shorten the timeframe, use a coarser granularity, name fewer series, select fewer metrics, or set bounds true.
