USPTO Patent MCP Server

get_office_action_citations

Read-onlyIdempotent

Retrieve examiner-cited prior art references from USPTO office actions by application, patent, document, or cited reference, including 102/103 legal section, and reverse-lookup citing applications.

Instructions

Get the prior art examiners cited in office actions.

USE THIS TOOL WHEN: You need the references an examiner cited against
an application, and under which statute (102 or 103); or, in reverse,
which applications' office actions cited a given patent or publication
(cited_reference="US 2013/0120945 A1"). For citations on an issued
patent's front page, ppubs_get_patent_by_number(sections=["biblio"])
is cheaper; for later patents citing it, ppubs_get_citing_patents.

Coverage: office actions from about 2012 on; rows appear about a week
after mailing. Rows carry no mail date, so mail_date (with an
application or patent number) finds that day's actions in the
rejection dataset first.

Args:
    application_number: Application number without slashes (e.g. "18402543")
    mail_date: Mail date of one action, YYYY-MM-DD (needs
        application_number or patent_number)
    patent_number: Patent number; resolved to its application first
    document_id: File-wrapper documentIdentifier of one action
    cited_reference: A cited US patent or publication number, with or
        without "US", separators or kind code
    legal_section: Comma-separated sections the reference was applied
        under: 102, 103
    examiner_cited: True for references the examiner cited
    art_unit: Group art unit (e.g. "1798")
    tech_center: Technology center (e.g. "1700")
    query: Extra Solr clause, AND-ed with the filters
    offset: Row offset (default: 0)
    limit: Rows to read (default: 50, at most 200)

Returns:
    Citations with app_num, document_id, reference (as written),
    reference_number (digits, when USPTO parsed them), legal_section,
    action, examiner_cited, applicant_cited, relied_on_in_action,
    art_unit and tech_center.

Input Schema

Name	Required	Description	Default
`limit`	No
`query`	No
`offset`	No
`art_unit`	No
`mail_date`	No
`document_id`	No
`tech_center`	No
`legal_section`	No
`patent_number`	No
`examiner_cited`	No
`cited_reference`	No
`application_number`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed15 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 / cited_reference

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

addedInput schema / properties / document_id

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

addedInput schema / properties / examiner_cited

Added value: +{
+  "anyOf": [
+    {
+      "type": "boolean"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Examiner Cited"
+}

addedInput schema / properties / legal_section

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

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 / tech_center

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

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_citationsOutput",
-  "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 only cover the read-only/idempotent/open-world profile, so the description adds real operational context: data starts around 2012, rows lag mailing by about a week, and rows contain no mail date, plus the workaround of using the rejection dataset to pin down the day. Missing rate limits and nothing on behavior when no filter is supplied, which keeps it out of the top score.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loads the one-line purpose, then routes with when-to-use and cheaper alternatives, then coverage caveats, then args, then returns. Because the schema itself has zero field descriptions, the per-argument block is not redundant and every sentence earns its place.

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?

The returns fields are enumerated in prose (necessary since there is no output schema), coverage limits are disclosed, and all filters are explained. The one unaddressed case is that zero parameters are required, yet nothing says whether an unfiltered call is valid or would sweep the whole corpus; a note on that (and on offset/limit paging behavior) would make it fully complete.

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%, so the description carries the full burden and does: it documents all 12 parameters with formats ('18402543' without slashes, YYYY-MM-DD), inter-parameter dependencies (mail_date needs application_number or patent_number), accepted input variants for cited_reference, the meaning of legal_section values, and the 200-row cap on limit.

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+resource (retrieve prior-art references examiners cited in office actions) and explicitly separates itself from the nearest siblings get_office_action_rejections, ppubs_get_citing_patents and ppubs_get_patent_by_number. The reverse-lookup mode (which applications cited a given reference) is called out, so an agent can identify the tool without reading 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?

A dedicated 'USE THIS TOOL WHEN' block gives both forward and reverse lookup conditions, and names cheaper alternatives with the exact condition that selects them (front-page citations -> ppubs_get_patent_by_number(sections=["biblio"])). Nothing about when-to-use or when-to-use-something-else 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

get_office_action_citations

Instructions

Input Schema

Schema Changelog

TDQS

Other Tools