Server has 10 tools with complete schemas and descriptions. Naming follows verb_noun pattern consistently (nara_search, nara_get, nara_download). Descriptions are present and actionable (avg ~80 chars), explaining WHAT and WHEN. However, parameter descriptions are minimal (often single phrases), and output schemas are not documented. Error handling is absent, no guidance on retryability, user-fixable vs fatal errors, or recovery paths. Security is well-handled (secrets scrubbed, write-root validation), but composition could be tighter (some tools like nara_make_source_packet and nara_make_negative_search_record feel domain-specific rather than general-purpose).

• Document output schemas for all tools. E.g., nara_search_records returns {records: [{naid, title, date, url, ...}], total_count, page, limit}. Include field types and whether fields are always present.
• Add error handling guidance to tool descriptions. E.g., 'If NAID not found, try nara_search_records() with a partial title. If API key missing, check NARA_API_KEY environment variable.'
• Formalize parameter constraints in descriptions. E.g., 'selection: comma-separated object indices or ranges (e.g., 1,3-5,7) or literal string "all". Invalid selections return a list of valid indices.'
• Clarify use cases for nara_make_source_packet and nara_make_negative_search_record. Add context: 'Use source_packet to prepare archival metadata for repository submission. Use negative_search_record to document why a query yielded no results (for research audits).'
• Enhance pagination documentation. Specify total_count and next_cursor in response schema. Document max page size and whether page numbering is 0-indexed or 1-indexed.