Blockworks

List 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.

monitoring_views

List 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_catalog

List 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_catalog

List 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_categories

List this user's watchlists: the named sets of assets they keep on Messari. Call it to answer "what am I watching", to pick up the assets a question is implicitly about ("how did my watchlist do this week"), or to get the id that watchlist_assets needs. It returns the watchlists the user owns plus any shared with them by their team. Each entry gives the title, how many assets are on it, who owns it, and how it is shared. It does not give the assets themselves — pass the id to watchlist_assets for those. Takes no arguments: whose watchlists these are is settled by the session, not by a parameter. This tool is read-only: it cannot create, rename or delete a watchlist, or change what is on one.

watchlists

Read developments from Blockworks' monitoring coverage of the crypto industry. A development is one thing that happened in the industry — a product launch, an exchange listing, a funding round, a governance vote, a security incident — assembled by Blockworks' editorial team from the public source documents reporting it, and carrying its own title, summary, taxonomy and editorial labels. It is news coverage of companies, protocols and assets, not information about individual people. 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_developments

Read events from Blockworks' monitoring coverage of the crypto industry. An event is a story over time: a group of related developments from Blockworks' editorial coverage of the industry, with rollups over its children — importance, category, asset coverage, a start and end, and how many developments and documents it spans. Like developments, events cover companies, protocols and assets, not individual people. 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_events

Read 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.

timeseries_data

Read 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.

tabular_data

Read one watchlist and the assets on it, each resolved to its name, slug and ticker symbol. Get the watchlistId from the watchlists tool. This is the call that turns "my watchlist" into a concrete set of assets you can then look up elsewhere: the slug each asset carries is the identifier the asset and dataset routes take. Assets come back in the order the watchlist holds them. A watchlist stores only asset ids, so the names are resolved by a second lookup; any id that lookup does not cover is reported in unresolvedAssetIds rather than guessed at, and note says so. Treat those ids as genuinely on the watchlist — only their names are missing. It reads a watchlist the user owns, one their team shares with them, or a public one whose id they have. This tool is read-only: it cannot add or remove assets.

watchlist_assets