An intelligent financial assistant MCP server built with FastMCP that manages financial transactions, provides asset price queries, and uses CrewAI agents for financial data processing with memory and SQL database integration.
The server exposes only 1 tool: 'resolve_relative_date'. While the tool has a description and schema, the implementation is severely underdeveloped for production use. The description is adequate (186 chars), but the schema is minimal with only a single 'input' string parameter. No output schema is documented, no error handling guidance is provided, and the server fundamentally lacks domain completeness for a financial assistant. The tool name does not follow verb_noun convention (should be 'convert_relative_date' or 'parse_date_expression'). The Streamlit frontend references a non-existent 'assistente_financeiro_inteligente' tool that is never registered in the MCP server, indicating a serious disconnect between declared functionality and implementation.
Main financial assistant tool that processes financial transaction requests and asset price queries using CrewAI multi-agent orchestration. Classifies user requests as either financial control (income/expense recording) or asset consultation, and delegates to appropriate crews.
Converts relative date expressions like 'hoje' (today), 'ontem' (yesterday), 'anteontem' (day before yesterday), or date formats like '15/07' or '01/08/2024' to ISO format (YYYY-MM-DD).
Tool name does not follow verb_noun convention. 'resolve_relative_date' uses generic verb 'resolve'; production tools use specific action verbs like 'convert', 'parse', or 'format'. LLMs infer intent from names, this naming is ambiguous and non-standard.
No output schema documented. Tool description does not specify what structure the response returns (e.g., does it return {date: string}, {iso: string, timestamp: number}?). LLMs cannot plan downstream calls or validate returned data without explicit output schema documentation.
No error handling guidance provided. Tool description does not explain how the LLM should handle invalid date strings ('xyz'), ambiguous dates ('15/07' without year context in non-DDMM regions), or edge cases. No recovery guidance for malformed input.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 7 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 25 | - | v1 |
Critical mismatch: Streamlit frontend calls 'assistente_financeiro_inteligente' tool which does not exist in mcp_server.py. This tool is never registered. The entire financial assistant functionality is unimplemented; only date resolution is available. The server falsely advertises finance capabilities.
Domain incompleteness: A financial assistant should provide tools for transaction recording, expense categorization, asset price lookups, and account management. Only a date parser exists. The single tool provides no financial utility.
Parameter description is generic. The 'input' parameter description ('A date expression in relative format') lacks specificity on format constraints. No examples of valid/invalid inputs, no mention of timezone handling, no specification of which formats are supported (does '15/07' mean DD/MM or MM/DD? Regional ambiguity).
Tool description mentions example formats but does not document output behavior. Does 'ontem' (yesterday) return yesterday's date in user's timezone or UTC? Does '15/07' auto-complete with current year or return an error? These ambiguities force LLMs to guess.