Prioris MCP has 27 tools with basic descriptions and tool annotations enabled. However, critical gaps undermine quality: (1) Input schemas are not visible in the provided source code, only tool names and descriptions are shown. Without seeing parameter definitions, types, and constraints, schema quality cannot be verified. (2) Descriptions are present but generic and brief (10-50 chars typical), lacking actionable context for LLM selection. E.g., 'Search arXiv for research papers' does not explain when to use this vs. discovery tools, what parameters are required, or what the output structure is. (3) No evidence of parameter descriptions, type definitions, or validation rules in the visible code. (4) Error handling and recovery guidance are absent from descriptions. (5) Output schemas are not documented in the tool definitions. The server uses fastmcp and includes tool annotations (destructiveHint, readOnlyHint), which is positive, but the foundation is weak.

• Add explicit input schemas to all tools in fastmcp decorator. Include parameter types (string, integer, enum), constraints (min/max, regex patterns), and descriptions (50-150 chars each). Example: @mcp.tool(description='Search arXiv papers by query. Returns up to 20 results; use page parameter for pagination.', inputSchema={...})
• Expand tool descriptions to 100-200 characters. Include: (1) What the tool does, (2) When to use it vs. similar tools, (3) Key parameters and their format, (4) What the output contains. Example: 'Search arXiv for papers by title, author, or keyword. Returns metadata (title, authors, abstract, arxiv_id). Use research_arxiv_fetch_full_text to get the PDF. Limit: 20 results per call; use page parameter for more.'
• Document output schemas in tool descriptions or via structured return type hints. Specify: field names, types, and whether fields are always present. Example: 'Returns: {papers: [{arxiv_id: string, title: string, authors: [string], abstract: string, published_date: ISO8601}], total_count: integer, next_page: string|null}'
• Add confirmation or dry-run patterns to destructive tools (delete_fetched, notes_delete, graph_write). Example: Add a 'confirm' parameter (boolean, default false) or a 'dry_run' parameter. Describe: 'This operation is irreversible. Pass confirm=true to proceed, or call with confirm=false to preview changes.'
• Implement per-tool error handling guidance. For each tool, document: (1) Common failure modes (e.g., 'Paper not found', 'Invalid query syntax'), (2) Recovery actions ('Try search_arxiv_search with simpler keywords'), (3) Retryability ('This error is transient; safe to retry'). Return structured error objects with code, message, and recovery_hint fields.

Inferred effective spec: <=2025-11-25.

• Relies on Logging (deprecated) - log to stderr or use OpenTelemetry