Skip to main content
Glama
riemannzeta

USPTO Patent MCP Server

by riemannzeta
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

ptab_search_proceedings

Read-onlyIdempotent

Search Patent Trial and Appeal Board proceedings such as IPR, PGR, CBM, and derivation to find patent validity challenges by trial type, patent number, party, filing date, or status.

Instructions

Search PTAB trial proceedings (IPR, PGR, CBM, derivation).

USE THIS TOOL WHEN: You need to find patent validity challenges at
the Patent Trial and Appeal Board. Live via USPTO ODP v3.0.

Trial types:
- IPR: Inter Partes Review (most common, based on patents/publications)
- PGR: Post-Grant Review (broader grounds, within 9 months of grant)
- CBM: Covered Business Method (for financial method patents, sunsetted)
- DER: Derivation proceedings

Args:
    query: Full-text search query
    trial_type: Type of trial (IPR, PGR, CBM, DER)
    patent_number: Patent number being challenged
    party_name: Petitioner or patent owner name
    filing_date_from: Filing date range start (YYYY-MM-DD)
    filing_date_to: Filing date range end (YYYY-MM-DD)
    status: Proceeding status (Pending, Instituted, Terminated, FWD Entered)
    offset: Starting position (default: 0)
    limit: Max results (default: 25)

Returns:
    Normalized response with matching proceedings.

Input Schema

NameRequiredDescriptionDefault
limitNo
queryNo
offsetNo
statusNo
party_nameNo
trial_typeNo
patent_numberNo
filing_date_toNo
filing_date_fromNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.8.1
    • changedOutput schema / (root)
      Previous value: -{
-  "properties": {
-    "result": {
-      "additionalProperties": true,
-      "title": "Result",
-      "type": "object"
-    }
-  },
-  "required": [
-    "result"
-  ],
-  "title": "ptab_search_proceedingsOutput",
-  "type": "object"
-}New value: +null
  2. First observedv1.1.1

TDQS

A3.8/5.0
Behavior3/5

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

Annotations already declare the full safety profile (readOnlyHint, idempotentHint, openWorldHint, destructiveHint=false). The description adds provenance ('Live via USPTO ODP v3.0') and trial-type semantics, which is useful, but says nothing about rate limits, auth, pagination behavior, or result shape beyond a one-line 'Returns' note. Net behavioral addition is modest.

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?

Front-loaded with the core action, then organized under Trial types / Args / Returns headers. It is somewhat long because the Args block restates every schema parameter, but each line adds a short clarifying gloss, so little is wasted.

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 nine-optional-parameter search tool with no output schema, the definition covers the domain (trial types), the trigger condition, every parameter, and a brief return summary. Only pagination semantics and result-field detail are thin, which is a minor gap given the low-stakes read-only nature.

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 description coverage is 0%, so the description carries the full burden and mostly meets it: it defines all nine parameters, supplies the status enum values (Pending, Instituted, Terminated, FWD Entered) that the schema lacks, gives the YYYY-MM-DD date format, and states offset/limit defaults. Explanations are terse but genuinely compensate for the empty 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?

States a specific verb ('Search') and resource ('PTAB trial proceedings') and enumerates the four trial types (IPR, PGR, CBM, DER), so an agent knows exactly what domain this covers. It is clearly distinguishable from siblings like ptab_get_proceeding or ptab_search_decisions by the 'proceedings' resource, but it never explicitly contrasts itself with those search siblings.

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 'USE THIS TOOL WHEN: You need to find patent validity challenges at the Patent Trial and Appeal Board' line gives a clear trigger condition. However, it names no alternatives and no when-not-to-use case (e.g., vs ptab_search_decisions or ptab_search_appeals), so routing between the search siblings is left to inference.

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

Deploy Server

Other Tools