Three tools with basic schemas and descriptions, but significant gaps in parameter documentation and output schema clarity. Tool naming follows verb_noun convention (get-prompts, get-prompt, get_trace). Descriptions exist but are minimal (10-80 chars, below the 194-char baseline). Parameters lack detailed constraints and format guidance. No output schemas documented. Error handling is generic ('Error: ' + error). The get_trace tool uses inlined Zod schema (not explicitly visible in registration), making verification difficult.

• Document output schemas for all tools. Example: get-prompts returns {prompts: [{name: string, arguments: [{name: string, required: boolean}]}, nextCursor?: string}. This enables LLMs to plan chained calls.
• Expand tool descriptions to 100 - 200 chars. Example: 'Get a list of available prompts from Langfuse. Returns prompt names and required variables. Use this to discover available prompts before calling get-prompt. Supports pagination via cursor.'
• Replace example values in parameter descriptions with formal constraints. Instead of 'e.g. {"<name>":"<value>"}', document: 'JSON object mapping variable names (strings) to values (strings). Keys must match prompt template variables.'
• Standardize tool naming: rename get_trace to get-trace for consistency with kebab-case convention used by other tools.
• Implement actionable error messages. Catch specific errors (PromptNotFound, InvalidArguments, APIError) and return recovery guidance: 'Prompt "xyz" not found. Available prompts: [list]. Call get-prompts to refresh the list.'