SharpSpring MCP has solid naming conventions (verb_noun pattern) and comprehensive descriptions for most tools. All 7 tools have descriptions (194-char baseline met). Input schemas are present and use Zod validation with type constraints. However, output schemas are undocumented, responses are JSON-stringified without field-level documentation. Error handling is minimal (no recovery guidance, no categorization). The generic sharpspring_call tool is a catch-all that bypasses structured validation, reducing composability. Pagination is supported but not consistently documented across all tools.

• Document output schemas for each tool. Define the structure of returned fields (e.g., sharpspring_get_leads returns array of {id, emailAddress, firstName, lastName, ...}). Return structured objects instead of JSON strings.
• Replace sharpspring_call with domain-specific tools for common operations (getAccounts, createOpportunities, addListMembers). Reserve sharpspring_call for truly rare/undocumented methods only.
• Add error handling middleware that catches SharpSpringError and returns structured error responses with recovery guidance: 'Invalid field systemName. Call sharpspring_get_fields to discover valid names for this account.'
• Add a dry_run parameter to sharpspring_create_leads, sharpspring_update_leads, and sharpspring_delete_leads. Return what would happen without committing changes.
• Enhance parameter descriptions with defaults and examples. E.g., 'limit: Maximum results per page (default 20, max 500). Use offset for pagination.' Include typical use cases.