IcePanel MCP server has solid naming conventions (all tools start with action verbs: get*, getLandscapes, getModelObjects, etc.) and comprehensive parameter schemas using Zod for validation. However, descriptions lack depth and specificity for most tools, parameter descriptions are sparse or generic, and output schemas are not documented. Most tools have descriptions between 34-194 chars (within baseline range p10=34, p90=392), but parameter-level annotations are minimal. Error handling returns generic error messages without recovery guidance. The server demonstrates good intent but lacks the LLM-optimization details required for A-tier scores.

• Add structured output schema documentation for each tool. Example for getModelObjects: 'Returns an array of objects, each containing {id: string, name: string, type: enum, status: enum, description?: string, parentId?: string, childIds: string[]}.'
• Expand parameter descriptions with actionable context. Example: 'type: Filter by model object type. Use "system" for C1 level, "app"|"store" for C2 level, "component" for C3 level. Multiple types can be passed as an array.'
• Implement error recovery guidance. Example: 'If landscape not found, call getLandscapes() to see available landscape IDs.' Convert all error returns to structured format with 'error', 'suggested_action', and 'available_alternatives' fields.
• Add pagination support with optional limit and offset parameters. Document: 'Results are capped at 50 items per call. Use offset to retrieve additional pages. Returns a total count for planning.'
• Enrich tool descriptions to 100-200 characters. Current 'Get all your landscapes from IcePanel' should become: 'Retrieve all architecture landscapes in your IcePanel organization. Use this to list available projects before querying specific landscapes. Returns landscape ID, name, creation date, and team ownership.'
• Standardize parameter naming: consistently use 'landscapeId', 'modelObjectId', etc. Ensure every tool that accepts these IDs uses the exact same parameter name for composability.
• Add query guidance in getModelObjects description: 'Prefer filtering by teamId when asking "What does Team X own?" and by technologyId for "What uses .NET?"', move hints from the description into a discoverable format.