Skip to main content
Glama
riemannzeta

USPTO Patent MCP Server

by riemannzeta
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

odp_search_office_actions

Read-onlyIdempotent

Search examiner-written office actions across USPTO applications by full text, statute (101/102/103/112), art unit, document code, or mail date, and count results via facets.

Instructions

Search office actions across all applications by what the examiner wrote.

USE THIS TOOL WHEN: You need to find office actions across many
applications by their text ("means-plus-function", "Alice",
"inherent anticipation"), by statute (101/102/103/112), by art unit
or by date, or to count them. metadata.facets gives document-code and
rejection-type counts for the whole match set, so limit=1 answers
"how many 101 rejections did art unit 3689 issue in 2026" in one call.
For one application's history, odp_get_documents is cheaper.

IMPORTANT: text_preview holds only the first 500 characters. The API
searches the full text but returns no more. To read a hit, pass its
app_num and document_id to odp_download_document(format="text").

Coverage: office actions mailed from mid-2007 on (19.9M records).
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 officeActionText:"printed matter"
    app_num: Application number without slashes (e.g. "18402543")
    patent_number: Patent number; resolved to its application first
    document_code: Comma-separated codes: CTNF (non-final rejection),
           CTFR (final rejection), NOA (allowance), CTRS (restriction),
           CTAV (advisory), APEA (examiner's answer), PETDEC
    rejection_type: Comma-separated statutes, all of which must apply:
           101, 102, 103, 112, DoublePatent, Other
    art_unit: Group art unit (e.g. "3689")
    date_from: Earliest mail (submission) date, YYYY-MM-DD
    date_to: Latest mail (submission) date, YYYY-MM-DD
    record_id: officeActionRecordIdentifier from an earlier result
    sort: "newest" (default) or "oldest" by mail date
    offset: Starting position (default: 0)
    limit: Max results (default: 25, at most 100)

Returns:
    Office actions with record_id, app_num, document_code, description,
    submission_date, art_unit, title, rejection_types, document_id and
    text_preview, plus metadata.facets.

Input Schema

NameRequiredDescriptionDefault
sortNonewest
limitNo
queryNo
offsetNo
app_numNo
date_toNo
art_unitNo
date_fromNo
record_idNo
document_codeNo
patent_numberNo
rejection_typeNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.8.1

TDQS

A5/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), so the bar is lower, yet the description adds substantial non-obvious behavior: text_preview is capped at 500 characters while the API still searches full text, coverage starts mid-2007 with 19.9M records, typed filters are AND-ed versus Lucene OR, and metadata.facets enables counting with limit=1. It even routes the agent to odp_download_document(format="text") to read a hit.

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?

The description is long but front-loaded and sectioned (purpose, USE THIS TOOL WHEN, IMPORTANT caveat, Coverage, Args, Returns). Every sentence is load-bearing given 0% schema coverage and no output schema; nothing is repeated from structured fields.

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, the Returns block enumerates the returned fields and metadata.facets; with 12 undocumented params, the Args block documents each. Caveats, coverage window, alternative tools, and result-reading workflow are all present, so an agent has everything needed 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%, so the description carries the full burden and does so for all 12 parameters: format examples for app_num, the patent-to-application resolution, the enumerated document_code values (CTNF/CTFR/NOA/CTRS/CTAV/APEA/PETDEC), the rejection_type list, date format, sort values, and limit/offset defaults with the 100 cap. This adds meaning far beyond the bare schema.

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?

The first line states a specific verb+resource+scope: search office actions across all applications by examiner text. It explicitly differentiates from the sibling odp_get_documents ("For one application's history, odp_get_documents is cheaper"), so an agent can route between them without opening either 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?

The "USE THIS TOOL WHEN" block enumerates concrete triggering conditions (free text, statute, art unit, date, counting) and names the cheaper alternative with the condition that selects it. It also explains the AND/OR filter semantics, which directly affects whether an agent uses this tool or builds a Lucene query.

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