Persnally MCP defines 2 tools with explicit schemas and descriptions. Both tools have rich, detailed descriptions that explain purpose, when to use, and what data structures are expected. Schemas are well-formed with nested objects, enums, and required fields. However, the server has significant weaknesses: (1) tool names lack clear action verbs, 'persnally_track' and 'persnally_context' are domain-specific but do not follow verb_noun convention (get_context, track_profile would be clearer); (2) parameter descriptions in the schemas are present but could be more LLM-optimized (some are verbose, others omit constraints); (3) no documented output schemas, descriptions explain what is returned conceptually, but formal response schemas are absent; (4) error handling guidance is minimal, no recovery hints or error classification. Tool descriptions themselves are exceptional (400-500 chars each, LLM-optimized), which elevates the score, but the lack of formal output schemas and weak naming conventions prevent a higher grade.

• Rename 'persnally_track' → 'track_context' or 'update_profile' to follow verb_noun convention. Rename 'persnally_context' → 'get_context' or 'get_profile'. This makes tool intent unambiguous to LLMs.
• Add formal output schemas to both tools. E.g., persnally_track should return { acknowledged: boolean, signals_stored: number } and persnally_context should return { text: string, items: number, category: string }. Document these in tool descriptions or as separate schema declarations.
• Expand error handling documentation. For both tools, add: 'On error, the LLM should [retry with exponential backoff | ask the user for clarification | suggest an alternative]. Common errors: daemon unreachable (retryable), invalid schema (user-fixable), permission denied (fatal).'
• Refactor 'persnally_track' description into a concise summary (1-2 sentences) + a 'Parameters' section that explains topics, style, and corrections independently. Move examples ('Next.js', 'pnpm') into enum declarations or separate guidance docs.
• Add 'required' boolean or 'default' values to all parameters. E.g., topics, style, and corrections are all optional in the schema, clarify this so LLMs know they can call the tool with minimal input.
• Include a 'confidence' field description in the style array documentation: e.g., 'Confidence (0 - 1, default 0.6): how certain you are that this pattern applies. Only use 0.9+ if you've seen this behavior in many conversations.'
• Document the relationship between 'persnally_track' (write) and 'persnally_context' (read). Suggest: 'Call persnally_context at conversation start to read the user's profile. Call persnally_track at the end to record signals learned from this conversation.'