Skip to main content
Glama
riemannzeta

USPTO Patent MCP Server

by riemannzeta
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

ppubs_get_patent_by_number

Read-onlyIdempotent

Retrieve a granted patent's full text or selected sections—biblio, abstract, claims, description—by patent number. Use it to answer patent questions while controlling token size.

Instructions

Get a granted patent's full text by patent number.

USE THIS TOOL WHEN: You know the patent number and need the patent
text. A whole document runs 20-40k tokens, most of it the
description — ask for `sections` when you need less.

Args:
    patent_number: Patent number. Separators, a leading "US" and a
           kind code are ignored, and design/reissue/plant prefixes
           are kept: "7123456", "US 10,000,000 B2", "D845123",
           "RE49123" all work.
    sections: Which parts to return; omit for everything. Any of
           "biblio" (front-page data: parties, dates, classification,
           references cited), "abstract", "claims", "description".
           ["biblio", "claims"] answers most questions in ~5k tokens.

Returns:
    Patent document with the requested sections. Empty fields and
    search highlight fields are dropped.

Input Schema

NameRequiredDescriptionDefault
sectionsNo
patent_numberYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv1.8.1
    • addedInput schema / properties / sections
      Added value: +{
+  "anyOf": [
+    {
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Sections"
+}
    • changedOutput schema / (root)
      Previous value: -{
-  "properties": {
-    "result": {
-      "additionalProperties": true,
-      "title": "Result",
-      "type": "object"
-    }
-  },
-  "required": [
-    "result"
-  ],
-  "title": "ppubs_get_patent_by_numberOutput",
-  "type": "object"
-}New value: +null
  2. First observedv1.1.1

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint and non-destructive behavior, so the safety profile is covered. The description adds genuinely useful non-annotation context: a whole document is 20-40k tokens dominated by the description, and empty/highlight fields are dropped from the response. That token-budget guidance is exactly the kind of behavioral cost disclosure an agent needs to plan a call.

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-loaded with the one-line purpose, then clearly delimited USE THIS TOOL WHEN, Args and Returns blocks. No sentence is filler: the token-cost aside and the per-value section explanations all change how an agent would invoke the tool.

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 only two parameters, no output schema, and annotations covering safety, this description supplies everything needed to call correctly: the required identifier's accepted formats, the optional filter's vocabulary, expected document size, and what is trimmed from the result. Nothing material is missing.

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 must carry the full parameter burden, and it does. It spells out normalization rules for `patent_number` (separators, leading 'US' and kind codes ignored; design/reissue/plant prefixes kept) with four worked examples, and enumerates every legal value of `sections` with meaning and a concrete recommended combination.

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 a granted patent's full text by patent number.' An agent immediately knows what it retrieves. It does not, however, distinguish itself from the sibling ppubs_get_full_document, which sounds like it may overlap, so it falls short of the sibling-differentiation bar for a 5.

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: You know the patent number and need the patent text' block gives an explicit trigger condition, and the token note routes the agent toward the `sections` parameter for lighter calls. It never names an alternative sibling (e.g. ppubs_search_patents or ppubs_get_full_document) or states when NOT to use it, so it is clear context without exclusions.

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