The server implements 2 tools with auto-generated schemas from Python function signatures. Both tools have names starting with action verbs (rag_*, get_*) and include descriptions extracted from docstrings. However, critical gaps reduce quality: parameter descriptions are minimal/generic (filter_by lacks any description of its structure or valid keys), no output schemas are documented, no error handling guidance is present, and no validation of inputs is shown. The MCPFunctionTool utility demonstrates reasonable schema generation infrastructure but the actual tool definitions lack the depth needed for confident LLM invocation.

• Add a detailed description to filter_by parameter: 'Dictionary of filter parameters. Valid keys: [list them]. E.g. {"company": "Acme", "year": 2024}. Call get_finance_report_filters() first to see available options.'
• Document the output schema for rag_finance_report_search in a docstring or tool metadata. E.g. 'Returns a list of report objects, each with: {report_id (string), title (string), date (ISO 8601), company (string), summary (string)}. Total result count capped at 20; use offset for pagination.'
• Add error handling guidance to descriptions. E.g. 'If no results are found, try broadening the query or removing filters. Call get_finance_report_filters() to see what filters are available.'
• Enhance the MCPFunctionTool schema generator to support constrained types: add support for JSON Schema enums, patterns, minLength/maxLength, and examples. Use enum constraints for filter_by keys instead of relying on LLM inference.
• Document what get_finance_report_filters returns (list of filter names and valid values), so the LLM knows when and how to call it as a discovery tool.
• Add pagination support to rag_finance_report_search if results could exceed ~20 items. Include 'offset' or 'limit' parameters and document the response structure (result count, total count, next_cursor).

Inferred effective spec: 2026-07-28+.

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