Skip to main content
Glama
riemannzeta

USPTO Patent MCP Server

by riemannzeta
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

odp_search_petition_decisions

Read-onlyIdempotent

Search USPTO petition decisions on revival, maintenance-fee reinstatement, priority, and examiner review. Filter by outcome, petition type, or deciding office to check grant rates.

Instructions

Search USPTO decisions on patent petitions.

USE THIS TOOL WHEN: You need petition decisions on reviving abandoned
applications, reinstating patents after a missed maintenance fee,
delayed priority claims, petitions to make special, or supervisory
review of an examiner, or want to see how the Office of Petitions has
ruled on an argument (search its text with `query`). metadata.facets
gives outcome, deciding-office and petition-type counts for the whole
match set, so grant rates take one call.

Coverage: 1.1M decisions, 1991 on. The text is OCR and can be noisy
("EENITED STATES"), so prefer single terms or proximity
(ocrSearchText:"unintentional delay"~3) to long exact phrases. Typed
filters are AND-ed; pass a Lucene string in `query` for OR.

Args:
    query: Lucene query; bare words search everything, or name a field
           such as ocrSearchText:"unintentional delay"
    app_num: Application number without slashes
    patent_number: Patent number
    petition_type: Numeric petition type code (e.g. "533", reinstate
           patent for delayed maintenance fee) or words from its
           description (e.g. "revive")
    outcome: GRANTED, GRANTED-IN-PART, DENIED or DISMISSED
    deciding_office: e.g. "Office of Petitions", "Technology Center",
           "International Division"
    technology_center: e.g. "2600"
    date_from: Earliest decision date, YYYY-MM-DD
    date_to: Latest decision date, YYYY-MM-DD
    final_only: Only decisions marked final agency action (in the data
           so far, exactly the DENIED decisions)
    record_id: petitionDecisionRecordIdentifier from an earlier result
    include_full_text: Add each decision's full OCR text as full_text
           (about 1.5-3k characters each, prefixed by the record's
           metadata). Off by default.
    sort: "newest" (default) or "oldest" by decision date
    offset: Starting position (default: 0)
    limit: Max results (default: 25, at most 100)

Returns:
    Decisions with record_id, app_num, patent_number, dates, petition
    type, outcome, deciding office, final_decision, text (an excerpt,
    with query matches marked «like this») and documents (pass a
    documentIdentifier and app_num to odp_download_document with
    format="text" for the decision letter), plus metadata.facets.

Input Schema

NameRequiredDescriptionDefault
sortNonewest
limitNo
queryNo
offsetNo
app_numNo
date_toNo
outcomeNo
date_fromNo
record_idNo
final_onlyNo
patent_numberNo
petition_typeNo
deciding_officeNo
include_full_textNo
technology_centerNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.8.1

TDQS

A4.9/5.0
Behavior5/5

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, openWorld), but the description layers on substantial non-obvious behavior: 1.1M records from 1991, OCR noise with a concrete degraded example ('EENITED STATES') and a proximity-search workaround, facet-based grant-rate aggregation in one call, the exact meaning of final_only (currently the DENIED set), and the ~1.5-3k character cost per record for include_full_text.

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?

Well front-loaded and organized under Purpose / When / Coverage / Args / Returns headings, with no filler sentences. It is long, but nearly all of that length is load-bearing documentation for 15 undescribed parameters, so the size is defensible rather than padded.

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?

Despite no output schema, the 'Returns' section describes the returned fields (record_id, dates, petition type, outcome, deciding office, final_decision, marked-up text excerpt) and includes the hand-off to odp_download_document using documentIdentifier plus app_num for the full decision letter. Nothing needed to call or chain this tool is missing.

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% across 15 parameters, so the description carries the full burden and does so: every parameter is documented with format, examples, and semantics (app_num without slashes, petition_type as numeric code or description words, outcome enumerations, date format YYYY-MM-DD, record_id provenance, sort/offset/limit defaults and the 100 cap).

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?

States a specific verb and resource ('Search USPTO decisions on patent petitions') and immediately scopes it to the Office of Petitions domain, which cleanly separates it from siblings like ptab_search_decisions, ptab_search_appeals, and odp_search_office_actions. An agent can identify the correct tool without opening the schema.

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

Usage Guidelines5/5

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

An explicit 'USE THIS TOOL WHEN' block enumerates the concrete petition scenarios (revival of abandoned applications, reinstatement after missed maintenance fee, delayed priority claims, petitions to make special, supervisory review). It further tells the agent when to use `query` (searching argument text) and when typed filters suffice, plus the OR vs AND semantics that decide between the two paths.

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