Skip to main content
Glama
Sign In
USPTO Patent MCP Server

USPTO Patent MCP Server

by riemannzeta
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

odp_get_transactions

Read-onlyIdempotent

Retrieve a patent application's prosecution transaction history, including office actions, responses, and fee payments, to trace the complete timeline by application number.

Instructions

Get prosecution transaction history for an application.

USE THIS TOOL WHEN: You need the complete timeline of prosecution
events including office actions, responses, and fee payments.

Args:
    app_num: Application number without slashes (e.g., "14412875")

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "app_num": "<app_num>"
    },
    "name": "odp_get_transactions"
  }
}

Input Schema

NameRequiredDescriptionDefault
app_numYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.8.1
    • changedOutput schema / (root)
      Previous value: -{
-  "properties": {
-    "result": {
-      "additionalProperties": true,
-      "title": "Result",
-      "type": "object"
-    }
-  },
-  "required": [
-    "result"
-  ],
-  "title": "odp_get_transactionsOutput",
-  "type": "object"
-}New value: +null
  2. First observedv1.1.1

TDQS

A3.9/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=true, so the safety and repeatability profile is covered. The description adds useful content scope (what event types are included) but says nothing about pagination, result volume, or whether the full history is always returned — modest added value over 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?

Two short blocks with zero filler: the purpose sentence first, then the selection trigger, then the argument format. Every line earns its place and the reader gets the essential facts immediately.

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?

For a single-parameter read tool with no output schema, the description covers purpose, selection trigger, and argument format adequately, and its enumeration of event types substitutes partially for a missing return schema. The remaining gap — result size/pagination behavior — is minor given the annotations and tool simplicity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must carry the parameter burden, and it does: it specifies the format ('without slashes') and gives a concrete example ('14412875'), which is exactly the kind of detail the bare schema lacks. It does not add anything further, but for a single required string parameter this is sufficient.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource: 'Get prosecution transaction history for an application.' The parenthetical content (office actions, responses, fee payments) clarifies the resource scope, distinguishing it reasonably from sibling tools like odp_get_documents or odp_search_office_actions, though it never names those siblings explicitly.

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?

The 'USE THIS TOOL WHEN' block gives a clear selection condition — needing the complete prosecution timeline rather than a subset of events. It provides positive guidance but no when-not condition and does not point to alternatives such as odp_get_documents for actual document retrieval.

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