This is a template/starter project, not a production MCP server. Tool definitions exist only as TypeScript type interfaces in lib/types/tool-responses.ts, with no visible tool registration, parameter schemas, or handler implementations. While type definitions document response structures, there is no evidence of actual MCP tool registration with input schemas, parameter validation, or error handling. The server appears to be a Next.js scaffold with database/auth infrastructure but lacks the core MCP server implementation details (tool handlers, input validation, structured responses). All tool scores are capped at 50 due to inferred definitions rather than explicit registration.
Tools (10)
account_balancesread onlyauth37/100
Get account balances and overview
account_healthread onlyauth37/100
Check account health and detect potential issues
budget_calculationread only37/100
Calculate budget allocations using the 50/30/20 rule
financial_tipsread only37/100
Get personalized financial tips and recommendations
hello_worldread only33/100
Example widget showing basic MCP integration
investment_holdingsread onlyauth37/100
Get investment accounts, holdings, and securities data
liabilitiesread onlyauth33/100
Get credit cards, loans, mortgages, and other liability data
spending_insightsread onlyauth37/100
Get spending insights categorized by transaction category
No input parameter schemas visible. Tools are defined as TypeScript interfaces documenting RESPONSE structures only (HelloWorldContent, AccountBalancesContent, etc.), but no input parameter definitions, validation schemas, or constraints are present.
Tool definitions are inferred from type interfaces, not explicitly registered. No visible tool handler implementations, no MCP server registration code, no tools() callback or equivalent. The project appears to be a Next.js template with database schemas but lacks the actual MCP server implementation layer.
Create explicit tool registration code in the MCP server implementation (likely missing from this template). Each tool must be registered with: name, description (150-250 chars), inputSchema (JSON Schema with type, properties, required, and per-param descriptions), and handler function.
Expand all tool descriptions to 100-250 characters. Include WHAT the tool does, WHEN to use it vs similar tools, and any PREREQUISITES. Example for account_balances: 'Retrieve balances and details for all connected bank accounts, including account type, subtype, balance, and available funds. Use this to show the user their account overview. Requires active bank connection via Plaid.'
Add structured inputSchema for each tool. For 'transactions': define parameters as {limit: {type: 'integer', minimum: 1, maximum: 100, default: 20}, offset: {type: 'integer', minimum: 0}, dateRange: {type: 'object', properties: {start: {type: 'string', format: 'date-time'}, end: {type: 'string', format: 'date-time'}}}, category: {type: 'string', enum: ['FOOD_AND_DRINK', 'SHOPPING', ...]} }. Every parameter must have a description explaining its role and constraints.
Document error responses explicitly. Add to each tool: 'On authentication failure, returns {message: "Authentication required", featureName: "...", pricingUrl: "..."}. On subscription required, returns {message: "Feature requires premium subscription"}. On data unavailable, returns {message: "No transactions found for date range", suggestion: "Try broadening the date range"}.' This enables LLM error recovery.
Spec posture evidence
Inferred effective spec: 2025-06-18+.
Relies on Logging (deprecated) - log to stderr or use OpenTelemetry
Score history
Overall score trend
↑ 32 points across a rubric change (v1 → v2)
32/100
Scored
Grade
Overall
Spec posture
Rubric
2026-09-22
F
32
2025-06-18+
v2
2026-03-09
F
0
-
v1
subscription_managementread onlyauth32/100
Access subscription management portal
transactionsread onlyauth43/100
Get transaction data with optional filtering, pagination, and metadata
Tool descriptions are extremely brief (20-45 characters). 'Get account balances and overview' (35 chars) does not explain WHEN to use this vs other financial tools, WHAT data structure to expect, or PREREQUISITES (e.g. must authenticate first).
No parameter descriptions visible. Even the 'transactions' tool (which has the most detailed response schema) shows no input parameter documentation. Parameters like 'limit', 'offset', 'dateRange', 'category', if they exist, lack descriptions explaining format, constraints, defaults, or dependencies.
No error handling documentation. Response types include AuthChallengeContent (for auth/subscription gatekeeping) and AuthResponseSchema (union type), suggesting errors exist, but no guidance on retry logic, user-fixable errors, or recovery strategies. LLMs cannot infer what to do on failure.
Generic/non-action-verb naming for 'subscription_management' and 'financial_tips'. 'subscription_management' is a noun phrase that does not clarify whether it retrieves, updates, or creates subscriptions. 'financial_tips' is vague, does it fetch, generate, or search tips?
No pagination or limit enforcement documented. Response schemas suggest large result sets (transactions.metadata.topMerchants array, spending_insights.categories array, investment_holdings implied to contain multiple securities) but no tool description states 'Returns up to N items' or documents pagination parameters.
transactionsspending_insightsinvestment_holdings
Rename 'subscription_management' to 'get_subscriptions' or 'list_subscriptions' (if fetching) or 'update_subscription' (if modifying). Action verbs clarify intent. Similarly, rename 'financial_tips' to 'get_financial_tips' or 'search_financial_tips'.
Add pagination guidance: 'Returns up to 50 transactions per call. For more, use limit and offset parameters. Set limit to 1-100; offset is 0-indexed. Response includes pagination.hasMore (boolean) and pagination.nextOffset (integer or null) to simplify paging loops.'
Document natural identifiers. If tools accept account names or merchant names alongside IDs, state this: 'account_id can be the account number (e.g. "1234") or name (e.g. "Checking"); the tool resolves it.' This reduces lookup tool calls.
Add toolAnnotations where applicable: mark all 10 tools as readOnlyHint=true (they only read financial data, no mutations). This tells agents the tools are safe to call speculatively.
Implement proper error responses with actionable guidance. For example, if a user has not connected a bank account: 'No accounts found. Please connect a bank account via Plaid link at [setupUrl]. After connection, try this tool again.' Instead of a bare error, guide the user to the fix.