Solace Broker MCP has critical definition gaps. Tool descriptions are present but minimal (10-50 chars, well below the 194-char baseline). Input schemas are partially visible for only 2 of 5 tools; 3 tools lack visible schema definitions. Parameter descriptions exist for some tools but are generic ('Broker identifier', 'Message VPN name'). No output schemas documented. Error handling guidance absent. Tool naming follows verb_noun convention (list-, describe-, get-, test-, destructive-) but lacks clarity on when to use similar tools (e.g., describe-semp-schema vs get-broker-status). No evidence of pagination, result limits, or chaining IDs in responses. Security annotations (destructiveHint) present on one tool but inconsistently applied.

• Add complete input schemas to all 5 tools. Schemas must include type, description, and constraints (enum, min/max, pattern) for every parameter. Currently 3 tools have no visible schema.
• Expand all tool descriptions to 100-200 characters. Include: (1) what the tool does, (2) when to use it vs similar tools, (3) what it returns. Example: 'List all configured Solace brokers with their connection status and SEMP API endpoints. Call this first to discover available brokers before querying individual broker status.'
• Document output schemas for all tools. Specify field names, types, and whether results are paginated. Include pagination parameters (limit, offset/cursor) and total count in responses.
• Rename test-tool and destructive-tool to reflect actual operations. If these are test fixtures, remove them from production tool registration. If real, use names like validate-vpn-config or delete-message-vpn.
• Add error handling guidance to descriptions. E.g., 'If broker not found, call list-brokers to verify the broker name. If SEMP API is unreachable, check broker connectivity.' Include error classification (retryable vs user-fixable) in tool documentation.