Skip to main content
Glama
riemannzeta

USPTO Patent MCP Server

by riemannzeta

search_litigation

Search over 74,000 US district court patent litigation records by patent number, party name, court, or filing date to identify relevant cases.

Instructions

Search patent litigation cases (74,000+ district court records).

IMPORTANT: The USPTO Patent Litigation API is not available on the Open
Data Portal (api.uspto.gov) and is not listed in the ODP Swagger
catalog. The OCE Patent Litigation dataset is distributed as bulk
downloadable files rather than a live API.

Args:
    query: Full-text search query
    patent_number: Filter by patent number
    plaintiff: Filter by plaintiff name
    defendant: Filter by defendant name
    court: Filter by court/district
    filing_date_from: Date range start (YYYY-MM-DD)
    filing_date_to: Date range end (YYYY-MM-DD)
    offset: Starting position (default: 0)
    limit: Max results (default: 25)

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
courtNo
limitNo
queryNo
offsetNo
defendantNo
plaintiffNo
patent_numberNo
filing_date_toNo
filing_date_fromNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes
Behavior3/5

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

No annotations are provided, so the description carries the full burden of explaining behavior. It adds useful source context (74,000+ district court records, OCE bulk dataset, the API not being available on ODP), but it does not describe return behavior, pagination effects beyond 'limit' and 'offset,' or other operational constraints.

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 efficient and front-loaded with a clear purpose, followed by a concise Args list. The 'IMPORTANT' paragraph about the API not being available is somewhat tangential, but it is brief and provides useful source context without bloating the description.

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

Completeness4/5

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

For a 9-parameter search tool with no schema descriptions and no annotations, the description is largely complete: it covers every parameter's meaning, the data scope, and source limitations. It could be slightly improved by mentioning filter combination behavior and expected result semantics, but an output schema exists to cover return structure.

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

Parameters5/5

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

Schema description coverage is 0%, but the description compensates fully by documenting every parameter: query as full-text, patent_number, plaintiff, defendant, court, filing_date_from/to with YYYY-MM-DD format, offset starting position, and limit max results. This is exactly the semantics needed beyond the raw schema.

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 specific verb and resource: 'Search patent litigation cases (74,000+ district court records).' The word 'search' and the focus on litigation cases clearly distinguish this from sibling get_* tools such as get_litigation_case, get_patent_litigation, and get_party_litigation.

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

Usage Guidelines2/5

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

The description does not provide explicit when-to-use or when-not-to-use guidance relative to sibling tools. It identifies the data source and parameters, but there is no direction such as 'use this for broad searches, use get_litigation_case for a known case ID.'

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/riemannzeta/patent_mcp_server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server