Alphanume Datasets

Crypto Enforcement Actions

get_crypto_enforcement

Read-onlyIdempotent

US digital-asset enforcement, one normalized tape across the three agencies that bring it: SEC litigation releases and administrative proceedings, CFTC enforcement press releases, and DOJ criminal announcements, 2024+. One row per (action, respondent): what was alleged (multi-category), statutes cited, tokens/assets involved (real JSON arrays), monetary relief with its stated basis, settled flag (three-state), listed-issuer linkage where the document itself states one, and a follow-up chain linking successive actions by the same agency against the same respondent (complaint -> consent order, indictment -> plea).

The date window filters published_date (structural, the agency's announcement date); action_date is extracted from the document with its own precision enum. One matter can appear once per agency -- nothing links across agencies, by design. monetary_relief_usd repeats on each respondent row of one action; de-duplicate on action_key before summing.

Requires an Alphanume Pro API key. A 403 PRO_SUBSCRIPTION_REQUIRED or DATE_RANGE_RESTRICTED error means the key's plan does not cover the request -- it does not mean the data is missing.

Input Schema

TableJSON Schema

Name	Required	Description
`date`	No	Exact date, YYYY-MM-DD. Cannot be combined with the date range parameters.
`asset`	No	Case-insensitive substring over the assets list, e.g. 'bitcoin'. Asset strings are unnormalized document literals (Bitcoin/BTC both occur).
`agency`	No	Which agency brought the action: sec, cftc, or doj.
`date_gt`	No	Start of date range, exclusive (YYYY-MM-DD).
`date_lt`	No	End of date range, exclusive (YYYY-MM-DD).
`settled`	No	Three-state: true (document says settled), false (document says not settled), unknown (document does not say). Never collapse unknown into false.
`date_gte`	No	Start of date range, inclusive (YYYY-MM-DD).
`date_lte`	No	End of date range, inclusive (YYYY-MM-DD).
`max_rows`	No	Maximum data rows to return to the client (applied after the API responds). Default 500. Use 0 for no cap. Prefer narrowing with date/ticker filters over raising this.
`record_id`	No	Exact served row id: '<action_key>#<respondent_index>'.
`action_key`	No	Exact action id, e.g. 'sec-lr:LR-26456', 'cftc:9285-26', 'doj:<uuid>'. One action returns one row per respondent.
`allegation`	No	Matches anywhere in the allegation list: fraud, unregistered_offering, unregistered_exchange_or_broker, market_manipulation, aml_bsa, sanctions, misappropriation, other.
`respondent`	No	Case-insensitive substring over the respondent name and its normalized key, e.g. 'bankman'.
`action_type`	No	What the document announces NOW: civil_complaint, administrative_proceeding, settled_order, criminal_indictment, criminal_plea, trial_verdict, other.
`is_followup`	No	1 = this action follows an earlier action by the same agency against the same respondent.
`has_followup`	No	1 = a later action by the same agency against the same respondent exists.
`source_index`	No	Document kind: litigation-release, administrative-proceeding (SEC only; the PDF orders), or press-release (CFTC/DOJ).
`updated_since`	No	YYYY-MM-DD, on last_updated -- rows touched by the follow-up sweep since this date.
`respondent_key`	No	Exact normalized respondent key (lower-cased, suffixes stripped) -- the group-by for 'every action against this party' within one agency.
`respondent_kind`	No	person or company.
`cursor_action_key`	No	Pagination: 'action_key' from next_cursor.
`primary_allegation`	No	Matches only the lead allegation (same enum as allegation).
`has_monetary_relief`	No	1 = a dollar amount was stated, 0 = none stated.
`max_monetary_relief`	No	Maximum monetary_relief_usd.
`min_monetary_relief`	No	Minimum monetary_relief_usd. CAUTION: relief repeats on every respondent row of one action -- summing across rows double-counts.
`action_date_precision`	No	Precision of the extracted action_date: day, month, quarter, year, unstated.
`cursor_published_date`	No	Pagination: 'published_date' from next_cursor (send all three cursor params together).
`cursor_respondent_index`	No	Pagination: 'respondent_index' from next_cursor.

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

First observedSep 6, 2026

TDQS

A4.7/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already establish read-only, idempotent, non-destructive behavior. The description adds meaningful extra context: an API key requirement, the meaning of specific 403 error codes, that one matter can appear once per agency, that monetary relief repeats across respondent rows, and that date filters apply to published_date rather than action_date. This goes well beyond the annotation baseline.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is dense but tightly organized: it starts with the product definition, then explains row semantics, date behavior, deduplication, and auth/error handling. Every sentence carries operational or semantic weight; there is no filler or repetition of schema content.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 28-parameter read-only tool with no output schema, the description covers the essential context: data source scope, row granularity, output field semantics, date-window behavior, deduplication pitfalls, authentication requirements, and error interpretation. Pagination details live in the schema, which is appropriate. An agent has everything needed to select and invoke this tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the schema already documents every parameter clearly. The description adds cross-cutting semantics that the schema cannot express: monetary_relief_usd repeats per respondent row and requires de-duplication on action_key before summing, and nothing links across agencies. This is exactly the kind of parameter-level clarification that helps an agent avoid misaggregation.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a precise resource definition: 'US digital-asset enforcement, one normalized tape across the three agencies' and names the three agencies individually. It clearly differentiates this tool from all sibling financial-data tools by its unique domain and row structure.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives strong usage context: data coverage from 2024+, the 'one row per (action, respondent)' unit, de-duplication guidance before summing monetary relief, and how to interpret 403 errors. It does not explicitly name a sibling alternative, but no sibling appears to overlap with this specialized enforcement dataset, so exclusions are not critical here.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All Alphanume Datasets tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.2/5.0

Disambiguation4/5

Each tool maps to a distinct dataset, and the descriptions are detailed enough to resolve most ambiguity. A few adjacent pairs (S-1 dilution vs. shelf registrations, IV-HV premium vs. IV rank, FDA votes vs. FDA adverse events) share thematic surface area and could be confused by name alone.

Naming Consistency4/5

The overwhelming majority of tools follow a clean get_<noun_phrase> snake_case pattern. The two exceptions, check_api_status and list_market_cap_tickers, are semantically appropriate utility/companion tools but break the otherwise uniform verb prefix.

Tool Count3/5

At 27 tools, the surface is heavy and spans many unrelated financial domains, making selection and prompt context more expensive. Each tool does earn its place as a distinct dataset, but the server would benefit from some consolidation or a higher-level catalog tool.

Completeness4/5

As a read-only datasets API, the surface is broadly complete: status checking, pagination, and one coverage-map companion exist where needed. Minor gaps include the absence of a global dataset catalog/coverage listing and the lack of companion list tools for most other datasets.

Resources

Need Help?