Skip to main content
Glama

MORVS

by ai.morvs.api
OverviewDiscussionsAdmin

Find Multidistrict Litigation

mdl_lookup
Read-onlyIdempotent

Find a federal multidistrict litigation (MDL) in the MORVS Mass Lawsuit Register by MDL number, caption word, or company word appearing in the Panel caption. Returns the Panel caption, category, district, transfer date, pending and total actions, the last 12 monthly pending counts, and terminated entries when available. Actions are lawsuits, not people. Centralisation is not a finding on the merits. A falling pending count is not a settlement or payout. A missing match only means no matching MDL was found in the published register.

Input Schema

NameRequiredDescriptionDefault
limitNoMaximum MDLs returned; default 20, allowed 1-100. Actions are lawsuits, not people.
queryYesRequired MDL number, caption word or company word as printed in the Panel caption, at most 80 characters.
statusNoOptional published MDL status; defaults to all statuses. Centralisation is not a finding.
categoryNoOptional category assigned by the Panel, not a conclusion about the cases.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changed
    • removedInput schema / properties / category / enum
      Removed value: -[
-  "Products Liability",
-  "Common Disaster",
-  "Antitrust",
-  "Miscellaneous",
-  "Securities",
-  "Data Breach and Consumer Privacy",
-  "Employment Practices",
-  "Sales Practices",
-  "Intellectual Property",
-  "Contract",
-  "Air Disaster"
-]
    • addedInput schema / properties / category / maxLength
      Added value: +80
    • addedInput schema / properties / category / minLength
      Added value: +1
    • addedInput schema / properties / category / pattern
      Added value: +"^[A-Z][A-Za-z0-9,&'/().-]*(?: [A-Za-z0-9,&'/().-]+)*$"
  2. Added

TDQS

A4.4/5.0
Behavior5/5

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

Annotations cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the description adds genuine value on top: it enumerates the returned fields (Panel caption, category, district, transfer date, pending/total actions, 12 monthly pending counts, terminated entries), flags optional availability of terminated entries, and pre-empts four specific misinterpretations (actions ≠ people, centralisation ≠ merits ruling, falling counts ≠ settlement, no match ≠ no MDL exists). That is substantial disclosure beyond structured fields.

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?

Purpose and return fields are front-loaded in the first two sentences, and the caveat sentences are short and scannable. However, 'Actions are lawsuits, not people' duplicates the limit parameter's schema description and 'Centralisation is not a finding' duplicates the status parameter's, so a few clauses are redundant rather than additive.

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?

With no output schema, the description carries the return-value burden and does so by listing the exact fields returned and the availability caveat for terminated entries. For a four-parameter read-only lookup, nothing an agent needs to call it or interpret its result is missing.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema already documents query, limit, status, and category fully. The description reinforces the query semantics ('caption word, or company word appearing in the Panel caption') but adds nothing about limit bounds, the status enum values, or the category pattern — it only loosely gestures at status via 'terminated entries when available.' Baseline 3 applies.

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?

Specific verb ('Find') plus specific resource ('federal multidistrict litigation (MDL) in the MORVS Mass Lawsuit Register'), followed by the exact lookup keys accepted (MDL number, caption word, company word). An agent immediately knows this is an MDL-registry lookup and not a general case search, distinguishing it from siblings like courts_by_party or federal_file_search.

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 querying context — what kinds of terms can be supplied and how results are scoped — and explains that a missing match means only 'no matching MDL in the published register,' which prevents an agent from misreading an empty result. It does not name an alternative sibling or state when NOT to use this tool, so it falls short of the explicit routing seen in the top calibration example.

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

All MORVS toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources