Skip to main content
Glama
riemannzeta

USPTO Patent MCP Server

by riemannzeta
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

odp_get_documents

Read-onlyIdempotent

List documents in a patent application's file wrapper—office actions, responses, notices of allowance, claims, IDS forms, and examiner citations—and return IDs for downloading.

Instructions

List the documents in an application's file wrapper (prosecution history).

USE THIS TOOL WHEN: You need to find office actions, responses,
notices of allowance, claims, IDS forms or examiner citations for an
application, then read one with odp_download_document.

Args:
    app_num: Application number without slashes (e.g., "14412875")
    document_code: Comma-separated USPTO document codes to keep. Common
           ones: CTNF (non-final rejection), CTFR (final rejection),
           NOA (notice of allowance), REM (applicant remarks/arguments),
           CLM (claims), SPEC (specification), IDS and 1449 (applicant
           citations), 892 (examiner citations), ADS, N417 (EFS receipt).
           `metadata.code_counts` in any response lists every code in
           the wrapper.
    direction: "INCOMING" (from applicant), "OUTGOING" (from USPTO) or
           "INTERNAL" (examiner search notes etc.)
    offset: Starting position within the filtered list (default: 0)
    limit: Max documents to return (default: 50)

Returns:
    Documents newest first, each with documentIdentifier (pass it to
    odp_download_document), documentCode, description, officialDate,
    directionCategory, page count and available formats.

Input Schema

NameRequiredDescriptionDefault
limitNo
offsetNo
app_numYes
directionNo
document_codeNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed5 schema fields changedv1.8.1
    • addedInput schema / properties / direction
      Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Direction"
+}
    • addedInput schema / properties / document_code
      Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Document Code"
+}
    • addedInput schema / properties / limit
      Added value: +{
+  "default": 50,
+  "title": "Limit",
+  "type": "integer"
+}
    • addedInput schema / properties / offset
      Added value: +{
+  "default": 0,
+  "title": "Offset",
+  "type": "integer"
+}
    • changedOutput schema / (root)
      Previous value: -{
-  "properties": {
-    "result": {
-      "additionalProperties": true,
-      "title": "Result",
-      "type": "object"
-    }
-  },
-  "required": [
-    "result"
-  ],
-  "title": "odp_get_documentsOutput",
-  "type": "object"
-}New value: +null
  2. First observedv1.1.1

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already declare read-only, idempotent, open-world, non-destructive behavior. The description goes further by describing sort order (newest first), returned fields (documentIdentifier, documentCode, dates, page count, formats), pagination via offset/limit, direction categories, and metadata.code_counts, adding substantial context beyond the annotations.

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 purpose, then usage, args, and returns, with clear headings. The document-code examples are lengthy but directly useful for an undocumented parameter; no sentence is redundant.

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?

No output schema exists, but the description describes the return shape and key fields. For a 5-param listing tool with rich annotations and complex filtering, the description supplies enough context about arguments, behavior, and return format to call it correctly.

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% and the schema provides no descriptions or enums, so the description carries the full burden. It defines app_num format, explains document_code syntax and lists common codes, specifies direction values, and gives defaults for offset and limit—compensating completely.

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 ('List') and resource ('documents in an application's file wrapper'), and disambiguates from the download tool by naming odp_download_document as the read step. An agent can identify this as the prosecution-history listing 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 Guidelines4/5

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

Provides an explicit 'USE THIS TOOL WHEN' section enumerating document types and names the follow-up tool for reading a single document. It does not say when to prefer this over sibling search tools like odp_search_office_actions, nor does it state when not to use it, so it falls short of full when/when-not/alternatives coverage.

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