Skip to main content
Glama
riemannzeta

USPTO Patent MCP Server

by riemannzeta
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

ppubs_search_applications

Read-onlyIdempotent

Search published US patent applications in Patent Public Search to find pre-grant filings before grant. Use query syntax, pagination, and sorting to retrieve application results.

Instructions

Search published US patent applications in Patent Public Search.

USE THIS TOOL WHEN: You need to search pre-grant published applications
(applications publish 18 months after filing, before grant).

Args:
    query: Search query using USPTO BRS syntax (same as
           ppubs_search_patents). Multi-word terms are AND-ed —
           quote phrases that must appear together (e.g.
           '"machine learning"'). Field qualifiers are dotted
           suffixes (.ti., .ab., .in., .as., .cpc.) — the legacy
           slash-prefix forms (TTL/, IN/) no longer work.
    offset: Starting position for pagination (default: 0)
    limit: Maximum results to return (default: 20, max: 500). Results
           over the token budget are cut to 20 anyway, so raise this
           only when paging with `offset`.
    sort: Sort order (default: "date_publ desc")

Returns:
    Normalized response with application results.

Input Schema

NameRequiredDescriptionDefault
sortNodate_publ desc
limitNo
queryYes
offsetNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv1.8.1
    • changedInput schema / properties / limit / default
      Previous value: -100New value: +20
    • changedOutput schema / (root)
      Previous value: -{
-  "properties": {
-    "result": {
-      "additionalProperties": true,
-      "title": "Result",
-      "type": "object"
-    }
-  },
-  "required": [
-    "result"
-  ],
-  "title": "ppubs_search_applicationsOutput",
-  "type": "object"
-}New value: +null
  2. First observedv1.1.1

TDQS

A4.5/5.0
Behavior4/5

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

Annotations already declare readOnly/idempotent/open-world/non-destructive, so the safety profile is covered. The description still adds real behavioral context: the 18-month publication timeline, the token-budget truncation to 20 results, and the deprecation of legacy TTL//IN/ qualifier syntax. It doesn't describe pagination edge behavior or error conditions.

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 purpose sentence, then labeled WHEN/Args/Returns blocks. Every sentence carries load — the syntax warnings and token-budget caveat are the kind of detail an agent needs to invoke correctly, not padding.

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?

No output schema exists, and the description only says 'Normalized response with application results', which is thin on return shape. However, for a search tool with annotations covering safety and thorough arg documentation, everything needed to make a correct call is present.

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 four params: BRS dotted field qualifiers with deprecated forms called out, AND-ed multi-word semantics with quoting guidance, offset's pagination role, limit's default/max plus the token-budget caveat, and the sort default. This is well beyond a baseline compensation.

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 (search published US patent applications) and immediately scopes it to pre-grant publications that appear 18 months after filing, before grant. This clearly distinguishes it from ppubs_search_patents and from the odp_search_applications family without needing 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?

A dedicated 'USE THIS TOOL WHEN' block gives an explicit triggering condition (need pre-grant published applications), and the args note points to ppubs_search_patents as the syntax-equivalent sibling. It stops short of an explicit negative rule (e.g. 'for granted patents use X instead'), so it doesn't reach a full 5.

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