The Schwab MCP server exhibits moderate definition quality with significant gaps in parameter documentation and output schema specification. While tool names follow verb_noun conventions (getQuotes, getAccounts, placeOrder), many lack detailed parameter descriptions. Schema visibility is mixed: some tools show parameter types but lack comprehensive documentation. Descriptions are present but often minimal (under 100 chars). Critical issues: incomplete parameter schemas for 15+ tools, no documented output schemas, and missing parameter type information for several tools. The server registers 23 tools but evidence from provided code shows only partial schema implementations. Error handling is present via toolError() but lacks actionable recovery guidance per pattern:recovery-guide.

• Add explicit output schema documentation for all tools, include field names, types, and descriptions. Example: 'Returns {quotes: Array<{symbol: string, price: number, bid: number, ask: number}>, timestamp: string}'
• Expand placeOrder and replaceOrder schemas to show all required order fields (symbol, quantity, orderType, duration, etc.) with type constraints
• Add parameter descriptions for searchInstruments specifying what 'projections' parameter controls and valid enum values
• Increase minimum tool description length, 'Get quotes' (11 chars) is below the 50-char baseline. Rewrite as: 'Retrieve real-time or delayed quotes for specified stock symbols with optional field selection (bid/ask, volume, etc.)'
• Implement pagination for getAccounts, getOrders, getTransactions with limit/offset or cursor parameters and total count in response
• Add explicit state-modification warnings to placeOrder, replaceOrder, cancelOrder descriptions: 'This tool executes an order on the live account, it cannot be undone automatically.'
• Document parameter constraints for date fields (startDate, endDate), specify ISO 8601 format and valid ranges
• Add confirmation-style tool variant or dry-run flag for irreversible operations to match pattern:confirmation-request
• Enhance error responses with actionable guidance. Example: instead of returning {ok: false, error: 'Symbol not found'}, return {ok: false, error: 'Symbol XYZ not found. Try searchInstruments() to find valid symbols.'}
• Document which parameters are mutually exclusive (e.g., if using period + periodType vs startDate + endDate in getPriceHistory)