Server has 2 tools with explicit definitions and schemas visible in src/index.ts. Both tools have descriptions (18 - 27 chars) and input schemas with documented parameters. However, descriptions are extremely brief (below the 34-char baseline for p10), lacking actionable context on WHEN to use each tool or multi-step workflows. Parameter descriptions are minimal (10-30 chars). No output schema is documented, the code returns text blobs without structured field definitions. read-messages returns JSON.stringify() without specifying the shape of the array or field names. Error handling is present but lacks recovery guidance (e.g., 'Channel not found' errors list available channels but don't suggest which to try). No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite send-message being a write operation. The server uses proper validation with Zod and catches errors, but error messages don't guide the LLM toward remediation. Schema format is correct JSON Schema with types and required fields. Naming is verb-first and clear (send-message, read-messages), following conventions. No security issues detected, no secrets in parameters, proper permission checks via Guild/Channel membership. Composition is sound: two single-responsibility tools. However, parameter re-use (server, channel across both tools) could be better documented as an optional multi-step pattern.

• Expand tool descriptions to 50 - 200 characters. Example: 'send-message' should say 'Send a message to a specific text channel in a Discord server. Useful for notifications, alerts, or chat-based workflows. Returns the message ID on success. Requires bot to have write permission in the target channel.'
• Document the output schema in the tool description or add a separate response field. For read-messages, specify: 'Returns an array of message objects with fields: {channel: string, server: string, author: string, content: string, timestamp: ISO8601}.'
• Add tool annotations to the ListTools response. send-message should include 'destructiveHint: true' to signal that this operation has side effects. read-messages should include 'readOnlyHint: true'.
• Remove the inline example 'e.g., "general"' from the channel parameter description and replace it with a format statement: 'Channel name or ID. Names are case-insensitive (e.g., general or General both work).' Or add an enum constraint if a fixed set of channels is known.
• Enhance error messages with recovery steps. Example: 'Channel "xyz" not found in server "acme". Available channels: #general, #dev-team. Did you mean #general? [ERROR_CHANNEL_NOT_FOUND]'
• Document parameter constraints in the schema. The limit parameter (min 1, max 100, default 50) is validated in Zod but not exposed in inputSchema. Add 'minimum: 1, maximum: 100' to the JSON Schema definition.
• Add a per-tool summary of idempotence and retry safety. read-messages is idempotent; send-message is not (repeated calls create duplicate messages). State this in tool descriptions.