The server has 4 tools with explicit schemas and descriptions. All tools are registered with proper JSON Schema definitions using mark3labs/mcp-go framework. However, there are several quality gaps: (1) Tool naming lacks action verbs, 'literature-fetch' should be 'get_literature' or 'fetch_literature'; 'markdown' and 'markdown_to_pdf' are generic; 'git-summary' lacks context about aggregation. (2) Descriptions are present but lean, most are 60-150 chars, below the 194-char baseline for production tools. (3) Several parameters lack descriptions: markdown tool has only 1 described parameter (content); git-summary is missing descriptions for 'start_date' and 'end_date' format expectations. (4) No output schemas documented in source, unclear what fields these tools return to downstream callers. (5) No error handling patterns visible, tools lack recovery guidance. (6) Prompts feature enabled but no prompts defined in provided source. (7) Security: git-summary accepts optional 'api_key' parameter (line in go.mod references go-openai), violating secret-injection pattern, keys should never be exposed as parameters.

• Rename tools to use verb_noun pattern: 'get_literature' (not 'literature-fetch'), 'convert_markdown_to_html' (not 'markdown'), 'convert_markdown_to_pdf' (not 'markdown_to_pdf'), 'summarize_git_commits' (not 'git-summary'). This helps LLMs parse intent from the name alone.
• Remove 'api_key' parameter from git-summary. Inject OpenAI API key server-side via environment variable or secure vault. Update description to note 'Requires OPENAI_API_KEY environment variable on server.' This eliminates credential exposure in logs and LLM traces.
• Expand all parameter descriptions to include format and constraints. E.g., 'start_date' should read: 'Start date for commit analysis. Format: ISO 8601 (YYYY-MM-DD) or natural language (e.g., "2 weeks ago").' E.g., 'filename' should read: 'Output filename relative to working directory. No absolute paths or '..' allowed. Defaults to 'output.pdf'.'
• Document output schemas for all tools in code comments or structured docstrings. E.g., literature-fetch should document: '{article_title: string, authors: string[], journal: string, year: number, pmid: string, doi: string, abstract: string}'. This enables downstream tool chaining and LLM reasoning.
• Add error handling with recovery hints. E.g., literature-fetch: 'If PMID not found, catch error and suggest searching by title or DOI instead.' E.g., markdown_to_pdf: 'If file write fails due to permissions, return clear message: "Cannot write to /path/to/file. Check directory permissions or provide a different filename."'

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

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