USPTO Final Petition Decisions MCP Server

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.0
Disambiguation5/5
Each tool has a clearly distinct purpose with no overlap: search functions target different scopes (minimal, balanced, by application, by art unit), get_petition_details retrieves full details, get_document_content extracts text, get_document_download provides download links, and get_guidance offers contextual help. The descriptions explicitly differentiate their use cases, preventing misselection.
Naming Consistency5/5
All tool names follow a consistent 'fpd_' prefix with snake_case and descriptive verb_noun patterns (e.g., fpd_search_petitions_minimal, fpd_get_petition_details). The naming is uniform across all eight tools, making them predictable and easy to understand at a glance.
Tool Count5/5
With 8 tools, the server is well-scoped for USPTO petition analysis, covering search (4 variants), detail retrieval, document access (content and download), and guidance. Each tool serves a specific role in the workflow, from discovery to deep analysis, without redundancy or bloat.
Completeness5/5
The tool set provides complete coverage for the domain: multiple search options for discovery, detailed petition retrieval, document extraction and download for full access, and guidance for workflow optimization. There are no gaps in the CRUD/lifecycle for petition analysis, enabling agents to handle end-to-end tasks without dead ends.
Average 4.7/5 across 8 of 8 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 1 commit in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

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 read-only operation (implied by 'get'), offers token reduction benefits (80-95%), and provides targeted guidance. However, it lacks details on potential errors, rate limits, or authentication requirements, which prevents a score of 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with a clear purpose and quick reference, but it includes repetitive or verbose elements, such as listing sections twice (in the quick reference and 'Available sections') and adding marketing-like benefits (e.g., 'Context Efficiency Benefits'). Some sentences could be trimmed without losing essential information.
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 tool's low complexity (1 parameter, no annotations, but with an output schema), the description is complete enough. It explains the purpose, usage, parameters, and benefits, and since an output schema exists, it doesn't need to detail return values. The description adequately covers what users need to know to invoke the tool 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?
The input schema has 0% description coverage for its single parameter 'section', but the description compensates fully by listing all available sections (e.g., 'overview', 'workflows_pfw') with brief explanations. This adds significant meaning beyond the schema, making the parameter's purpose and options clear to users.
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?
The description clearly states the tool's purpose: to 'Get selective USPTO FPD guidance sections for context-efficient workflows.' It specifies the verb ('get'), resource ('USPTO FPD guidance sections'), and benefit ('context-efficient workflows'). However, it doesn't explicitly distinguish this tool from its siblings (e.g., document-focused tools like FPD_get_document_content_with_mistral_ocr), which would be needed for a score of 5.
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 versus alternatives through the 'QUICK REFERENCE' section, which maps specific questions (e.g., 'Find petitions by company/art unit') to recommended sections (e.g., 'tools'). It also lists all available sections with brief descriptions, helping users select the appropriate one based on their workflow needs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 critical behavioral traits: the proxy requirement for document URLs, the mandatory workflow steps when include_documents=True, and what the tool returns (petition fields, document metadata, legal context, timeline). However, it doesn't mention error conditions, rate limits, or authentication needs.
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 clear sections (critical warnings, workflow, use cases, returns, document access, parameters). Every sentence adds value, though the workflow section is somewhat lengthy. It's appropriately sized for a complex tool with critical dependencies.
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?
Given the tool's complexity (document access workflow, proxy requirement) and the presence of an output schema, the description is mostly complete. It covers purpose, usage, critical behaviors, and parameter semantics. The output schema handles return value details, so the description appropriately focuses on workflow and context rather than repeating output structure.
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?
With 0% schema description coverage, the description must compensate for the schema's lack of parameter documentation. It adds meaningful semantics: petition_id is 'Petition decision record identifier (UUID from search results)' and include_documents 'Include documentBag with file metadata (default True).' This provides crucial context about parameter sources and effects, though it could elaborate more on the documentBag structure.
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's purpose: 'Get complete details for a specific petition by petition ID (UUID).' It specifies the verb ('Get'), resource ('petition details'), and scope ('complete details for a specific petition'), distinguishing it from search-oriented sibling tools like Search_petitions_balanced.
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: 'Use for: Deep dive into specific petition, document metadata access, full legal context review.' It also distinguishes it from search tools by specifying it's for a 'specific petition' and outlines a mandatory workflow for document access, clearly indicating when to use sibling tools like fpd_get_document_download.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 and does so effectively. It explains the proxy behavior ('ALWAYS-ON PROXY (DEFAULT): Proxy server starts with MCP'), link persistence options ('True: Attempts persistent link via USPTO PFW MCP', 'False: Session-based link'), and response format requirements ('CRITICAL RESPONSE FORMAT - Always format with BOTH clickable link and raw URL'). The only minor gap is lack of explicit mention about authentication requirements or rate limits.
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 clear sections (purpose, proxy info, workflow, response format, document types, parameters) and front-loads the core purpose. While comprehensive, some sections like the detailed workflow and response format justification could be slightly more concise. Every sentence earns its place by adding 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 tool's complexity (4 parameters, no annotations, but with output schema), the description is remarkably complete. It covers purpose, workflow integration, behavioral details (proxy, persistence), parameter semantics, response formatting requirements, and document type context. The presence of an output schema means the description doesn't need to explain return values, and it focuses appropriately on the operational context.
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?
With 0% schema description coverage, the description fully compensates by providing detailed semantic explanations for all parameters. It explains petition_id ('Petition UUID from search results'), document_identifier ('Document identifier from documentBag'), proxy_port ('Optional (defaults to FPD_PROXY_PORT env var or 8081)'), and generate_persistent_link with its two modes and implications. This goes well beyond what the bare schema provides.
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 explicitly states the tool's purpose: 'Generate browser-accessible download URL for petition documents (PDFs) via secure proxy.' This is a specific verb ('Generate') + resource ('download URL for petition documents') that clearly distinguishes it from sibling tools like Get_petition_details (which retrieves details) or FPD_get_document_content_with_mistral_ocr (which extracts content via OCR).
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 workflow guidance: '1. fpd_get_petition_details(petition_id='uuid', include_documents=True) → get documentBag 2. fpd_get_document_download(petition_id='uuid', document_identifier='ABC123') → get download link 3. Provide download link to user.' It clearly positions this as step 2 in a sequence and distinguishes it from content extraction tools by focusing on URL generation rather than document analysis.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 the tool's behavior: it's a search operation (implied read-only), returns 10-20 results with 18 key fields, and provides specific examples of how to use parameters. However, it doesn't mention potential limitations like rate limits, authentication requirements, or error conditions, which keeps it from a perfect score.
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 clear sections (purpose, usage, parameters, examples, workflow, integration) and uses bold formatting effectively. While comprehensive, it's somewhat lengthy; every sentence serves a purpose, but some redundancy exists (e.g., repeating parameter lists in different sections). The front-loaded purpose and usage are clear, making it efficient for understanding.
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 (17 parameters, no annotations, 0% schema coverage) and the presence of an output schema, the description is remarkably complete. It explains the tool's purpose, when to use it, all parameters with semantics, provides examples, outlines a workflow, and describes cross-tool integration. The output schema handles return values, so the description appropriately focuses on usage context rather than output details.
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?
With 0% schema description coverage for 17 parameters, the description fully compensates by providing detailed parameter information. It clearly lists all 14 parameters (grouped as 9 minimal and 5 balanced), explains what each represents with examples (e.g., 'petition_type_code: Petition type (e.g., '551' = revival, '182' = restriction)'), and includes practical code examples showing parameter usage, adding substantial value 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 description clearly states the tool performs a 'balanced search for Final Petition Decisions with comprehensive fields (10-20 results)', specifying both the action (search) and resource (Final Petition Decisions). It explicitly distinguishes from the sibling 'Search_petitions_minimal' by explaining this adds 5 advanced filters to the minimal tier, making the differentiation clear and specific.
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: 'Use for: Detailed petition analysis after minimal search, cross-referencing with PFW/PTAB data, analyzing petition types and legal context.' It also includes a 'Progressive Disclosure Workflow' section that shows how this tool fits into a sequence with the minimal search tool, and mentions cross-MCP integration alternatives, giving comprehensive usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and adds significant behavioral context. It explains the tool's role in red flag analysis (e.g., multiple petitions indicate difficult prosecution) and cross-referencing workflows, though it doesn't explicitly mention rate limits, auth needs, or error handling.
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?
Well-structured with clear sections (Use for, Examples, Red flag analysis, Cross-MCP integration, Parameters). Every sentence adds value, though it's somewhat lengthy. The purpose is front-loaded, and information is efficiently organized.
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 2 parameters, 0% schema coverage, no annotations, but an output schema exists, the description is highly complete. It covers purpose, usage, examples, analysis context, integration with other tools, and parameter details, compensating for gaps in structured data.
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. It provides detailed parameter semantics: application_number format examples ('17896175', '15/123,456') and include_documents behavior ('Include documentBag in response'). This adds substantial meaning 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 description clearly states the tool's purpose with specific verb ('Get') and resource ('all petition decisions for a specific application number'), distinguishing it from siblings like Search_petitions_by_art_unit or Search_petitions_minimal. It precisely defines the scope of retrieval.
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 for' section explicitly lists three scenarios: complete petition history, red flag identification, and cross-referencing. The 'Cross-MCP integration' section provides detailed alternatives and sequencing with other tools, including pfw_search_applications_minimal and PTAB checks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and does well by explaining the tool's purpose, return format ('balanced field set for cross-referencing'), and integration patterns. It describes analysis patterns for interpreting results and cross-MCP workflows. However, it doesn't mention rate limits, authentication needs, or error conditions, leaving some behavioral aspects uncovered.
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 clear sections (purpose, use cases, examples, analysis patterns, integration, parameters) and every sentence adds value. It's appropriately sized for a complex tool with integration needs, though slightly longer than minimal. The front-loaded purpose statement immediately clarifies the tool's function.
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 tool's complexity (3 parameters, 0% schema coverage, no annotations, but with output schema), the description is remarkably complete. It covers purpose, usage guidelines, parameter semantics, analysis patterns, and cross-tool integration workflows. The output schema existence means return values don't need explanation, and the description provides everything else needed for effective use.
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?
With 0% schema description coverage, the description fully compensates by providing detailed parameter explanations: art_unit format examples ('2128', '3600'), date_range format specification ('YYYY-MM-DD:YYYY-MM-DD'), and limit details (default 50, max 200). It adds practical examples showing parameter usage, giving clear semantic meaning 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 description clearly states the tool searches petitions by art unit number for examiner/art unit quality analysis, using specific verbs ('search', 'returns') and resources ('petitions', 'art unit number'). It distinguishes from siblings like Search_petitions_by_application by focusing on art unit rather than application, and from Search_petitions_balanced/minimal by specifying balanced field sets for cross-referencing.
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 for:' section explicitly lists specific scenarios (art unit quality assessment, systematic petition patterns, examiner behavior analysis). It provides clear alternatives by mentioning cross-MCP integration with pfw_search_applications_minimal and PTAB MCP, and distinguishes from siblings by focusing on art unit analysis rather than application-based or minimal searches.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
Behavior5/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 thoroughly explains the tool's behavior: the hybrid extraction process (PyPDF2 first, Mistral OCR fallback), cost optimization details (free vs. $0.001/page), dependency on MISTRAL_API_KEY, and return values (extracted_content, extraction_method, etc.). It also covers practical aspects like cost savings (70%) and fallback mechanisms, providing rich context beyond basic functionality.
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 clear sections (PREREQUISITE, USE CASES, COST OPTIMIZATION, Example workflow) and front-loaded key information. However, it includes some redundancy (e.g., repeating cost details in multiple sections) and could be slightly more concise by integrating the example workflow more seamlessly. Overall, most sentences earn their place by adding value, but minor trimming is possible.
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 tool's complexity (hybrid extraction, cost optimization, prerequisites) and the absence of annotations, the description is highly complete. It explains the extraction process, cost implications, dependencies, use cases, and workflow integration. With an output schema present, it doesn't need to detail return values, but it still lists them (extracted_content, etc.) for clarity. This provides all necessary 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?
The input schema has 0% description coverage, so the description must compensate. It adds significant meaning for all parameters: petition_id is contextualized in the prerequisite and example workflow, document_identifier is explained as coming from documentBag via fpd_get_petition_details, and auto_optimize is detailed with its default (True) and effects on cost and extraction method. This goes beyond the schema's basic titles and types, clarifying how and why to use each parameter.
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's purpose: 'Extract full text from USPTO petition documents with intelligent hybrid extraction (PyPDF2 first, Mistral OCR fallback).' It specifies the verb ('extract'), resource ('USPTO petition documents'), and method ('hybrid extraction'), distinguishing it from sibling tools like FPD_get_document_download (which likely downloads files) and Get_petition_details (which retrieves metadata).
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, including prerequisites ('First use fpd_get_petition_details to get document_identifier from documentBag'), alternatives (e.g., using auto_optimize=False for direct OCR), and sibling tool references (e.g., 'For document selection strategies and cost optimization, use FPD_get_guidance('cost')'). It also lists specific use cases like analyzing legal arguments and detecting patterns, helping differentiate from other search or download tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![uspto_fpd_mcp MCP server](https://glama.ai/mcp/servers/john-walkoe/uspto_fpd_mcp/badges/card.svg)](https://glama.ai/mcp/servers/john-walkoe/uspto_fpd_mcp)

Score Badge

Copy to your README.md:

[![uspto_fpd_mcp MCP server](https://glama.ai/mcp/servers/john-walkoe/uspto_fpd_mcp/badges/score.svg)](https://glama.ai/mcp/servers/john-walkoe/uspto_fpd_mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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