Skip to main content
Glama
john-walkoe

USPTO Final Petition Decisions MCP Server

by john-walkoe
OverviewSchemaRelated ServersScoreDiscussions
Python
Remote

Search_petitions_minimal

Search USPTO final petition decisions using simple parameters like applicant name, decision type, or date ranges to discover relevant petitions quickly.

Instructions

Ultra-fast discovery search for Final Petition Decisions (50-100 results).

NEW: Minimal tier convenience parameters (9 total) - no query syntax needed!

Use for: High-volume petition discovery, finding petitions by applicant, decision type, or date range. Returns: 8 essential fields - petition ID, application number, patent number, applicant name, decision type, petition mail date, decision date, deciding office.

Convenience Parameters:

  • applicant_name: Company/party name (e.g., 'Apple Inc.')

  • application_number: Application number (e.g., '17896175')

  • patent_number: Patent number if granted (e.g., '11788453')

  • decision_type: Outcome (e.g., 'GRANTED', 'DENIED', 'DISMISSED')

  • deciding_office: Office that decided (e.g., 'OFFICE OF PETITIONS')

  • petition_date_start/end: Filing date range (YYYY-MM-DD)

  • decision_date_start/end: Decision date range (YYYY-MM-DD)

Examples:

# Denied petitions for company
fpd_search_petitions_minimal(applicant_name="TechCorp Inc.", decision_type="DENIED", limit=50)

# Hybrid: keywords + convenience
fpd_search_petitions_minimal(query="machine learning", decision_type="DENIED", limit=50)

Progressive Disclosure Workflow:

  1. Use THIS TOOL for discovery with minimal params (50-100 results)

  2. Present top results to user for selection

  3. Use fpd_search_petitions_balanced for detailed analysis (10-20 selected)

    • Balanced tier adds: petition_type_code, art_unit, technology_center, prosecution_status, entity_status

  4. Use fpd_get_petition_details for complete petition data

Cross-MCP Integration:

  • {QueryFieldNames.APPLICATION_NUMBER} -> Links to Patent File Wrapper MCP

  • {QueryFieldNames.PATENT_NUMBER} -> Links to PTAB MCP for post-grant challenges

  • Use balanced tier to get {QueryFieldNames.ART_UNIT} for PFW cross-reference

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
queryNo
limitNo
offsetNo
applicant_nameNo
application_numberNo
patent_numberNo
decision_typeNo
deciding_officeNo
petition_date_startNo
petition_date_endNo
decision_date_startNo
decision_date_endNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Tool Definition Quality

A4.7/5.0
Behavior4/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes key traits: it's a search tool (implied read-only), specifies result limits ('50-100 results'), mentions 'ultra-fast discovery' (performance hint), and details the return format ('8 essential fields'). However, it lacks explicit information on permissions, rate limits, or error handling, which are important for a tool with 12 parameters.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with sections like 'Use for:', 'Returns:', 'Convenience Parameters:', 'Examples:', and 'Progressive Disclosure Workflow,' making it easy to scan. However, it includes some verbose elements like 'NEW: Minimal tier convenience parameters (9 total) - no query syntax needed!' and extensive cross-MCP integration details that, while informative, could be trimmed for conciseness without losing core value.

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?

Given the complexity (12 parameters, no annotations, but has output schema), the description is highly complete. It covers purpose, usage guidelines, parameter details, return fields, examples, workflow integration with sibling tools, and cross-MCP references. The output schema exists, so return values need not be explained in depth, and the description provides enough context for effective tool selection and invocation.

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 compensate fully. It adds significant meaning beyond the schema by explaining all 12 parameters in the 'Convenience Parameters' section with examples (e.g., 'applicant_name': Company/party name), clarifying data types and usage. It also describes the 'query' parameter in examples and mentions 'limit' and 'offset' in the schema, though less explicitly, but overall provides comprehensive parameter semantics.

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 description clearly states the tool performs 'Ultra-fast discovery search for Final Petition Decisions' with '50-100 results,' specifying the verb (search), resource (Final Petition Decisions), and scope (minimal tier). It distinguishes from siblings by emphasizing 'minimal tier convenience parameters' and explicitly mentions the sibling tool 'fpd_search_petitions_balanced' for detailed analysis, making the purpose specific and differentiated.

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 description provides explicit guidance on when to use this tool vs. alternatives. It states 'Use for: High-volume petition discovery' and outlines a 'Progressive Disclosure Workflow' that directs users to start with this tool for discovery, then use 'fpd_search_petitions_balanced' for detailed analysis, and 'fpd_get_petition_details' for complete data. This includes clear when-to-use and alternative tool references.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/john-walkoe/uspto_fpd_mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server