Loading ToolBench
MCP server for USPTO Patent Trial and Appeal Board (PTAB) data via Open Data Portal API
The USPTO PTAB MCP exhibits solid foundational quality with comprehensive tool definitions, detailed parameter schemas, and good documentation. However, it suffers from critical naming redundancy (3x variants of the same search tools), incomplete error handling guidance, and missing output schema documentation. Tool descriptions are adequate (100-150 chars average) but lack strategic context about when to use minimal vs. balanced vs. complete variants. Parameter schemas are well-typed with enums and constraints, but the server would benefit from clearer guidance on variant selection, explicit output structures, and recovery paths for common failures. The tool composition pattern (minimal/balanced/complete) is non-standard and creates cognitive overhead for LLM selection.
Extract text content from a PTAB document via OCR or embedded text extraction
Get browser-accessible download URL for a PTAB document with optional redaction selection
Get document list for a trial, appeal, or interference proceeding with optional filtering and pagination
Get contextual guidance for USPTO PTAB MCP usage, field configuration, document operations, and cross-MCP workflows
Search PTAB ex parte appeals with balanced field set for detailed analysis
Search PTAB ex parte appeals with all available fields for comprehensive archival
Search PTAB ex parte appeals with minimal field set for discovery
Naming redundancy: 9 of 14 tools share the same prefix with only suffix variation (_minimal, _balanced, _complete). This violates the pattern:tool principle that each tool should have a clear, distinguishing purpose. LLMs must reason about variants instead of selecting based on semantic clarity. The description alone ('minimal field set', 'balanced field set', 'complete archival') does not compensate, the variant pattern creates cognitive overhead.
Missing output schema documentation. No visible documentation of what fields each search tool returns, their types, or structures. LLMs cannot plan downstream tool calls (e.g., what ID from search result chains to get_documents) without knowing response fields. The sample config mentions 'field_configs.yaml' but the actual response structure is not specified in tool definitions.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-21 | D | 55 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 40 | - | v1 |
Search PTAB interference proceedings with balanced field set for detailed analysis
Search PTAB interference proceedings with all available fields for comprehensive archival
Search PTAB interference proceedings with minimal field set for discovery
Search PTAB trial proceedings with balanced field set for detailed analysis
Search PTAB trial proceedings with all available fields for comprehensive archival
Search PTAB trial proceedings (IPR/PGR/CBM) with minimal field set for discovery
Manage registered users and their roles (admin tool, OAuth mode only)
No error recovery guidance. Tools like PTAB_get_documents and PTAB_get_document_content offer no error classification or recovery hints. 'Filter by filing party name (trials only, server-side)' in get_documents hints at filtering behavior but does not explain what happens if a party name yields no matches or is malformed. Error responses should guide the LLM: 'Party not found. Try search_trials_* first to confirm party spelling.'
Incomplete parameter constraints. 'sort_order' in get_documents specifies only two values ('asc', 'desc') without an enum constraint. 'format' in get_document_content lists valid values ('text', 'markdown') only in description, not as a schema enum. LLMs cannot reliably parse text constraints, they need formal enums.
ptab_manage_users is a WRITE tool with no dry-run or confirmation step. Removing a user with action='remove' and email='[email protected]' could be destructive and irreversible. The tool lacks a confirmation pattern (e.g., 'confirm': true parameter, or separate dry-run variant) to prevent accidental administrative errors.
Missing scope and permission declarations. Neither the tool definitions nor the source code sample declares what permissions each tool requires (e.g., 'read:ptab', 'admin:users'). This prevents least-privilege agent configuration and clear audit trails. The ptab_manage_users tool should explicitly state it requires 'admin' role.
Variant selection strategy not documented. The tool_reflections.py guidance mentions '1-15KB per section vs 70KB+ total' and 'context reduction' percentages for field variants, but the PTAB_get_guidance tool (section='fields') only hints at this in truncated text. A clear decision tree should state: 'Use minimal when <context constraint>; use balanced when <tradeoff>; use complete when <needs>.'