USPTO Patent MCP Server

get_office_action_rejections

Read-onlyIdempotent

Retrieve claim-level office action rejection data to identify which claims were rejected, objected to, or allowed, filtered by application, patent, date, statute, case law, art unit, and document code.

Instructions

Get claim-level rejection data from office actions.

USE THIS TOOL WHEN: You need which claims an examiner rejected, objected
to or allowed in each office action, and under which statute (101, 102,
103, 112, double patenting); or claim-level 101 analytics across
applications, such as actions citing Alice or Mayo in an art unit
(case_law="alice", art_unit="3689"). For the action's text, search with
odp_search_office_actions and read it with odp_download_document.

Results come grouped by office action. statutes and case_law describe
the whole action; claims sums up the claim numbers by what happened to
them; claim_groups keeps the dataset's rows (each with action,
legal_section, form paragraph and claims). The rows are extracted by
machine from the action's text, so treat them as a guide and read the
action for anything that matters.

Coverage: actions mailed from 2012 on (93M rows), appearing about a
week after mailing. Pagination counts rows, not actions; an action can
straddle two pages. Continue from metadata.next_offset, not offset +
count: when the token budget drops actions, next_offset points at the
first row of the first one dropped.

Args:
    application_number: Application number without slashes (e.g. "18402543")
    mail_date: Mail date of one action, YYYY-MM-DD
    patent_number: Patent number; resolved to its application first
    document_id: File-wrapper documentIdentifier of one action
    statute: Comma-separated statutes, all of which the action must
        apply: 101, 102, 103, 112, DP (double patenting)
    case_law: Comma-separated cases, all of which the action must cite:
        alice, mayo, myriad, bilski
    document_code: Comma-separated codes, e.g. CTNF (non-final), CTFR (final)
    art_unit: Group art unit (e.g. "3689")
    date_from: Earliest mail date, YYYY-MM-DD
    date_to: Latest mail date, YYYY-MM-DD
    query: Extra Solr clause, AND-ed with the filters
        (e.g. nationalClass:"705")
    offset: Row offset (default: 0)
    limit: Rows to read (default: 50, at most 200)

Returns:
    Office actions with document_id, app_num, document_code, mail_date,
    art_unit, statutes, case_law, claims and claim_groups. total counts
    rows; metadata.next_offset continues the scan.

Input Schema

Name	Required	Description	Default
`limit`	No
`query`	No
`offset`	No
`date_to`	No
`statute`	No
`art_unit`	No
`case_law`	No
`date_from`	No
`mail_date`	No
`document_id`	No
`document_code`	No
`patent_number`	No
`application_number`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed16 schema fields changedv1.8.1Oct 17, 2026

addedInput schema / properties / application_number / anyOf

Added value: +[
+  {
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]

addedInput schema / properties / application_number / default
```
Added value: +null
```
removedInput schema / properties / application_number / type
```
Removed value: -"string"
```

addedInput schema / properties / art_unit

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Art Unit"
+}

addedInput schema / properties / case_law

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Case Law"
+}

addedInput schema / properties / date_from

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Date From"
+}

addedInput schema / properties / date_to

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Date To"
+}

addedInput schema / properties / document_code

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Document Code"
+}

addedInput schema / properties / document_id

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Document Id"
+}

addedInput schema / properties / limit

Added value: +{
+  "default": 50,
+  "title": "Limit",
+  "type": "integer"
+}

addedInput schema / properties / offset

Added value: +{
+  "default": 0,
+  "title": "Offset",
+  "type": "integer"
+}

addedInput schema / properties / patent_number

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Patent Number"
+}

addedInput schema / properties / query

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Query"
+}

addedInput schema / properties / statute

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Statute"
+}

removedInput schema / required

Removed value: -[
-  "application_number"
-]

changedOutput schema / (root)

Previous value: -{
-  "properties": {
-    "result": {
-      "additionalProperties": true,
-      "title": "Result",
-      "type": "object"
-    }
-  },
-  "required": [
-    "result"
-  ],
-  "title": "get_office_action_rejectionsOutput",
-  "type": "object"
-}New value: +null

First observedv1.1.1Aug 19, 2026

TDQS

A4.7/5.0

Behavior4/5

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

Annotations already cover read-only, idempotent and non-destructive behavior, so the description focuses on what annotations cannot express: row-level machine extraction with a caution to verify against the action text, coverage starting 2012 with roughly a one-week indexing lag, and the non-obvious pagination rule that tokens count rows, not actions. That is substantial added context; the only gap is no mention of rate limits or auth.

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 purpose and usage before parameters, and nearly every sentence carries information an agent could not get elsewhere. It is long, and the 'Results come grouped' paragraph overlaps slightly with the 'Returns' block, which is the only real trimming opportunity.

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, no enums and 13 undocumented params, the description supplies the missing return shape (document_id, statutes, case_law, claims, claim_groups, total, metadata.next_offset), the pagination continuation rule, and the data-coverage and reliability caveats. Nothing an agent needs to call and interpret this correctly is absent.

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 coverage is 0% and the schema is bare (13 title-only params), so the description carries the full burden and does: it gives formats (application number without slashes, YYYY-MM-DD dates), enumerates accepted values (101/102/103/112/DP; alice/mayo/myriad/bilski), explains comma-separated semantics as AND-across-values, clarifies limit's 200 cap, and shows what an extra Solr query clause looks like.

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 (claim-level rejection data from office actions) and immediately scopes it against siblings by naming odp_search_office_actions and odp_download_document for action text. An agent can distinguish it from those tools without opening any 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?

Explicit 'USE THIS TOOL WHEN' block gives both a per-action use case and an aggregate analytics use case, complete with a concrete example (case_law="alice", art_unit="3689"). It also names the alternative tools for the overlapping need (reading the action's text) and routes the agent there.

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

Deploy Server

get_office_action_rejections

Instructions

Input Schema

Schema Changelog

TDQS

Other Tools