This server exposes 20 workplace prompt tools via HTTP, but has severe definition quality issues. All tools share identical, minimal schemas with only a single generic 'input' string parameter. Descriptions are generic boilerplate ('Generate workplace content using the [prompt-name] prompt') that do not explain WHEN to use each tool or what distinguishes it from similar tools. No output schema is documented. The tool naming convention (e.g., 'communication-writing/write-professional-email') mixes category/tool, which is unusual for MCP and does not follow verb_noun convention. Parameters lack meaningful descriptions, the 'input' parameter is described as 'The input text or parameters for the prompt' but does not specify what format, structure, or constraints apply. No error handling, validation, or recovery guidance. The implementation treats these as thin wrappers around prompts rather than well-defined tools. This pattern violates the tool composition, description, and schema definition patterns from the rubric.

• Replace generic descriptions with tool-specific, actionable text (50 - 200 chars each). For example: 'write-professional-email' should describe: 'Generates a professional email given recipient, topic, and tone. Use when composing workplace correspondence.' This tells the LLM when and how to invoke the tool.
• Redesign input schemas to capture tool-specific parameters. For 'write-professional-email', define: recipient (string), topic (string, required), tone (enum: formal, friendly, urgent), and optional context (string). Use proper JSON Schema with types and descriptions for each parameter.
• Document output schema for all tools. Define what fields are returned (e.g., generated_text (string), content_type (enum), word_count (integer)). This enables LLMs to extract and chain results correctly.
• Rename tools to follow verb_noun convention without category prefix. Replace 'communication-writing/write-professional-email' with 'write_professional_email'. This improves LLM parsing and naming clarity.
• Add parameter descriptions that specify format, constraints, and examples. For 'summarize-long-email', describe the 'input' parameter as: 'Email thread or text to summarize (plain text, Markdown, or quoted format; max 10,000 characters).' This guides LLMs on input format.
• Implement error handling with actionable recovery messages. If input validation fails, return: 'Invalid input: missing recipient email. Include recipient name or email in the request.' This lets LLMs self-correct.
• Add tool annotations (destructiveHint: false, readOnlyHint: true, idempotentHint: true for these read-only prompt generators) to clarify side effects and retry safety.