Skip to main content
Glama

Probative legal-marketing data

This connector has been deprecated

Duplicate listing. The maintained listing for this server is Probative legal-marketing data, synced with the official MCP Registry entry com.probativegrowth/legal-marketing-data. Same endpoint: https://probativegrowth.com/mcp

Federal MDL dockets by actions pending

list_mdl_dockets
Read-onlyIdempotent

Federal multidistrict litigation (MDL) dockets from the Judicial Panel on Multidistrict Litigation's monthly pending-dockets reports, largest first: the docket number, title, court district, actions pending on the report date, total actions, and the change over the past year. Filter by words in the title (for example "hair relaxer" or "talcum") or ask for one docket (MDL-2738) to get its monthly history since 2019. Counts are court actions, not people. Paginated with cursor. Results summarize public sources for marketing planning; they are not legal advice.

Input Schema

NameRequiredDescriptionDefault
limitNoRecords per page (1 to 25)
queryNoWords in the docket title or court, e.g. "hernia mesh"
cursorNoThe nextCursor from the previous page; leave out for the first page
detailNosummary (default): each record as its id, a 1-2 sentence text, status, date checked, one source URL and the page to cite. full: every field, every source and the per-record provenance.summary
docketNoOne docket, e.g. MDL-2738 or 2738; returns its monthly history

Output Schema

NameRequiredDescriptionDefault
metaYesCredit line (attribution), citation, DOI, version, license (CC BY 4.0), disclaimer, notice and the page to cite
nextCursorNoPass as `cursor` to get the next page; null on the last page
provenanceYesWhere this came from: the publisher of the dataset, the dataset and its version DOI, the record id, the original source (who published it and its URL), the day that source was last checked, and when this answer was retrieved

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • addedInput schema / properties / detail
      Added value: +{
      +  "default": "summary",
      +  "description": "summary (default): each record as its id, a 1-2 sentence text, status, date checked, one source URL and the page to cite. full: every field, every source and the per-record provenance.",
      +  "enum": [
      +    "summary",
      +    "full"
      +  ],
      +  "type": "string"
      +}
    • changedInput schema / properties / limit / default
      Previous value: -10New value: +5
  2. Added

TDQS

A4.1/5.0
Behavior4/5

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

Annotations already confirm this is a safe, read-only, idempotent, non-destructive, closed-world operation. The description adds useful behavioral context beyond annotations: results are ordered largest first, counts represent court actions rather than people, pagination uses a cursor, and the content is summarized public-source material for marketing planning rather than legal advice.

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

Conciseness4/5

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

The description is a single dense paragraph that front-loads the source, scope, and ordering before moving into filtering and behavioral notes. It is appropriately sized for a tool with five optional parameters, though the legal and marketing disclaimers add a little length.

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?

Given that an output schema exists, the definition covers what an agent needs: the data source, default ordering, returned fields, filtering behavior, single-docket history mode, pagination, and the meaning of counts. No critical context for correct invocation appears missing.

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 baseline is 3. The description adds meaning beyond the schema by giving examples for title-word filtering, explaining that a specific docket returns monthly history since 2019, and confirming cursor-based pagination. It does not elaborate on every parameter, but it meaningfully supplements the already complete schema.

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

Purpose4/5

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

The description clearly states that this tool lists federal MDL dockets from JPML monthly pending-docket reports, including the fields returned and default ordering. It is specific and actionable, though it does not explicitly differentiate from sibling tools because none of the listed siblings appear to cover the same resource.

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 clear usage context: filter by title words, or request a single docket to retrieve its monthly history since 2019. It also notes pagination. It does not name alternatives or explicit when-not-to-use conditions, but no close sibling alternative is apparent.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources