Loading ToolBench
MCP server for USPTO Final Petition Decisions data, tracking prosecution-related petitions (37 CFR 1.181, 1.182, 1.183) and bridging normal prosecution and post-grant challenges
The USPTO FPD MCP server demonstrates solid definition quality with mostly complete schemas and reasonable descriptions across 8 tools. All tools have input schemas with typed parameters and descriptions. However, several issues prevent a higher score: (1) Tool naming lacks verb consistency, most tools prefix with 'fpd_' (domain namespace) rather than action verbs like 'search_', 'get_', which is non-standard; (2) One tool name is malformed: 'FPD_get_guidance' uses inconsistent capitalization (uppercase prefix vs lowercase verb); (3) Output schemas are not documented, the rubric requires documentation of what fields are returned; (4) Error handling guidance is absent from descriptions; (5) Parameter descriptions, while present, are somewhat generic and lack actionable constraints (e.g., date format is documented but not validated with enums or patterns). Strengths: all parameters have descriptions and type information; search tools offer useful progressive disclosure via 'minimal' vs 'balanced' variants; pagination limits are respected (50-100 for search tools); the guidance tool shows good domain structure with 11 sectioned outputs. These are production-adjacent patterns but fall short of A-grade quality due to missing error recovery guidance and undocumented output schemas.
Context-efficient sectioned guidance for USPTO FPD workflows, supporting selective retrieval of 11 comprehensive sections including overview, workflows, tools, red flags, documents, and cost optimization
Extract text content from petition PDFs using hybrid PyPDF2 and Mistral OCR for scanned documents
Generate browser-accessible PDF download URL for petition documents via proxy, keeping USPTO API keys secure
Retrieve full petition details with optional documents for a specific petition ID
Detailed analysis of 10-20 petitions with 18 fields, achieving 80-88% reduction in response size
Retrieve complete petition history for a specific application number
Tool naming violates verb-first convention. Tools use 'fpd_search_*' and 'fpd_get_*' prefixes which prioritize domain namespace over action verb. Pattern guidance (pattern:tool) specifies action verbs (get, search, create, list) as the primary identifier for LLM parsing. Current names mix namespace and verb together, making intent parsing slightly less efficient.
Inconsistent tool name capitalization. 'FPD_get_guidance' uses UPPERCASE prefix while all other tools use lowercase 'fpd_'. This creates naming ambiguity and makes tool name parsing unreliable for LLMs.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 56 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 0 | - | v1 |
Art unit quality assessment - retrieve all petitions for a specific art unit within a date range
Ultra-fast discovery of 50-100 petitions with 8 fields, achieving 95-99% reduction in response size
Output schemas not documented. No tool descriptions specify what fields are returned or their types. Pattern:response-shaper and pattern:tool require documented output structure so LLMs know what data to extract for downstream tool calls. E.g., fpd_search_petitions_minimal returns results but shape (array? object with 'results' key? pagination info?) is not documented.
No error handling guidance in tool descriptions. Pattern:recovery-guide requires that error responses tell the LLM what to do next. Current descriptions say nothing about failure modes, retryability, or recovery steps. E.g., 'petition_id' parameter provides no guidance on what happens if the UUID does not exist or is invalid.
Parameter constraints not formally declared. Date parameters (petition_date_start, petition_date_end, decision_date_start, decision_date_end) describe format (YYYY-MM-DD) in text but lack enum or pattern constraints in schema. LLMs cannot parse text format hints reliably, should use JSON Schema 'format: date' and pattern validation.
Decision type and other enum-like parameters not declared as enums. 'decision_type' accepts 'APPROVED, DENIED, WITHDRAWN' per description but is typed as plain string with no enum constraint. LLMs may hallucinate invalid values like 'PENDING' or 'APPROVED '. Should be formal enum schema.
Tool description for art_unit and similar filters lacks selectivity guidance. When is fpd_search_petitions_by_art_unit preferred over fpd_search_petitions_balanced with art_unit filter? Ambiguous tool selection forces LLM reasoning and risks wrong tool choice. Description should state: 'Use when you need ALL petitions for a single art unit across a date range. For filtered searches across multiple fields, use fpd_search_petitions_balanced.'