Archive-Agent provides 7 well-named READ_ONLY tools with clear verb prefixes (get_*, list_*). Descriptions are present for all tools and are reasonably detailed (average ~100-150 chars), exceeding the critical minimum. All parameters have type declarations and descriptions. However, output schemas are documented only in docstring comments rather than formal JSON Schema declarations, and several parameter descriptions lack actionable constraints (e.g., no guidance on collection name format, no enum for optional fields). Error handling is minimal, tools rely on assertions and will throw unhandled exceptions rather than providing actionable recovery guidance. The codebase demonstrates consistent naming, good composition (tools are single-concern), and appropriate READ_ONLY classification, but lacks the structured error responses and parameter validation that would elevate this to 70+.

• Add formal JSON Schema output declarations to each tool. Use the MCP server framework's capability to register return type schemas (e.g., FastMCP's type hints or explicit schema registration). Include field descriptions and types so LLMs can plan downstream operations.
• Implement structured error responses. Replace bare assertions with try-catch blocks that return a dict like {"error": "Collection does not exist", "recovery": "Call get_collections() to see available collections"}. Categorize errors as retryable (user should call get_collections) vs fatal.
• Add enum constraints to the 'collection' parameter. Call get_collections() internally to build a list of valid collection names and either pass it as an enum in the schema or validate and return a helpful error message (e.g., 'Invalid collection. Valid options: [list]').
• Implement pagination for get_search_result and get_chunk_headers. Add an optional 'limit' parameter (default 20, max 100) and return a response that includes 'total_results' and 'next_cursor' (if applicable). Document the limit in the tool description.
• Refactor global _context to request-scoped injection. Pass _context as a parameter through tool invocations or store it in a request-local context manager. This ensures each request is stateless and thread-safe.
• Add parameter constraints to descriptions. For 'question' in get_search_result, add guidance like 'A natural language query (10-500 characters). Keep broad to retrieve more results, narrow for specific topics.' For 'file_path', specify the expected format and whether it's relative or absolute.