Six tools with complete schemas and descriptions, but quality is uneven. Tool names lack action verbs (register, query, list, show, close, update are weak; prefer create_entry, search_entries, list_entries, get_entry, close_entry, update_entry). Descriptions are present but brief (avg ~60 chars, below 194-char baseline). Parameter descriptions exist but lack format/constraint details. Output schemas are not documented. Error handling is minimal. No tool annotations (readOnlyHint/destructiveHint). Composition is reasonable, tools are single-purpose and chainable via IDs.

• Rename tools to verb_noun: register→create_entry, query→search_entries, list→list_entries, show→get_entry, close→close_entry, update→update_entry. This matches LLM expectations and the 90% baseline of A+ tools.
• Expand descriptions to 100 - 200 chars. Include WHAT, WHEN, and any prerequisites. Example: 'Create a new carn entry to track a code pattern, constraint, or coordination point. Use forbid-pattern to block anti-patterns, prefer-pattern to recommend alternatives, or coordinate to track cross-team work. Requires type and description; paths and ttl are optional.'
• Document output schemas for all tools. Specify field names, types, and whether results are paginated. Example: 'Returns {id: string, type: string, description: string, paths: string[], status: "in-flight"|"closed", created_at: ISO8601, ttl?: string}'.
• Add tool annotations via the MCP SDK: server.tool(..., {readOnlyHint: true}) for query/list/show; {destructiveHint: true} for close/update. This signals intent to LLMs without extra description text.
• Enhance parameter descriptions with format constraints. For 'ttl', state: 'Format: <number><unit> where unit is s|m|h|d (seconds, minutes, hours, days). Example: 7d, 24h, 3600s.' For 'id', state: 'Entry ID or prefix to match (case-sensitive, alphanumeric).' For 'type', use an enum: {enum: ["forbid-pattern", "prefer-pattern", "coordinate"]}.